ASM programming is FASCINATING!

[mfro]

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.

It will not even work (out even) for basically all modern CPUs. A dirty trick of the past.

[BravoV]

If you are into swinging on monkey bars with 11KV 3 phase on adjacent rungs, then you'll enjoy this...

- Self modifying code. This is pretty dirty but a great technique for some very fast stuff. Normally one doesn't modify opcodes but modifies the data fields in an instruction. It can speed up code several times.

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.  Look for a more conventional approach - BUT if you absolutely have to resort to something like this - DOCUMENT THE HELL OUT OF IT!!

Its the bread & butter for malware I guess.

[tggzzz]

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.

It will not even work (out even) for basically all modern CPUs. A dirty trick of the past.

In that case, how do JIT optimisers for modern language runtimes work? They create code fragments on the fly at runtime, then execute them.

You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter.

[mfro]

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.

It will not even work (out even) for basically all modern CPUs. A dirty trick of the past.

In that case, how do JIT optimisers for modern language runtimes work? They create code fragments on the fly at runtime.

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).

[Berni]

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.

It will not even work (out even) for basically all modern CPUs. A dirty trick of the past.

It does work on modern CPUs.

It indeed does not make sense to use it for the things that self modifying code was used on 8 bit computers of speeding up things. Doing that on a modern CPU will in most cases just confuse the heck out of its long pipeline.

But JIT interpreters found a new use for this. The program looks at its uncompiled (ie. JavaScipt) or bytecode compiled code(ie .Net) and translates that into machine code instructions, then jumps into those machine instructions and executes them until reaching a part that has not yet been compiled where a jump back into the JIT interpreter is placed, making it compile up some more machine code and jump back in to continue running. This makes for a massive speed boost compared to the oldschool emulation based interpreters.

Another use for self modifying code on modern PCs is game console emulators. Sometimes PCs are too slow to emulate the consoles CPU or GPU in real time, so the emulator works a lot like JIT to translate say PowerPC instructions into x86 instructions on the fly.

[tggzzz]

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.

It will not even work (out even) for basically all modern CPUs. A dirty trick of the past.

In that case, how do JIT optimisers for modern language runtimes work? They create code fragments on the fly at runtime.

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).

(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]

You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter.

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]

You do, of course have to ensure that there are the necessary memory barrier instructions in the JITter.

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

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.

[MK14]

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.

>>"self-modifying code won't work on modern processors isn't true".

Many (not all) electronics/embedded processors (MCUs) these days, have Harvard architecture's, and the code can only reside in flash memory. (**Yes I know, some do let you run code in ram).

I.e. No self-modifying code (ignoring continually rewriting flash memory techniques, which would risk wearing out the flash and would be relatively slow, continually erasing/rewriting the flash, usually).

[tggzzz]

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.

>>"self-modifying code won't work on modern processors isn't true".

Many (not all) electronics/embedded processors (MCUs) these days, have Harvard architecture's, and the code can only reside in flash memory. (**Yes I know, some do let you run code in ram).

I.e. No self-modifying code (ignoring continually rewriting flash memory techniques, which would risk wearing out the flash and would be relatively slow, continually erasing/rewriting the flash, usually).

True, but "modern processor" != "embedded MCU", any more than all black birds are crows.

I remember seeing a C compiler get around the limitations of an instruction set by building a subroutine on the stack, and then execute it.

[Nusa]

To the OP that's just having fun learning, I recommend the following book:
https://www.academia.edu/36492595/Prosser_The_Art_of_Digital_Design_2ed

That digital copy is free, but a new or used paper copy is easy to buy if you prefer that.

Disclaimer: I've known the authors my entire life as family friends and colleagues of my father. Also, I was one of those that did the labwork covered in the book (wirewrapping and testing their PDP-8 design) before the book was published. Winkel passed away four years ago, but Prosser is still moving. Dad died last October, age 88.

[MK14]

True, but "modern processor" != "embedded MCU", any more than all black birds are crows.

Doesn't make any difference.
Because I was effectively trying to say (in summary):
SOME modern processors, don't allow self-modifying code.

So, since many embedded MCU's are modern processors, what I said still stands and is correct.

I.e. If some crows, have Covid. Then it would be true that at least some black birds have Covid.

I would have needed to say, if ALL crows have Covid, then I couldn't say "ALL black birds have Covid", as that would not be necessarily correct.

[Berni]

Hraward architecture MCUs are sort of the old way of doing things these days. But yes self modifying code is indeed problematic for those.

These days modern high performance MCUs are moving away from dedicated flash. The latency is becoming too high to directly execute instruction by instruction from it, so time critical things like interrupt handlers are meant to be put in RAM anyway. Also the manufacturing process optimized for CPUs does not make very dense flash, so megabytes of flash tend to start getting bigger than the CPU itself. For that reason they are now starting to make MCUs with no non volatile memory at all, requiring external memory to hold the program in things like QSPI flash, so copying critical code to RAM becomes even more important.

Loading code from some other memory to RAM and then executing it is technically self modifying code. Tho its more appropriate to call it a bootloader instead.

