Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
6502.py , 6809.py, 68000.py, etc.
#2
The approach for this is to use only one main executable, which loads the corresponding libraries. This is the way ZX Basic is designed. So you should use something like:
Code:
zxb.py --arch=<architecture name>
This way, you can produce an output for different architectures from a single compiler.
The compiler then loads the "backend" (the part of the compiler which translates from "Intermediate representation" to machine code of the target architecture), which should be, in these case, python modules like yours. This is not an easy task, though:
  • Target architecure might have a different CPU (e.g. other than Z80, like 68k)
  • Even if the target platform happens to have the same CPU the hardware and memory organization might be different. You will need to rewrite input/output (keyboard, cassete, screen, joystick) asm library routines (you can save time using the one provides by the BIOS/ROM or a prebooted OS, but this might introduce other problems, like Floating Point in ZX Basic being slower and requiring some fixed RAM positions, etc...)
  • To run in a target emulator/real machine, the output file format must be generated accordingly (thousands of them, completely different and VERY BAD documented).
So this is a titanic task. Even worse, as I started ZX BASIC as a toy compiler, some of these layers are not completely well designed. This is why I've thinking in rewriting some of them from scratch or even the compiler entirely. At the moment, only the zxbasm (the assembler) and zxbpp (the preprocessor) are completely independant and designed "correctly enough".

Other layers has too much interdependences with each others or with the target architecture (Speccy), which means that changing them is very hard without affecting the whole compiler. This is what I've been working out these days...
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 1 Guest(s)