General > General Technical Chat
ASM programming is FASCINATING!
tggzzz:
--- Quote from: Berni on July 30, 2020, 09:44:52 am ---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.
--- End quote ---
Precisely.
That can be extended to loading a program from disk in any conventional PC/workstation/supercomputer.
joeqsmith:
--- Quote from: Berni on July 30, 2020, 09:44:52 am ---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.
--- End quote ---
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:
--- Quote from: peter-h on July 29, 2020, 03:14:17 pm ---- 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 :)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version