J.C. Wren wrote:
> A number of C compilers on small architectures have solved this problem
by
> having 2, sometimes 4, distinct compiling
phases, and passing data
through
> temporary files. This gives you a lot more
leeway in code space. I've
seen
> preprocessor pass, tokenization pass, code
generator pass, and in some
cases,
> the 4th pass is the assembler (which I
generally prefer over
> direct-to-assembly, since you can insert a user-written processing phase
I ported Hendrix tiny C from my Imsai (CP/M version 1.4 actually) to a mini
computer that had no c support in the early 80's when it first came out.
If I recall it came in two passes as mentioned, and then an assembly, then
link.
There was a c library support as well.
I actually didn't to go assembly for the mini, but actually to an interpreted
language like Java uses now. I think I had to implement around 30 opcodes
total to implement the instructions used by the hendrix compiler. that means
that of all the 8080 instructions that the original hendrix compiler emitted,
there
were only 30 total used.
It supports a 16 bit address space natively, so would produce good code on
your HP.
A typical pass was as follows:
run C0 on the c source
run C1 on the result of C0
merge the source for the clib (which was earlier run thru C0 and C1) with
this output of C1.
Assemble the whole mess with an assembler that assembled to a
relocatable module.
take relocatable module, and use load command to suck into interpreter
on target machine (which was written in assembly).
I don't know about running in 32k. That probably would be tight to
run the compiler. I think the full C lib was around 24k long, but it may
have been smaller. Since i linked in the whole mess w/o any way to
pick and choose what was used vs what was not, it was allways
there regardless. A better linker and better way of merging in the
clib could fix that.
the machine I had had a symbolic assembler that was easy to gen up
the assembler used here w/o any work so I didn't optimize that at
all.
As to optimization, you do have to do some duplicate elimination,
but other than that, it produced pretty good code.
most of the work on the hendrix c compiler was to the C1 pass,
which emitted the 8080 instructions. I don't recall whether the
Hendrix Tiny C was orignally for the 8080 / CP/M environment,
or whether the published version was a port from some other
environment, but the one I worked from ran on either CP/M 1.4
or 2 or 3x cpm's. the clib was pretty brain dead.
Jim
