Questions about ARM and stuff~

Discussion of development of software for any "obsolete" computer or video game system.
Post Reply
naseyuki
Posts: 6
Joined: Wed Feb 13, 2019 6:30 pm

Questions about ARM and stuff~

Post by naseyuki » Mon Jun 15, 2020 6:26 am

-
Last edited by naseyuki on Tue Jun 16, 2020 5:11 pm, edited 1 time in total.

User avatar
Bregalad
Posts: 7879
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Questions about ARM and stuff~

Post by Bregalad » Mon Jun 15, 2020 7:27 am

naseyuki wrote:
Mon Jun 15, 2020 6:26 am

When using thumb, what is the most common practice on function creation and use? Like r7 is stack frame pointer and etc.
No, r13 is still the stack pointer and r14 is still the link register, no matter whether THUMB or ARM mode is used. Because r8-r15 aren't adressable by the instruction set doesn't mean they stop to exist. The only difference is that those registers aren't directly accessible with THUMB instruction set, which targets r0-r7. PUSH instruction can still use the link register (aka r13) and the POP instruction can still use the program counter (aka r15) which allows to use the stack for storing the return adresses, and using those return adresses.

Not sure what you mean by "function creation" - this sounds like something that only exist in HLL, not in assembly.
I'm currently calling functions loading their address into r6 and bxing into it, there's a more simple/elegant way to do it?
Still not sure what you mean by "function loading".
But to call a subroutine you'd typically use the bl instruction.

So the typical "normal" way it's handled is :

Code: Select all

some_non_leaf_routine:
    push lr       ; save return adress on the stack
    [code here]
    bl some_leaf_routine
    [code here]
    pop pc      ;restore return adress and jump back to it

some_leaf_routine:
   [code here]   ; no need to save the return adress in the stack, it stays in link register (aka r14)
   bx lr          ; jump back to return adress
And the thumb interworking with ARM, I don't find any resource about what's the best practice when going from one to another.
I'm not an expert but normally the bx instruction is the "standard" way to do this. The low bit of the destination adress is discarded and used as an ARM/THUMB switch.
I would only use ARM, but since I decided to work on the GBA (that have a sufficient hardware, and don't have the executable limitation of the NDS + the roundabout way of accessing the cartridge data), just printing a string on the screen already shows the difference between the two on NO$GBA's CPU usage bar.
Yeah, executing code directly from ROM, it makes no sense for it to be ARM, since the CPU will have to fetch both half-words separatedly, making it as slow as THUMB code. It has to be loaded in IRAM or VRAM (yeah!) in order to run faster than THUMB code.
Also note, don't trust emulators when it comes to exact CPU speed. Most GBA emulators are still close to Nesticle-days when it comes to accuracy, and this includes no$gba. Only mGBA has proven to be a little more accurate.

User avatar
aa-dav
Posts: 56
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Questions about ARM and stuff~

Post by aa-dav » Mon Jun 15, 2020 9:25 am

I would strongly recommend using of GCC with assembler code as inlines or separate modules.
GCC architecture allows to create assembler output (command line parameter -S) from C/C++ sources which will produce absolutely the same binary object file. So, it's easy to look into code generated by compiler and to add own code in similar way. Assembler or not.
It's good thing to learn about GCC inline asm because it's very efficient thing too. However large chunks of code are better to implement in separate asm file.
Modern GCC compiler generates VERY efficient code, so it's not like NES where cc65 can drop speed by x10 times. So this platform are really from times where compilers began to rule the world.
I see very little need in asm there. It must be something like demo where you need to copy chunk of code into 32-bit-wide-bus internal RAM to speed up ARM mode code or something.
Some time ago I started to do Contra Force port there: https://youtu.be/FwRUjuW54aE but stopped it (source code is free, but ask link if you want to see them). Anyway I never feel need in asm on that platform. (To say the truth I wrote almost full course of GBA programming tutorials in my native language and this port was it's 'complex example')
The low bit of the destination adress is discarded and used as an ARM/THUMB switch.
If I remember correctly it is not even discarded, but it IS ARM/THUMB switch, so then you place return address to LR/stack you place this bit in it automatically. So, switching between modes is easy and transparent thing and, for example, function pointers in C work without any need of knowing of concept of different modes at all. This bit is just not used in fetching of instructions.

User avatar
Bregalad
Posts: 7879
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Questions about ARM and stuff~

Post by Bregalad » Tue Jun 16, 2020 1:36 am

I see very little need in asm there. It must be something like demo where you need to copy chunk of code into 32-bit-wide-bus internal RAM to speed up ARM mode code or something.
Depends what you want to do, for a normal game I fully agree, but if you want to push the system to its limit like having an advanced sound mixer or do 3D-rendering, then assembly comes in handy - but in that cases you need to have the code in IWRAM and use ARM code - the performance loss by executing THUMB code from ROM will be enormous.
Some time ago I started to do Contra Force port there: https://youtu.be/FwRUjuW54aE but stopped it
Very cool ! That explains your avatar...

User avatar
aa-dav
Posts: 56
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Questions about ARM and stuff~

Post by aa-dav » Tue Jun 16, 2020 2:30 am

Bregalad wrote:
Tue Jun 16, 2020 1:36 am
...
Very cool ! That explains your avatar...
Thanks! It was best game in my cartridge collection in childhood, so I have special place for it in my nostalgy list. :)
As for ARM I believe it's better for start to look at the code compiler emits (-S -O2) and learn. Modern compiler are very efficient.

naseyuki
Posts: 6
Joined: Wed Feb 13, 2019 6:30 pm

Re: Questions about ARM and stuff~

Post by naseyuki » Tue Jun 16, 2020 8:19 am

-
Last edited by naseyuki on Tue Jun 16, 2020 5:11 pm, edited 1 time in total.

User avatar
aa-dav
Posts: 56
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Questions about ARM and stuff~

Post by aa-dav » Tue Jun 16, 2020 9:07 am

naseyuki wrote:
Tue Jun 16, 2020 8:19 am
Unhappily I'm really working with assembly for the fun! With C everything would be done so quickly wouldn't be fun.
I respect this reason. :)
I refresh my memory and yes, ArmV4T has Thumb-1 only and it's not as versatile as Thumb-2 in modern Android projects where I analyze generated asm sometimes too. Thew, all these T1/T2/A1/A2 (and so on) encodings of instructions in "architecture reference manual" seems like a lot of problems for compiler creators and you. :)
It's interesting that DevKitArm still uses BL instruction for interworking calls betweeen C functions, but I suppose it's up to linker to detect interop and replace BL with something else or place trampoline. Again, BL in fact is two different 16-bit instructions in Thumb-1, first one is updating one part of LR and second one - anther+executes jump. Maybe linker can replace it with something, but it's not visible in compile time.
I think you can just google 'ABI for Thumb' and look at some different schemes and choose something you like.

Then I was young I have big problem with programming in assembler (Z80 or i8086 back then): I always get bogged down in optimization of every single instruction. Every movement of data from register to register should have been justified and every CPU clock cycle must not be spent in vain. And that slowed me down a lot. It required a lot of time for me to get rid of fear of non-ideal assembler code and for several last years I like to make things I didn't made then was young because of fear of imperfection.
And it's good feeling - to stop worrying when you save temporary variables to memory and so on.
And MOS 6502 made a lot for this my progress because it just has no options. You just doomed to save/load memory every time and everywhere.
And it's such a relief. :)))

Post Reply