Announcement, Jun update on FPGA Transputer

Announcement, Jun update on FPGA Transputer

Post by JJ » Tue, 07 Jun 2005 06:59:11


Jun 5th update

I am now routinely passing the new Transputer C compiler through itself
to generate directly the asm to be run on the FPGA cpu ISA simulator.
There are several intermediate stages, RPN and then linear code output
as raw prefixed codes with some peephole optimizations at each pass.

At this point the C control flow and C expression results look pretty
good but still lots of work to do. I still have to do the name
scoping-mapping to register/workspace names, switch blocks, function,
some ptr stuff and a myriad of other small details.

In order to make progress quickly, I will refrain from making the
compiler true C leaving more abstract types till later and maybe take
as many shortcuts as needed till the compiler output looks valid. I am
removing use of C features in the source that have no way to get
immediately translated so the C level is falling back some towards BCPL
semantics.

While it is possible to hand check emitted asm for a page or 2 of
output, it gets tedious real quick. When I believe the whole results
could be largely correct, I will run the emmited compiler on the ISA
simulator to further debug that, and when that is valid, run the
compiler source through the ISA simulator hosted compiler to see if
that emits the same as itself. The ISA simulator runs around 30Mips so
is only a few times slower than real HW is expected to be for 1 PE.

When that is done, I can take a long break from SW and get back into
FPGA and MMU HW design. In effect the compiler becomes the primary test
program for the cpu design as well as a necessary tool to have to write
any test programs at all. When the HW actually boots, I can resume the
compiler or hand it off.

I am wondering if other compilers can be ported by having them
recompile them selves to a lower level C form or whatever (early
Cfront). Having the common form at a very low asm level means having to
figure other peoples backends.

What do compiler writers use as an open intermediate form? I get the
impression gcc keeps that internal form closed off. I heard the RTL
term used but I usually use that in the HW sense (register transfer
level ie pipelines).

I think I suggested before that occam could be used as the internal
language built by any language compiler with a sneak path right into
that, with asm on the other side.

// mono spacing


/-------/-------------/--------------->
C/C++/.....-->occamN/RPN ---> asm_raw-->binary--->
occam{}----------/ /
asm {}-------------------------

This has the advantage that you can still input and output occam for
program manipulation purposes but use C or occam syntax for initial
source capture.

It might make sense when I get to add the occam features !?
chan,alt,par etc to restructure the internals to use an occam like bin
tree then convert that to RPN and so on. That makes it easy to add
other front ends and gives back the occam input & output options.



In late april/early may I was pretty busy writing the paper I hope to
give in sep (funny thing it turned out to be 42 pages long). One good
result of that is that I learnt OpenOffice is pretty neat, and has good
pdf and html output. At some point the paper can go straight on the web
but I have to fix the ascii graphics 1st, they come through html in
wrong font.

The other aspect of writing the paper is that several cpu details got
really worked through, the function fp