| General > General Technical Chat |
| ASM programming is FASCINATING! |
| << < (12/24) > >> |
| tggzzz:
--- Quote from: mfro on July 30, 2020, 06:32:46 am --- --- Quote from: tggzzz on July 30, 2020, 06:19:22 am --- --- Quote from: mfro on July 30, 2020, 06:07:36 am --- --- Quote from: Brumby on July 30, 2020, 01:52:34 am ---Doing this requires great care. If you have any conceivable element of luck in your approach or risk assessment - don't. It WILL blow up on you. My advice is - DO NOT do this. --- End quote --- It will not even work (out even) for basically all modern CPUs. A dirty trick of the past. --- End quote --- In that case, how do JIT optimisers for modern language runtimes work? They create code fragments on the fly at runtime. --- End quote --- They either have to do (ineffective) cache flushes or use other means to ensure that the icache doesn't contain old code (like executing a sufficient amount of other code first). --- End quote --- (Looks like your response and my addition to my post missed in the æther. ) You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter. Clearly they are effective, since JITters work. They are not, and do not need to be, lightweight. Since I haven't looked at this topic for 25 years, I am out of date on the details. |
| Berni:
Oh and instruction cache is not a problem because the CPU itself is writing to it so the cache controller can see a write happening to that location and act accordingly. Issues with the cache comes up if you are to use other things like the DMA to modify it. In that case the write access didn't go trough the CPUs own internal memory bus and so the cache controller could not see it, so it keeps caching the old invalid data. However it seams like PowerPC has an issue with old instructions getting wedged in its pipeline, so even with cache disabled there are special procedures in making sure self modifying code doesn't screw it up. https://stackoverflow.com/questions/10989403/how-is-x86-instruction-cache-synchronized |
| mfro:
--- Quote from: tggzzz on July 30, 2020, 06:39:25 am ---You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter. --- End quote --- A memory barrier doesn't help with cache coherence. In its original sense, memory barriers are only meant to enforce a certain sequence of execution of code JIT will be effective on platforms that implement bus snooping to maintain cache coherence. Typically not found on µCs |
| james_s:
I've dabbled in 6800 assembly with my Heathkit ET-3400. I created a FPGA version of the ET-3400 that anyone can play around with https://github.com/james10952001/Heathkit-ET-3400 The 6800 core is not cycle accurate so programs run a bit faster than they do on a real ET-3400 but I've used them side by side and it's pretty close. |
| tggzzz:
--- Quote from: mfro on July 30, 2020, 07:01:13 am --- --- Quote from: tggzzz on July 30, 2020, 06:39:25 am ---You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter. --- End quote --- A memory barrier doesn't help with cache coherence. In its original sense, memory barriers are only meant to enforce a certain sequence of execution of code JIT will be effective on platforms that implement bus snooping to maintain cache coherence. Typically not found on µCs --- End quote --- Both those points are true. Nonetheless, your original contention that self-modifying code won't work on modern processors isn't true. Cache coherence is found in any general-purpose SMP computer, and is a severe limitation on scalability. |
| Navigation |
| Message Index |
| Next page |
| Previous page |