Questions about the new M32C target

Questions about the new M32C target

[glagnar]

Hi everyone,

I was excited to find out that gcc now supports the Renesas M16C/M32C
architecture. I have compiled binutils and gcc from the CVS sources.
However, there are several questions that I have:

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

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?

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?

Thanks

Re: Questions about the new M32C target

[DJ Delorie]

> 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.