#882 r800 port (to generate better code for R800, Z280)
The R800 is a badly documented CPU that hasn't seen much use. It is mostly known for its use in the MSX Turbo-R computers, which AFAIK didn't achieve the popularity of their predecessors. Still, they are known and targeted in the retrocomputing scene.
The instruction set is a binary compatible superset of the official Z80 instruction set and a binary compatible subset of the Z280 instruction set. A r800 port would thus benefit both R800 and Z280 users (since we currently do not have a z280 port, and creating one would be substatially more effort than an r800 one).
IMO, it could make sense to have this port as it shouldn't be too much effort, and both R800 and Z280 users benefit.
Original documentation for the R800 is available in Japanese only. From the existing English texts on the net, the R800 apparently:
- Supports the official Z80 instructions
- Supports the iyl/iyh/ixl/ixh instructions (unofficial on Z80, official on eZ80 in Z80 mode)
- Supports a few of the Z280 multiplication instructions (those at opcodes ed c3, ed f3, ed c1, ed c9, ed d1, ed d8).
- Executes instruction in fewer cycles than Z80.
For documentation, there are e.g https://archive.org/details/MsxTurboR/page/n173/mode/2up, https://map.grauw.nl/resources/z80instr.php and the Z280 preliminary technical manual.
For consistency I suggest to just use the Z280 mnemonics for the multiplication instructions.
The steps to create this port would be:
0) Create r800 branch in svn
1) Add support for a new .r800 directive in the assembler, to switch to the R800 instruction set.
2) Add support for the R800 in ucsim. This would be selected by a new R800 option argument to the -H option.
3) Create r800 port infrastructure (i.e. in src/z80/main.c, configure.ac, src/port.h, src/SDCCmain.c), for now still using the z80 library.
4) Add new r800_cycles parameter to cost2 function in src/z80/gen.c, put the appropriate number of cycles it takes for the instruction to execute on the R800 at each call to cost2. Check all calls to cost to ensure that they report the correct number of cycles for R800, too.
5) Add support for the multiplication instructions (similarly to how we already handle the z180 and r2k ones).
6) Add a regression test target in support/regression/ports.
7) Debug until regression tests pass.
8) Merge r800 branch to trunk.
9) Enable nightly regression testing for r800 port.
10) Check if we want to make changes to the peephole optimizer rules, and if yes, do so.
11) Create r800 library (just copy the z80 one, then replace -mz80 by -mr800, possibly look at mul.s and mulchar.s functions to see if it makes sense to reimplement them as for z180 or partially remove as for r3ka) and use it for r800.
I would help with the effort, but mostly on the compiler side (i.e. not with 2) and 10)). Others would have to help (e.g. by contributing patches).
Diff:
Diff:
I've created an r800 branch, and a separate feature request [feature-requests:#885] for the simulator.
P.S.: The r800 branch now contains a prototype of the r800 port. Many parts are still missing, but it should generate correct code for R800 (and make use of the iyl/iyh instructions, and even use the multu instruction once in a while).
Related
Feature Requests:
#885Last edit: Philipp Klaus Krause 2023-07-28
Diff:
A first version of assembler support now exists in the r800 branch. This assembles fine:
By now the r800 branch passes nearly all regression tests. multu (but not yet multuw) is used by r800 code generation.
We might want to merge it to trunk soon, to get more testing by users.