arthropod_shift

joined 1 day ago
[–] arthropod_shift@programming.dev 1 points 19 hours ago (1 children)

Not moving the goalposts at all, you're just missing the forest for the trees. The main point is that there are plenty of use cases that can use pure C with no assembly. I went with a simple example because I thought you'd have an issue with more complex examples like sending a notification over SMS via modem or providing a serial interface for sensor data.

I don't feel like arguing for the sake of arguing, though, and I feel like we're in a pedantry spiral, so I'll leave the conversation at that. Hope you enjoy your day.

[–] arthropod_shift@programming.dev 2 points 19 hours ago (3 children)

Again, those aren't universally required. You can make an embedded device that reads the ambient light levels and turns on an LED when it's dark without thread stacks, privileges, or interrupts. Don't make your system more complicated than it needs to be.

[–] arthropod_shift@programming.dev 2 points 20 hours ago (5 children)

Not necessarily. Let's say that...

  • The stack pointer is defined in the vector table to point somewhere into RAM.
  • The reset vector points to some function _entry(), with a linker script to take care of its memory placement.
  • All other interrupt handlers are arbitrary C functions.

You can compile only your C source file that defines _entry() and interrupt vectors, then flash the resulting firmware. No assembly involved, no external linkage, and no stdlib required.

[–] arthropod_shift@programming.dev 1 points 20 hours ago (7 children)

My point is that assembly isn't strictly required. You can do memory-mapped reads and writes from C all you want, which is enough for plenty of I/O: storage, serial, sensors, GPIOs.... You can build quite a few things with these without touching system registers.

I'm not saying we should abolish assembly. Just that it isn't a universal requirement.

[–] arthropod_shift@programming.dev 2 points 21 hours ago (9 children)

Yeah, if your bootloader is expected to handle that you're going to need assembly. That can also be delegated to the kernel, RTOS, or bare metal reset vector later on in the boot sequence, though. I had to write a bootloader for an embedded system like this once and it basically just applied firmware updates, validated the firmware, and handed control over to the firmware.

Reminds me of not long after I started using Linux. I thought the kernel was "just a program" like cat and tried to run the kernel from the terminal, only to be disappointed when a new kernel in fact did not start running inside the terminal window.

[–] arthropod_shift@programming.dev 4 points 1 day ago (11 children)

A little hair-splicy, but an assembly-free bootloader is definitely doable on some platforms -- Cortex-M processors load the stack pointer from the vector table, and the initialized memory setup can be taken care of with memcpy.