This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BITS_PER_UNIT issue in port....

On 12/08/2016 01:37 PM, Steve Silva wrote:

I was not sure where to look but I thought I would try this.  I am in
the middle of porting GCC 6.2 to an internal processor we are
experimenting with.  I have about 2 months into it and I have made
some decent progress.  The biggest issue I have right now is that our
processor does not use 8 bit bytes but 16 bit bytes.  When I try and
set BITS_PER_UNIT to 16, GCC will not compile because some of its
internal structures become too big for the host platform.  Our
processor only needs to support QI (16 bits) and HI (32 bits) modes;
we don't really need anything SI or bigger.  I really don't want to
hack on the GCC source code unless I am forced to, I would prefer to
stay in the machine dependent realm.  Also, we are only using the "C"
front end.  So I have the following questions:

1.  Is it possible to set BITS_PER_UNIT to 16 at all?  If so, How?
I thought we had targets that did this in the past. In theory it should be possible, but it's certainly not something that's done with any regularity or something that is tested. It is highly likely that you'll run into various assumptions throughout GCC that BITS_PER_UNIT is 8.

Is there a minimum number of registers GCC has to have to work
correctly?  What is that minimum?
It depends on the structure of your register file. If (for example) you have address and data registers, you'll likely need at least 4 address registers (stack pointer, frame pointer, 2 for the compiler to use in code generation). You'll likely need 2-4 data registers.

If you have general purpose registers, then ~6 ought to work (frame pointer, stack pointer, 4 for code generation.

To some degree this will depend on things like your ABI, whether or not you have registers that have specialized uses, etc.

Folks have done ports on more constrained targets. If you have zero page addressing, you could use zero-page memory locations as an extended register file. Or you could look at the rl78 port which defines a set of virtual registers, then packs those down to the even more limited processor registers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]