[zokier]

> Hello World bypassing clib altogether, and talking direcly to the hardware. 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 until their kernel boots and provides other methods, like those covered already.

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

[ksaj]

"Software Interrupt (SWI) functions are functions that run in Supervisor Mode of ARM7™ and ARM9™ core and are interrupt protected."

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?

[brontitall]

I wrote a longer answer in response to your other comment. It has a lot of explanation that I see from this comment is likely not needed for you. I’m pasting it here, anyway. I’m no expert in ARM assembler but it appears that SWI 0, later renamed SVC[1], is how you make system calls in ARM Linux[2]. That would make it equivalent to x86 syscall. In other words, it’s the underlying mechanism that libc uses to ask the kernel to output some data. In this case you are calling the write[3] system call (selected by r7=4) with the arguments (r0:fd=1 - file descriptor 1 – i.e. stdout, r1:buf - the address of the data to write, r2:count=14). The kernel then does whatever is necessary to accomplish that write. It could be talking to the video core to update the text console or the contents of a window. It could be passing it to its lower networking layers for sending over an existing network connection for an ssh connection.

It’s pretty fundamental to the Linux kernel that you can’t access any hardware directly unless things have been set up specially to allow it in a limited way. If you really want to deal directly with the hardware, you either have to convince the kernel to allow you to, or run without an operating system. In that latter case, it’s on you to drive all of the hardware. And there’s actually quite a lot of hardware involved in getting stuff displayed on a raspberry pi screen.

[1]: https://developer.arm.com/documentation/qrc0001/latest/ [2]: https://man7.org/linux/man-pages/man2/syscall.2.html [3]: https://man7.org/linux/man-pages/man2/write.2.html

[ksaj]

Thanks! I'll check out your other response as well.