[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [M16C-dev] Re: Binutils + GCC port

From: Grant Edwards
Subject: Re: [M16C-dev] Re: Binutils + GCC port
Date: Thu, 6 Nov 2003 09:20:37 -0600
User-agent: Mutt/1.4.1i

On Thu, Nov 06, 2003 at 11:11:47AM +0100, Dr. Manuel Kessler wrote:

> > Right -- pointer arithmetic would require two instructions:

> Well, that depends on the specific CPU. You are correct for
> the /60, /62 /20 etc. series, while for the /80 series
> (M16C/80 and M32C/8x), A0 and A1 are 24 bit each, such that a
> single instruction is sufficient. Furthermore, simple indirect
> addressing with [A0/A1] works for nearly all instructions.

You're right, I was looking at documentation for the 60 series.
It sounds like code generated for the 80 series could be much
better than code for the 60 series. 

>> I looked at the machine description stuff briefly, and it
>> didn't appear that you knew what pointer type you were
>> generating code for.  The patterns were matched based on the
>> data size and wether the quatity was signed or not.  When I
>> was looking at the docs for vbcc, it was apparent in the
>> machine description interface that the pointer's type was
>> available to the back end, and it was possible to define
>> pointer sizes to be different.
> Yes, but the selection could be very simple: Choose 24 bit for
> code accesses (jumps and branches), but 16 bit for data
> accesses (load, store, ALU). Therefore the pattern itself is
> aware of the necessary size.

If the pattern can tell whether the pointer is to data or code,
then it should be possible to do sort of a "medium" model.
AFAICT, you'd still have to allocate 32-bits for storing a data
pointer, but you would have the option of generating code that
used it as a 16-bit pointer.

> > We've ended up choosing the H8 over the M16C for reasons other
> > than gcc support (though that's a happy bonus!), so I probably
> > won't be spending much more time with the M16C architecture.
> Sorry to hear that. However, I acknowledge the need for a
> working solution, and waiting for some unknown time is not a
> viable approach for most products.

gcc support wasn't a big reason to choose the H8 over the M16C,
it was mostly price.

Grant Edwards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]