[tggzzz]

Loading code from some other memory to RAM and then executing it is technically self modifying code. Tho its more appropriate to call it a bootloader instead.

Precisely.

That can be extended to loading a program from disk in any conventional PC/workstation/supercomputer.

[joeqsmith]

Loading code from some other memory to RAM and then executing it is technically self modifying code. Tho its more appropriate to call it a bootloader instead.

I'm sure many of us have swapped memory on the Intel parts.  On my oldest computer, which had 2K of core, half for the video, you would have a small bit of code that would reside in core and it would then swap segments from the floppy to the core to execute them. 

On that computer, the bootstrapping was done in hardware.  There was a reset button for the program counter.  You would then press keys and the computer would take the lower nibble and combine it with the next keys to form instruction.   Nothing would be on the display while you performed this process.   

[peter-h]

Self modifying code obviously needs to reside in RAM, but this is not that unusual in modern applications e.g. where you want the code to load an updated flash image. You normally can't run code from flash while writing the flash. On the ST ARM is supposedly does work, somebody claims, but you get about 100000 wait states after each instruction So not practical. You need to copy the flash loader into RAM and run it from there. Some variants have two flash banks for this reason but they cost more.

None of this stuff is a problem if you comment it properly. Nowadays most "software" is hacked really fast, with zero comments. It may be a form of job security for the programmer... Certainly in PHP it seems normal to have zero comments. Nobody can maintain such code cost-effectively... Commenting is an art, as much as writing the code itself.

I am fairly sure the ST ARM 32F etc, running at the max of about 150MHz, runs out of the on chip flash with zero wait states. It would be dumb otherwise. External bus memory (which robs you of most IO pins) uses a load of wait states.

[Berni]

Yes above around 100MHz the flash tends to start having latency issues keeping up with the CPU. It depends a lot on the implementation so it varies between vendors. One of the common vendors like ST uses cache accelerated flash for running a ARM Cortex M4 core at 180MHz. All of the larger chips from ST using the ARM Cortex M7 and similar then have a full on instruction and data cache right in the CPU. The fastest H7 family doesn't even run the internal RAM at full CPU speed anymore, so if you want to actually make proper use of all of those 480MHz you need to use the cache. Indeed some also have external RAM capability and caches are a must there, especially because DRAM likes sequential access and often these RAM controllers commonly found on MCUs tend to be rather slow (But still very useful for doing graphics at higher resolutions). At that point optimizing code indeed becomes more like on modern x86 PCs where the bottleneck is RAM latency so a cache miss becomes the most painful performance hit.

