Re: [M16C-dev] (no subject)

[Grant Edwards]

> Probably on tuesday I will commit my current development version to CVS,
> in order to enable you to assess the situation. The assembler port is
> still missing many codes and variants, and I would very much appreciate
> some help on the linker. In my personal opinion, I would guess that the
> assembler and linker should be in a useful state before we start working
> on gcc,

In order to start work on a gcc port, the M16C port of gas
wouldn't have to be working as long as there was access to
another assembler that used the same mnemonics and operand
syntax.  One could do a GCC port with the ability to generate
two different "flavors" of assembly language for two different
assemblers -- some of the targets have that capability, and it
doesn't look like it would be too difficult.

That said, after studying the GCC internals documentation, I'm
not convinced that GCC is a viable option for the M16C.  GCC
has the requirement that all pointers be the same size.  This
would mean that GCC could only support two memory models:

 1) A "tiny" memory model where all pointers are 16 bits wide,
    and there is a single 64KB address space.  It might be
    possible to support a 64KB address space for data and a
    separate 64KB address space for code, but it looked
    unlikely to me.

 2) A "huge" memory model where all pointers are 32 bits wide.
    Since only 3 or 4 of the M16C instructions can operate on
    32 bit pointers, this would result in very inefficient code
    when handling data pointers (by far the most common case in
    most of the C code I've seen).
    
IMO, to be practical an M16C compiler must support a memory
model that uses 64-bit pointers for data and 32-bit pointers
for code.  This would allow for efficient use of the "near"
address space from 0x0000 to 0xffff for data, and still allow
code to reside at the other end of the address space.

After looking at GCC internals, I looked at several other
open-source compiler projects:

 LCC   http://www.cs.princeton.edu/software/lcc/

 SDCC  http://sdcc.sourceforge.net/

 VBCC  http://www.compilers.de/vbcc/ 

Of these, the last one looks like the best option for the M16C.

 1) Vbcc explicitly supports pointers of differing sizes.

 2) There's already a back-end for the C166, which has many of
    the same pointer size vs. memory model issues that the M16C
    has. 

VBCC would still something equivalent to "binutils" and I see
no reason not to use Gnu binutils.

The disadvantage to choosing something other than GCC is that
you loose access to the other GCC front ends (c++, fortran,
etc.).

-- 
Grant Edwards
address@hidden