Re: Porting gcc

[jfox@xxxxxxxx (Jeff Fox)]

Dear MISC readers,

It has been a number of years now since I looked into the idea of
using gcc with F21.  I like the idea very much and learned enough
to study the target representation and overall environment a little.
I was not nearly as familiar with the machine and writing code and
writing compilers for it at the time as I am now.

I was stopped by the need for me to do other things and my limited
experience with that environment.  It did seem to me that there were
plenty of warnings right up front in the gcc descriptions.  Maybe this
was before it was changed for embedded application use because one
of the warnings up front was that the target should be at least 4M byte.

It also warned that the target should provide byte addressing and that
the word length should be a multiple of eight bits.  To me that sounded
like three strikes right there.  We have 1M 20 bit words.  

In machine Forth or in ANS it is easy to say that cells and characters 
are any size you want but it seemed that gcc was not as tolerant of
a machine with less than 4M byte of non-byte addressable 20 bit words.
Since I had not generated any code actually run on an F21 I was also
concerned about the fact that in a cross compiler you will have to
exclusive or data and addresses with some mask of AAAAA.  However 
that has proven to be a very minor factor in any of our compilers
at iTV or Ultra Technology.

I would think that for a gcc port or any other C or whatever
compiler that some design decisions must be made upfront such as
whether the code will run in SRAM, DRAM, or a combination.  Will
you use a compiler directive to set the homepage bit for the 
compiler.  Remember that homepage mode branches mean different things
depending on the homepage bit in the address configuration register
at runtime.  But when compiling you must assume the bit is set a
particular way.

There are five possible branching methods:

10 bit page onpage branch opcode in slot 1
14 bit page onpage branch opcode in slot 0
14 bit page homepage branch opcode with homepage at start of SRAM or DRAM
long branch macros w/ 20 bit range in form of # push ;
extra long branch macros w/ 21 bit range in form of # com push ;

You don't need extra long branches if you don't have SRAM or intend
to branch to SRAM but only return from SRAM to DRAM and never branch
that way and with homepage in SRAM.

Some of our assemblers and compilers support SRAM branching others do
not.

These can easily be made transparent in the assembler or code generator
but one should be able to choose at compile time whether the code
should be for homepage at 0 in DRAM or at the start of fast SRAM 140000.

SRAM is only 16K words but fast.  DRAM is 1M word with 1K cache like 
pages and it is not all the same.

If homepage is in DRAM then 0-3FFF becomes more valuable real estate
because it can be branched to by a single cell 14 bit homepage branch
opcode rather than a two to four cell macro. Then 4000-7FFF will be
the next most valuable because code there can branch to anywhere from
0 to 3FFF via homepage or 4000-7FFF via 14 bit onpage single word
opcodes rather than longer less dense and slower multiple word macros.

8000-BFFF can not branch to 4000-7FFF without the use of a multi
word macro but it could still get to 0-3FFF using homepage or
8000-BFFF using the 14 bit page mode.

If you are compiling inlined native code sequences then often you
can use slot 0 for an opcode and compile a 10 bit onpage branch
opcode.  If the branch is on the same 10 bit page it will execute 
about three times faster whether it is a 10 or 14 bit type opcode.
The memory management unit inserts the RAS signals when it 
sees the DRAM page address changing.  RAS signals are not important
to the compiler writer, except that one should understand that
the DRAMs sort of act like cache and run about three times faster
if you stay on the same 10 bit page.  Offpage access is slow so
you want to take this into consideration in the design of code
or code generators.

MISC machine Forth programmers or compiler writers also need to
remember that registers are 21 bits wide while memory is 20 bits
wide.  The most significant bit is either carry or bit 20 in a 21
bit math operation or the SRAM/ROM addressing bit.  You must
set this carry bit to generate an SRAM or ROM or register address.
This bit is always set to 0 by a load from memory but it may be
changed by various CPU instructions.  When generating code
sequences you must take this into consideration.  You have to
be careful with that bit.  We have 21 bit machine Forth with
20 bit memory and 21 bits of memory addressing.  Math and
logic on negative numbers can cause addressing problems if you
are not careful.

Anyway that's my thoughts on some of the basic conceptual issues
that must be kept in mind when approaching the problem of a MISC
port of gcc or C or whatever.

I suspect that code sequences posted in MISC might get optimized
by readers and that there might be some takers for writing the
functions and libraries etc.

One big advantage now is that there are object code simulators
available that permit examination of code sequences up close so
that cross compiler functionality can be verified without MISC
hardware.

Jeff Fox


Jeff Fox              jfox@dnai.com    
Ultra Technology Inc. http://www.dnai.com/~jfox/