This is the mail archive of the
mailing list for the GCC project.
Re: BITS_PER_UNIT issue in port....
- From: Jeff Law <law at redhat dot com>
- To: Steve Silva <stv_007 at yahoo dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 9 Dec 2016 13:07:25 -0700
- Subject: Re: BITS_PER_UNIT issue in port....
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
On 12/08/2016 01:37 PM, Steve Silva wrote:
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.
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?
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.
Is there a minimum number of registers GCC has to have to work
correctly? What is that minimum?
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