11 May
2005
11 May
'05
11:10 a.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.
Agreed. But these sizes would lead to bloated PDP-8 code for simple
operations, which in turn would mean you could get almost nothing useful
done in 4Kw. Average data size around 2 words makes this worse, too.
Witness the complexity of the largest Focal 69 programs that can be fit in
4K. There's only so much you can do in the space available. Here the
reason for the space constraints would be different (the co-resident code is
run-time libraries instead of the interpreter), but I suspect the result
would be similar.
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).
I think the challenges would be to determine when recursion is actually
used, etc. Otherwise, the entry and exit from subroutines will be expensive
(especially if you are calling a heap allocator).
I actually think the task is only manageable if you virtualize a processor
that is more amenable to C. Which is also time-inefficient, but could
potentially be at least a little more space-efficient. (Maybe a 24-bit two
operand machine? Or something like a Nova, but 24 bit?)
Don't ask me to write the floating point library,
though...
That shouldn't be that bad; there are plenty of floating point routines
around for the PDP-8.
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.
I think the broken code in the world is either too large for the PDP-8, or
small enough to fix :-).
Vince