Device Driver API

[sam-falvo]

I've been thinking, why keep the distinction between character I/O and block I/O? Perhaps unifying them would make some sense?

For example, in Plan 9 from Bell Labs, all filesystem drivers implement a single read/write abstraction. In terms of a higher-level language like C, they would look like:

• actual_size = read(fileHandle, buffer, size, offset);
• actual_size = write(fileHandle, buffer, size, offset);

The idea is that "offset" tells the driver where to read or write, with buffer and size indicating how much data to preferentially transfer. actual_size is an indication of how much data was actually transferred.

But, for character devices, offset is simply ignored.

Thoughts?

[zuiko21]

It makes sense and seems easily implemented. I see however a few performance considerations:

Currently, the CIN and COUT functions just use a io_c parameter (besides the device number in Y, irrelevant for this discussion) and that's what gets printed, or where the read char is stored. The way you describe, that parameter would be a pointer (say, io_ptr) and will need another parameter (say, io_size). A 65C02 or later will easily use that instead for character devices, just replacing the appropriate LDA/STA io_c by a LDA/STA (io_c) (or [io_c] is on a 816).

While the addressing mode itself makes negligible overhead on the I/O functions (usually 2/3 extra clock cycles), the app code calling these functions will be heavier -- especially if the size parameter must be set for abstraction (does the app know if that device is character or block based? does it even know the device used?). For instance, a typical I/O call (printing a character) is now:

LDA #CR       ; will print a newline
STA io_c      ; store parameter
LDY iodev     ; set selected device
_KERNEL(COUT) ; macro is LDX #COUT plus JSR $FFC0
; this is 11 bytes, 16 cycles on a '02 system

while the same on a unified model will become:

LDY #<cr_byte ; get pointer address LSB
LDA #>cr_byte ; and MSB
STY io_ptr    ; store pointer word
STA io_ptr+1
STZ io_siz    ; let's assume 0 means single character
LDY iodev     ; select device as usual
_KERNEL(COUT) ; macro as above
; ...somewhere
.asc CR       ; the byte to be printed, somewhere (could be shared*)
; this takes 17+1* bytes, 24 cycles

...and could be worse if io_siz expects a 16-bit (or larger) amount. While the '816 might save some bytes and cycles via 16-bit transfers, the already discussed issue (see email) with pointers set from '02 code to '816 kernel will increase the overhead even more. From the receiving side (the kernel function), a simple LDA io_c for processing the char to be printed (2 bytes, 3 cycles) would become something like:

LDX run_arch   ; called from '02?
BEQ ok_24b     ; pointer already set in full
  PHB          ; if not, get current (in use by app) data bank
  PLX
  STX io_ptr+2 ; fill missing byte
ok_24b:
LDA [io_ptr]   ; get pointed byte and proceed as usual
; this takes 11 bytes and 13/22 bytes for '816/'02 calling code, resp.

...and the above code is incomplete as doesn't check for zero page pointers! While all of this is feasible, I don't think is worth it, even if "higher" CPUs would assimilate it with ease.