Hum, not sure to understand,
Well there was a bit sarcasm in saying 64bit CPU. 
On an ARM CPU you'd probably need about 10bytes to beep a piezzo on an IO line. I have a vague recollection that there's even a BIOS call for this on a PC.
Back in the good old days of Turbo Pascal we still had access to memory mapped IO.
Now, with all the cross platform abstraction it become a major software engineering project !
I want to make two points here, although it really wouldn't be appropriate for us (collectively) to allow this to mushroom into an off-topic wibble.
The first is that we're stuck with having to go through APIs for this sort of thing. The alternative is to use a platform like Arduino, and to discover- the hard way- that since there's no underlying OS or HAL that using multiple libraries- even well-written ones- is fraught since they inevitably end up contending for timers or other low-level resources.
The second is that I'm not at all happy with the situation, but can't see an easy way out of it.
Mainstream OSes are fundamentally broken, because both major clades (Windows and unix) have at some point made decisions that prioritised speed over robustness and modularisation. This is compounded on the PC architecture by the emphasis on backward-compatibility.
Linux, in particular, has ended up as a monolithic mess. This has been made worse rather than better by the efforts of people to rationalise the situation by adding subsystems with both application-facing and device-facing APIs, I would highlight ALSA/PulseAudio here as well as systemd... in fact we might as well throw in just about anything by Lennart Poettering for good measure.
Noting the Torvalds/Tanenbaum controversy, it's likely that adoption of a microkernel-based OS would, initially, have complicated things by forcing more rather than less API use. However 30 years on, I suspect that we would be seeing significant advantages: if nothing else because the heavy use of IPC between independent daemons would have forced writing use of robust documentation.
The problem there is that architectural choices made in the early 90s would probably have been stifling by the early 00s. For example, unix initially used named devices at a low level with a small number of uniform driver calls... but all of a sudden the proliferation of novel hardware broke this to the extent that the majority of devices now have a user-accessible "backdoor" API (open a named device, use an IOPL to get a pointer to a private entry point, and call that directly). As an older example, I remember an OS that used byte-wide IPC for keyboard input... which broke when programs started working with PC-style scancodes, and was beyond salvage when almost everything wanted to be able to check the held-down state of arbitrary keys... and this included background programs which by rights should be completely isolated from the UI.
So, I'm sorry: on unix, we're stuck with ALSA or something even nastier. And on Windows, while the APIs might arguably be more straightforward you still have to use them: Turbo Pascal was written back before most people had heard of multitasking OSes, and those of us who had to both develop in and support languages of that era used to curse their assumption that they had unfettered low-level access on a regular basis.
MarkMLl
Recent
