#11535 - poslundc - Thu Oct 09, 2003 8:06 pm
I'm writing my first ASM function to do my HBlank ISR in a separate .s file, which I intend to compile and link with the rest of my program.
My question is: which registers should I be preserving/restoring at the beginning/end of my function?
I've looked at ASM tutorials and seen a wide variety... some just preserve lr; most preserve r4 and r5.
The code that GCC automatically generated for my function preserves r4 through r7, as well as lr.
I checked the ARM docs, but couldn't find a standard list of registers that are to be saved/restored when a function is called.
Any help is appreciated.
Thanks,
Dan.
#11537 - sajiimori - Thu Oct 09, 2003 8:49 pm
The only ones that you can change without concern are r0-r3. The rest should be restored if you alter them. If you never call another function, and you never use other registers above r3, you don't need to save anything at all.
#11538 - tepples - Thu Oct 09, 2003 8:52 pm
ARM's procedure call standard explains all, including a table of registers' roles in function calls.
Summary: Conforming functions must preserve r4-r11 and r13. It's fine to trash r12, and it's fine to trash r0-r3 after you fetch arguments and r14 after you fetch the return address.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#11541 - poslundc - Thu Oct 09, 2003 9:40 pm
<blink, blink> I'd be lying if I said I made it terribly far through that. The table was useful, though.
| Quote: |
| Summary: Conforming functions must preserve r4-r11 and r13. It's fine to trash r12, and it's fine to trash r0-r3 after you fetch arguments and r14 after you fetch the return address. |
OK, will do!
Dan.
#12453 - poslundc - Fri Nov 14, 2003 3:32 pm
I'm now writing my first Thumb function, and am faced with this issue again. Basically it comes down to the following questions:
- The Work Register (r7) in Thumb mode seems to parallel the Intra-Procedure Scratch Register (r12) in ARM mode. Does this mean I can safely trash its value?
- Do I need to preserve the upper registers (r8-r15, excluding SP, PC and LR) if I decide to use them, or does Thumb mode consider them to be volatile?
Thanks,
Dan.
#12457 - torne - Fri Nov 14, 2003 5:42 pm
| poslundc wrote: |
I'm now writing my first Thumb function, and am faced with this issue again. Basically it comes down to the following questions:
- The Work Register (r7) in Thumb mode seems to parallel the Intra-Procedure Scratch Register (r12) in ARM mode. Does this mean I can safely trash its value? |
No. r7 must be returned to its original value before you leave your function.
| poslundc wrote: |
| - Do I need to preserve the upper registers (r8-r15, excluding SP, PC and LR) if I decide to use them, or does Thumb mode consider them to be volatile? |
Yes, you need to preserve them.
The rules do not change whether you are in Thumb or ARM mode. You must always obey the same restrictions.
#12538 - Omega81 - Mon Nov 17, 2003 9:10 am
I have two questions
1:
Since you are writting are writting an ISR, will you not have to preserve even r0-r3 as they may be in use when the ISR is called?
2:
Also I through r9-r15 are not accessible in Thumb mode? as in that mode the ARM behaves like a 16bit processor with only 10 registers (I think). Please can someone enlighten me.
Omega Red out!!!
_________________
Keep it real, keep it Free, Keep it GNU
#12539 - tom - Mon Nov 17, 2003 10:08 am
| Omega81 wrote: |
| Since you are writting are writting an ISR, will you not have to preserve even r0-r3 as they may be in use when the ISR is called? |
the bios interrupt handler does this for you, before it calls your interrupt handling routine.
#12541 - torne - Mon Nov 17, 2003 1:20 pm
| Omega81 wrote: |
| Since you are writting are writting an ISR, will you not have to preserve even r0-r3 as they may be in use when the ISR is called? |
As Tom said, the bios pushes and pops them, as it assumes that your ISR is any ATPCS-compliant routine.
| Omega81 wrote: |
| Also I through r9-r15 are not accessible in Thumb mode? as in that mode the ARM behaves like a 16bit processor with only 10 registers (I think). Please can someone enlighten me! |
In Thumb mode, the high registers can be accessed by the mov instruction, but not by most other instructions. You can mov r11, r0 or vice versa in Thumb, but you can't use, say, r8 as an arithmetic operand. All Thumb instructions can access r0-r7. Some Thumb instructions have special forms for accessing the PC, the LR and/or the SP (for example, the push and pop instructions are in fact 'stmfd sp!,' and 'ldmfd sp!,' respectively). Mov can access all registers, though you can't move an immediate into a high register. You need to look at an instruction set reference to see which instructions can access which registers; try to find a PDF copy of the ARM Architectural Reference Manual (the ARM ARM) if you can, however this document is *technically* not supposed to be free (I got it from Altera's website, but the link has now gone). The No$GBA help file has an ARM and Thumb instruction reference which, though terse and confusing, are accurate.
The ARM never behaves as a 16-bit processor, as the term '16-bit processor' refers to one or both of the address and data sizes. The Thumb instructions are stored as 16 bits but are simply decoded into full ARM instructions by the CPU during the decode stage of the pipeline; there are two seperate instruction decoders on the ARM's die, one for ARM and one for Thumb (-J variants of ARM processors have a third instruction decoder for Java bytecode). Thumb is merely a space optimisation; it does not change the way that the processor functions, and the ARM7 is always running in 32-bit mode.
Hope this clarifies everything,
Torne
#12546 - tepples - Mon Nov 17, 2003 4:11 pm
| torne wrote: |
| The No$GBA help file has an ARM and Thumb instruction reference which, though terse and confusing, are accurate. |
No$GBA is no longer available for free and is now available only to Nintendo-licensed GBA developers. I'd call it GBATEK instead of "the No$GBA help file."
| Quote: |
| The ARM never behaves as a 16-bit processor, as the term '16-bit processor' refers to one or both of the address and data sizes. |
Then why was the MC68000 processor considered a "16-bit" processor in Sega Genesis, Neo-Geo, and arcade architectures? It had seventeen 32-bit registers (D0-D7, A0-A7, and PC), a 24-bit address bus, and a 16-bit data bus. Likewise, the ARM7TDMI has sixteen 32-bit registers (R0-R14 and PC), and the memory controller in front of it has a 28-bit address bus and a 16-bit data bus to everything but IWRAM.
"Bitness" of a game console confuses me. Going by external data bus size of the primary CPU, the Super NES was an 8-bit system.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#12551 - torne - Mon Nov 17, 2003 5:51 pm
| tepples wrote: |
| No$GBA is no longer available for free and is now available only to Nintendo-licensed GBA developers. |
You can still use a copy if you have one, or download it from other sites if they still have it; he is merely not providing future versions or providing downloads.
| Quote: |
| Then why was the MC68000 processor considered a "16-bit" processor in Sega Genesis, Neo-Geo, and arcade architectures? It had seventeen 32-bit registers (D0-D7, A0-A7, and PC), a 24-bit address bus, and a 16-bit data bus. |
I'd call that a 32-bit processor. When I said address/data size I meant the word size, not the bus size. A processor with 32-bit registers and an ALU with 32-bit results is 32-bit IMO. I probably shouldn't've mentioned address size as even the ARM doesn't neccecarily have a 32-bit address space. =)
| Quote: |
| Likewise, the ARM7TDMI has sixteen 32-bit registers (R0-R14 and PC), and the memory controller in front of it has a 28-bit address bus and a 16-bit data bus to everything but IWRAM. |
Only the one on the GBA, which is a synthesisable core which has been tweaked by Nintendo. A normal hard ARM7 core has 32-bit address and data busses; the synthesised core on the ARM has all 32 data lines hooked up to the IWRAM (which is on the same die), but only 16 data and 28 address lines emerging from the die. The ARM is happy to work with a memory map where different regions have different bus widths as this is common in the embedded world.
| Quote: |
| "Bitness" of a game console confuses me. Going by external data bus size of the primary CPU, the Super NES was an 8-bit system. |
It normally refers to arbitrary marketing crap, on consoles. =) I wouldn't count the bus size, just the ALU width and/or address space (i.e. program counter width).