So, I haven't written ARM assembly since I owned an Archimedes computer many years ago, but isn't there a mistake describing the very first assembly language instruction in lesson 1?
> The ARM assembler also supports a similar pseudo operation. The construct LDR rd,=value is used to load value into register rd. The LDR pseudo instruction uses the MOV or MOV instructions, or it places the constant in memory and uses program counter relative addressing to load the constant.
> If expression evaluates to a numeric constant then a MOV or MVN instruction will be used in place of the LDR instruction, if the constant can be generated by either of these instructions. Otherwise the constant will be placed into the nearest literal pool (if it not already there) and a PC relative LDR instruction will be generated.
Thanks! That makes sense, I'm only familiar with the old assembler from BBC Basic :) 0x202 wouldn't be a constant that you could use with MOV now I think about it, since it could only express integers generated with an 8 bit value and a shift.
ARM instructions are 32 bit, so there is a problem when you want to load a 32 bit literal. The assembler will get around this by sticking literals in the text section and then fixup the load with the correct offset.
You can use that method (arm usually uses a "mov" and "movt" to load upper and lower half-words), but you would be using 2 instructions to accomplish the same thing that ldr with a literal pool does in one.
Not sure about a MOVT (my ARM assembler is only current to an ARM2...) but it's two (pipelined) instructions vs one instruction and a slow memory access. But then again, I'm thinking of a previous era with no instruction or data caches !
I speak mostly from an ARMv7 perspective (so pipelines, caches, prefetchers, etc are par for the course).
Your literal pool has a high degree of spacial locality WRT the instruction that references it. You can take measures to optimize this (see the ltorg directive) making I$ hits very likely.
In the end, the assembler is free to pick and choose which method is best for the target CPU and input code.
From what I can tell, yes. ldr r0, =0x20200000 loads from memory. In C, r0 = *0x20200000; what we would want is just r0 = 0x20200000; or mov r0, #0x20200000
However, I wonder if it isn't too painful in the long run to teach OS programming on a target where you have to flip SD cards every time you compile (as opposed to one of those with a hardware debugger included, like Launchpad or ST Discovery).
When I took Operating Systems (INF242 at Oslo) ten years ago, we wrote an operating system for PCs that booted from floppies, and debugging was largely a matter of poking bytes to 0xB800:0000, which made this course somewhat unpopular with students with little low-level programming experience.
