https://github.com/ksaj/helloworld
I kept the code as close to each other in format and style as possible, so comparisons are easier to make. I don't really know the benefits and drawbacks to each method, but they are there and available, so I sleuthed them out and got them working.
This doesn't seem quite right; the code doesn't use libc, but it talks to kernel and not directly to hardware. On Linux I don't think direct syscalls are in any way "no-no". But most importantly it still doesn't work on bare-metal; indeed, the hardware has no concept of stdout
also
"This means that the processor state changes to ARM, the processor mode changes to Supervisor, the CPSR is saved to the Supervisor Mode SPSR, and execution branches to the SWI vector"
I'll have to go into that further. I was under the impression it was similar to the x86 OUT opcode. So is it more akin to a "direct syscall" then?
This is what we used to do with 8 bit computers that didn’t have a hardware text mode. You might be able to look up the bitmaps in the ROM, otherwise it’s time to define them all yourself.
Using a direct system call would be like calling a ROM routine or an OS routine to print characters. You’d either call the routine or invoke a software interrupt.
Oh wow, memories!
Had an Amstrad CPC6128 in the mid-80s and for the life of me I just could not 'get' BASIC. "Syntax error" in everything, even those multi-page type-in games that Amstrad Action would print each month.
Then I discovered the MAXAM ROM - along with Protext. That, a copy of the CPC Firmware Guide, and I was away.
BASIC stumped me but the Z80 language just clicked.
Loved writing code, learnt the importance of backups, learned how to find cheats in games and so much more. Good times.
[1]: https://developer.arm.com/documentation/den0024/a/The-A64-in...
>Apparently this is a no-no, even if it is theoretically more efficient. The bare-metal and OS dev folk are pretty much limited to using this method
mov r7, #4 /\* raw system call for write */
swi #0 /* print without using clib \*/
I haven't really looked deep into it but a google search came up with this for bare metal text printing https://github.com/bztsrc/raspi3-tutorial/tree/master/0A_pcs...
"You have to do this to do functions the kernel supports but haven't been ported to clib yet."
This is insightful. I'll reflect it in my updated text.
But as their goals and timelines are different, they are out sync, which comes into play not only in the new functionality not being included, but variations of existing functionality where the function has additional flags or parameters that the clib function hasn't added. For example, you'll often see this in areas involving threading, starting processes, and sockets. Luckily for most people you'll often find a fork of the clib or just a 3rd party library that wraps the functionality, but if you are on cutting edge or using a feature that never really caught on because its applicability is very niche, you'll have to go back to syscalls.
Though not assembly language, I think that www.ultibo.org is a cool embedded development environment for the Pi.