Blocking or Non-Blocking?

[thejpster]

Should the common BIOS API have naive blocking functions? They are easy to use and simple to implement, but they hurt performance (e.g. printing 15 characters when you only have an 8 character FIFO will cause the CPU to spin for the duration of 7 characters - or 608 microseconds at 115,200 bps).

Non-blocking functions are more complicated - you'd have to get some aynchronous object back which represents the transaction which you'd need to poll for completion at some later date (c.f. Windows Overlapped IO).

A compromise might be functions which process as much data as they can without spinning, and return a value indicating how much has been processed. Obviously disk reads block until the entire sector is available, but writing a [u8; 16] to a UART might write half the buffer into a FIFO and then return 8 to indicate some data was left unwritten. The OS can then decide whether to retry immediately or come back later after doing some other work.

[IGBC]

Probably both, with blocking implementations working as block!(call)

[thejpster]

So, the OS isn't going to support processes, as we don't have an MMU. But is it going to support threads? Acorn MOS, Commodore Kernal, MS-DOS and CP/M didn't, to the best of my knowledge - they just had basic single-byte routines, or blocking sector-based disk reads/writes. Supporting the writing of multiple bytes at once offers greater performance/efficiency, especially on platforms like the Nordic nRF where all UART access is done via DMA but I'm not yet convinced that making the BIOS API more complicated to gain some efficiency on an uncommon operation on an uncommon platform is a good trade-off.

[IGBC]

I expect the BIOS to evolve as applications are written ontop of it. The structure of the BIOS call table, I feel we can add functions as long as we don't remove any.

With this in mind I feel we can add Aync BIOS calls later if/when needed