Re: Questions about the new M32C target

[DJ Delorie <dj@redhat.com>]

> 1. Does anyone know if or when there will be a libc supporting this
> target, and which one that will be (newlib?)?

newlib/libgloss patches are next on my list.  There's a simulator and
gdb port on the way too.  I have a couple of hardware boards as well,
which I'll use for testing and whatnot.

> 2. After building the compiler, I can create object files but not
> executables. ld claims there are linker scripts missing (the files ld
> wants are r8c.ld, m16c.ld and m32c.ld, depending on CPU). Will these
> be added to gcc or are you supposed to write your own?

They'll be in libgloss.  I just got the word on copyrights (BSD) and
need to hook in the init-ram-from-rom stuff.

> 3. There has been a project to add M16C support to gcc, but it was
> apparently abandoned because the M16C architecture has two different
> addressing modes, while gcc presumably does not support different
> pointer sizes. See this discussion for details:
> http://lists.gnu.org/archive/html/m16c-dev/2003-11/msg00001.html
> 
> How has this issue been addressed in the current version?

The problem is that gcc doesn't support two different pointer widths
*in the same compilation*.  So, I made it a command line option which
to use.  I started a couple of threads about single-pointer
assumptions in gcc back when I discovered that.

R8C and M16C modes (-mcpu=r8c, -mcpu=m16c) use 16 bit pointers.  The
M16C allows code to live outside the first 64k; the linker generates
call thunks to accomodate requests for 16 bit pointers to them.

M32CM and M32C modes (-mcpu=m32cm, -mcpu=m32c) use 24 bit pointers in
a 32 bit word (PSImode), but a 16 bit "size_t".  It's a little weird
but results in the best overall code.

The assembler has %dsp8() and %dsp16() modifiers for disp[a0] type
addressing for when you know that the variable is in the first 256 or
64k bytes, but gcc does not currently use them.  I'm hoping at some
point in the future to add linker relaxing so that these will be used
automatically.