Id say running from flash while also writing to it is a pretty common feature in MCUs even old harward based ones. More of a trap is that flash needs to be erased in large pages, so if you try to modify a location in flash that is too close to currently executing code then the erase step will also erase the code and crash before it has time to put that data back in. Doing this write while running from RAM with interrupts disabled gets around this problem. The fact of running slower is usually not really a problem since your flash writing routine is likely waiting for the slow flash to finish writing anyway (And its often a bootloader or something where it doesn't have to do anything else). Tho its better practice to simply put the data you want to modify somewhere far away and align it to the flash pages.

[Siwastaja]

- CPU and peripheral register initialisation which needs to be exactly right and often needs to be loaded in a particular order e.g. some registers are not accessible until after another has been suitably configured. Most people do this in C too, but they would be mostly stuck if they could not copy startup code ripped off from the dev kit source examples

This isn't actually true IMHO, all of this is easily controlled using the volatile qualifier in C. I have always written startup code in C, it's typically copying from one address space to another (so assigning *something = *something in a while loop), zeroing some address space (*something = 0 in a while loop), possibly configuring a few registers (just reg = val), then calling main. None of this requires asm.

Most of your other points I agree with, though.

The reasons for needing (instead of just preferring it for the "why not" argument) asm modules or inline asm segments are usually so specific, weird and complicated that you could write a book chapter of each case, but yeah, the gist of it is that sometimes it is just impossible (or very difficult or unreliable) to get the C compiler to do what you need to do. In the end, maybe 1% tops of my MCU code is in asm, including startup code where I have never needed any asm.

One example of inline asm would be a 2-channel synchronous DC/DC converter where the two interrupt handlers would store 16-bit current readings in a reserved (prevented the C compiler from using it anywhere in the program) CPU register so that SIMD instructions can be used with the least amount of memory overhead, so that both ISRs calculate values for each other as a side product of calculating 16-bit values for themselves.

You can do many of the typical asm use cases with compiler intrinsics these days, though. It's a matter of taste whether you call this "asm programming"; it technically is, in a sense! The piece you need to do in asm gets progressively smaller when you move from the full asm modules into inline asm, then intrinsics.

[ebastler]

To the OP that's just having fun learning, I recommend the following book:

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

[Siwastaja]

Yes above around 100MHz the flash tends to start having latency issues keeping up with the CPU. It depends a lot on the implementation so it varies between vendors. One of the common vendors like ST uses cache accelerated flash for running a ARM Cortex M4 core at 180MHz. All of the larger chips from ST using the ARM Cortex M7 and similar then have a full on instruction and data cache right in the CPU. The fastest H7 family doesn't even run the internal RAM at full CPU speed anymore, so if you want to actually make proper use of all of those 480MHz you need to use the cache.

No, these STM32H7 (even the lower-end F7 series) parts do have the core-coupled RAMs that run at the CPU frequency, so no need to run with caches. Cache becomes very useful when you have large applications you want to run off SD card or something.

The whole idea of running code from RAM benefits significantly from using a dedicated RAM just coupled to the core, so that instruction fetches do not appear on the bus. From chip design viewpoint, this is a relatively small extra cost to having a single larger RAM. The SRAM kilobytes themselves are expensive. (Of course, dividing the total kilobytes to several different interfaces makes the usage of the RAM less flexible if you need large tables or dynamic allocation.)

In my experience, the ITCM / "boost" ram / scratchpad / whatever they call it sections tend to be so large (for example, 64kB for the H7 parts I have worked with) that you can fit most of your code there, not just the most obviously timing-critical pieces, making the decision what to put there much easier; place it in ITCM unless you are sure the performance doesn't matter. All sorts of init functions tend to remain in flash for running, for me.

[MK14]

This isn't actually true IMHO, all of this is easily controlled using the volatile qualifier in C.

Nice post, overall, but 'volatile' is not always enough. The thing is that some hardware setup, has strict timing 'rules', imposed by the datasheet and/or hardware design.
E.g. An A to D converter, which insists, that after enabling it, you have to wait X microseconds or machine cycles, before using it. So that it can stabilise/initialise itself properly.
Or a watch-dog timer(s), which can only be enabled or disabled, a certain time (e.g. clock cycles), after initially coming out of reset. To stop errant software from being able to interfere with the watch-dog timer, later.

In assembler, these timings, are fairly easily bolted down, by counting the clock cycles (which isn't necessarily that precise these days, as already discussed in this thread).
But in a highly optimised compiler (although one option, might be to disable or reduce the optimisation setting, for the hardware initialisation part of the code). The compiler may interfere too much with the timings. Bit-banging, hardware timings, can also be tricky, when compiler optimisations are enabled.

In some extreme cases (I remember worrying about this a long time ago, I can't remember if I had to do it or not, in the end). Even the initialisation performed by the C compiler (e.g. clearing sections of memory, compiler dependent), can take so long (in fast hardware terms, like milliseconds). That you can't meet the specifications of the product, without putting assembler start up code, even BEFORE the C code has initialised itself.
Even before the first C statement, can be executed.
E.g. To check for some startup options (defined by the statues of some external I/O port pins), then do things and/or disable/enable other I/O things. To meet those requirements.

I can't remember exactly, but off the top of my head, it was something worrying long, like 500 milliseconds (on a relatively slow processor, too long ago, I could be misremembering, but it was longish), to finish the C compiler initialisations.
It was to switch on or off, some stuff, to protect the hardware, immediately after switch on (coming out of reset). Otherwise, the hardware could damage itself (arguably poor design, not my design anyway).

Anyway, I agree. that there are various things you can do, so that if you are really determined. You can solve most/all of these issues and implement such schemes in C code.

E.g. Using hardware timers and/or interrupts. To get the timing right and independently of the instruction execution times.

[Siwastaja]

MK14,

Indeed, setting up the C "runtime" for running standard-compliant C does take time. More specifically, this means that because the C standard guarantees that global (or static, inside of functions) variables, tables etc. are all initialized zero, there must be some piece of code before main() that zeroes all these variables. Similarly, there must be a piece of code which copies the initial values of all initialized globals and statics from the flash memory. That's basically what the magical "startup code" is - completely trivial.

However, you can decide not to use the compiler-generated startup code and do that yourself - either in asm or C. This should be possible in most compilers.

Clearing the bss and copying data in ASM isn't going to magically be any faster than the same in C, the implementation is trivial, and C compiler does the most optimized copy and zeroing, likely even at the lower optimization levels.

You can, of course, decide to do things like perform certain important tasks before bss is zeroed or data copied - I do that all the time, you basically just move the important main() things out of main, to the reset vector handler or whatever you call it -, or decide not to conform to the C standard and not clear .bss, and so on, but you don't need any ASM to do any of this - the same result can be achieved in both C or ASM.

That really leaves us with those peripherals that require cycle-accurate control sequences. I find those are exceedingly rare although yes they do still pop up from time to time, and using some asm to access them has better chances of being consistent than writing some dummy operations in C and hoping it stays the same.

[MK14]

However, you can decide not to use the compiler-generated startup code and do that yourself - either in asm or C. This should be possible in most compilers.

That particular example, was from a very old compiler (compared to ones, these days). It was an 8 bit processor (8051/2 series), and those compilers, were trickier and somewhat/potentially eccentric (the 8051 can be a funny sort of beast, e.g the way its I/O ports work!). Some old 8 bit processors (like that), with old compiler technology, were not especially brilliant.
It sticks in my mind, because I remember the difficulties, that needed to be sorted out.