10 May
2005
10 May
'05
3:50 p.m.
I don't expect to ever see a true C compiler for
the PDP-8. The lack of
stacks, etc. are easily gotten around, but the 12 bit word size isn't. On a
PDP-8, a short (or a pointer, for that matter) would have to be 2 words (and
a long would be 3). The C data types just don't fit efficiently into 12 bit
words. So writing a C compiler would be difficult, and the resulting code
would be horrible (at least by PDP-8 standards) :-).
The C data types only have minimum sizes. Actual sizes are up to the
implementation.
The resulting C data types for a PDP-8 would be 12-bit char, 24 bit
short and int, 36 bit long. As long as limits.h contains the correct
values and the sizeof() operator correctly returns 1, 2 and 3 for the
above. I'd go with 12 bits pointers for a start, you could also make
a "large model" compiler to use more than 4k. I'd put declared autos
in the current page and expand the address to 12 bits if it get stored
in a pointer or the routine gets too large. Passed parameters could be
zero page, and it would be up to the caller to save ones that they
need later. (Yes, there really doesn't need to be a stack. You can
do variable size local allocations on the heap.) All in all, a cross
compiler built from LCC should be a doable task (although there will
be some 32-bit assumption issues). It's certainly easier than
building a mixed-model 8086 compiler (as there is less garbage to deal
with).
Don't ask me to write the floating point library, though...
The only real problem is that too much C code floating around assumes
that CHAR_BIT==8 and that sizeof(void *), sizeof(int) and sizeof(long)
are equal to each other. It would still compile and run, since you
can convert a 12 bit pointer to a 24 bit int and back with no loss.
It wouldn't be efficient, though.
Eric