In the update I've submitted I've used the riscv symbol to identify code for the RISC-V CoPro target, but riscv is doing two tasks that should be split up.
It is used to indicate code that needs to target a RISC-V CPU (eg register sizes, etc.), and also code that needs to target a RISC-V CPU that is using the Tube/BBC API. (eg COLOUR should do vdu(17),vdu(n), etc.). These are two different things.
For instance, there is nothing to stop there being a RISC-V build that runs on a RISC-V running Linux. So it needs to use Linux calls not Tube/BBC calls. Similarly, there is nothing stopping an ARM build to run on ARM RISC OS, so again would need to use RISC OS (ie, near enough Tube/BBC) calls.
On other code I've worked on I've used a cpu symbol to indicate the CPU targetted (eg arm 8086 riscv) and a osapi symbol to indicate the API being targetted (eg unix dos win). I suggest riscv be reduced to just indicating CPU-specific code, and introduce another symbol to indicate the API being used.
In the update I've submitted I've used the riscv symbol to identify code for the RISC-V CoPro target, but riscv is doing two tasks that should be split up.
It is used to indicate code that needs to target a RISC-V CPU (eg register sizes, etc.), and also code that needs to target a RISC-V CPU that is using the Tube/BBC API. (eg COLOUR should do vdu(17),vdu(n), etc.). These are two different things.
For instance, there is nothing to stop there being a RISC-V build that runs on a RISC-V running Linux. So it needs to use Linux calls not Tube/BBC calls. Similarly, there is nothing stopping an ARM build to run on ARM RISC OS, so again would need to use RISC OS (ie, near enough Tube/BBC) calls.
On other code I've worked on I've used a cpu symbol to indicate the CPU targetted (eg arm 8086 riscv) and a osapi symbol to indicate the API being targetted (eg unix dos win). I suggest riscv be reduced to just indicating CPU-specific code, and introduce another symbol to indicate the API being used.