Re: architecture.md static/dynamic loaded drivers

[sam-falvo]

I'd like to talk more about this. For a CPU like the 6502, static driver allotment is perfectly adequate; but for something larger like x86 or RISC-V, it's going to be too limiting. I think putting some thought into this ahead of time, even if not implemented in the smaller OS configurations, is worth the time investment.

[zuiko21]

You're right. As the docs say:

Details for passing the allocated space pointer to the asking driver are TBD

Well, let's determine them now :-) While keeping things within reach of 65xx processors, I can think of two ways of doing this:

• Write drivers with absolute addressing from 0 (forcing the high byte, not using zero-page opcodes) and then letting the OS relocate such references while loading the driver into RAM. This will bring the highest performance, once running, but I currently have no relocation code at all (although it's on the to-do list)
• Write drivers using indirect-indexed addressing, preloading Y with the targeted variable offset; the required pointer already has a zeropage location for it (sysptr, reserved for interrupt use!). The ISR will load this pointer from whatever allocation table it keeps prior to calling such driver's interrupt task.

The last approach seems pretty interesting. It impairs performance a bit (and driver code will be a bit bigger) but within reason; and can be implemented right now with moderate effort. Would be the first step for loadable on-the-fly drivers.

Naturally, these are implementation details. The extra performance needed (both speed and memory) seems within reach of all but the smallest systems. In any case, if I can't afford such procedures, a particular kernel could just keep doing things the old way, rejecting any driver specifying more than 0 dynamically allocated bytes and thus limited to statically allocated drivers (or those using no variables, rare but possible)

[sam-falvo]

On Tue, May 9, 2017 at 3:27 AM, Carlos Santisteban ***@***.***> wrote: Write drivers with absolute addressing from 0 (forcing the high byte, not using zero-page opcodes) and then letting the OS relocate such references while loading the driver into RAM. This will bring the highest performance, once running, but I currently have no relocation code at all (although it's on the to-do list)

There is a third option: write your driver as you normally would, using zero-page locations starting from 0. But, for each zero-page reference you make, keep a record of its address, so that a fix-up routine can add a necessary constant to relocate the address. NOTE: This requires the driver to exist in RAM, since we'll be patching code. This is, in a more crude way, exactly what the o65 loader format provides. This obviously won't work for ROM-resident code except for statically-linked modules.

Naturally, these are implementation details. The extra performance needed (both speed and memory) seems within reach of all but the smallest systems. In any case, if I can't afford such procedures, a particular kernel could just keep doing things the old way, rejecting any driver specifying more than 0 dynamically allocated bytes and thus limited to statically allocated drivers (or those using no variables, rare but possible)

The 68000, RISC-V, and other larger CPUs all provide (usually) some mechanism to support both PC-relative addressing as well as base+offset addressing that obviates the need to keep track of too many relocations. Especially the RISC-V architecture, all branches are PC-relative (except for register-indirect jumps), and all data references are biased by a register of your choice. There are no absolute addresses at all in RISC-V assembly language. At least with the 65816, you assign a unique direct-page block for a given device driver.

…

-- Samuel A. Falvo II