Re: BITS_PER_UNIT larger than 8 -- word addressing

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Boris Boesler]

On 2007-11-27 18:29, Michael Eager wrote:
 > Joseph S. Myers wrote:
 > > On Tue, 27 Nov 2007, Michael Eager wrote:
 > >
 > >> I think that there is a pervasive understanding that SImode is
 > >> single precision integer, 32-bits long.
 > >
 > > Only among contributors not considering non-8-bit bytes.  SImode  
is 4
 > > times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at  
least not be
 > > particularly usable, much like the limitations on TImode on 32-bit
 > > targets) with large BITS_PER_UNIT.
 >
 > I think you just described the majority of contributors.  :-)
 >
 > It's human nature not to recognize one's tacit assumptions or their
 > consequences.

  I assume that GCC internals assume that memory can be byte (8 bits)  
addressed - for historical reasons. Therefore, the sizes of all types  
are multiples of a byte. The same is true for addressing values in  
memory. (Sizes of types and their addresses must be separated more  
precisely. A 32 bit value could be on a 4 bit boundary!) But this is  
changing. Addressable units are on 32 bit boundaries or even on 4 bit  
boundaries today. Well, this is the problem I'm running in right now.

Boris

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Ian Lance Taylor]

Boris Boesler <baembel@gmx.de> writes:

>   I assume that GCC internals assume that memory can be byte (8 bits)
> addressed - for historical reasons. 

No.  gcc internals assume that memory can be addressed in units of
size BITS_PER_UNIT.  The default for BITS_PER_UNIT is 8.  I have
written backends for machines for which that is not true.

It is unusual, and there is only one official target with
BITS_PER_UNIT != 8 (c4x), so there is often some minor breakage.

Ian

BITS_PER_UNIT less than 8 (was: Re: BITS_PER_UNIT larger than 8 -- word addressing)

[Boris Boesler]

Am 05.12.2007 um 22:32 schrieb Ian Lance Taylor:

> Boris Boesler <baembel@gmx.de> writes:
>
>>   I assume that GCC internals assume that memory can be byte (8 bits)
>> addressed - for historical reasons.
>
> No.  gcc internals assume that memory can be addressed in units of
> size BITS_PER_UNIT.  The default for BITS_PER_UNIT is 8.  I have
> written backends for machines for which that is not true.
>
> It is unusual, and there is only one official target with
> BITS_PER_UNIT != 8 (c4x), so there is often some minor breakage.

  Ok, so what have I to do to write a back-end where all addresses  
are given in bits? Memory is addressed in bits, not bytes. So I set:

#define BITS_PER_UNIT 1
#define UNITS_PER_WORD 32

(As far as I can see, offsets are divided by BITS_PER_UNIT, so this  
seems to be a precondition for bit addressing.)

  All sizes and and boundary are set to 32. SImode is only four bits  
wide, so I added the integer modes OI and XI:
INT_MODE(OI, 32)
INT_MODE(XI, 64)

  In builtin_define_type_max I added the case "1", which will return  
without doing anything.

  Without these changes the compiler stops with internal error  
mesages. With these changes gcc/cc1 generates a bus error.

So, what can I do to get this running for my architecture?

Thanks in advance,
Boris

Re: BITS_PER_UNIT less than 8 (was: Re: BITS_PER_UNIT larger than 8 -- word addressing)

[Ian Lance Taylor]

Boris Boesler <baembel@gmx.de> writes:

>   Ok, so what have I to do to write a back-end where all addresses
> are given in bits?

That's kind of an extreme case.  But it sounds like you are following
the right approach.

>   Without these changes the compiler stops with internal error
> mesages. With these changes gcc/cc1 generates a bus error.
> 
> So, what can I do to get this running for my architecture?

Well, you have to look at the generated code, find out where it is
wrong, and fix it.  There is no royal road to success.  It's always
hard to write a new gcc backend.  And since your backend is so
unusual, it's likely to be unusually hard.

Ian

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Joseph S. Myers]

On Fri, 30 Nov 2007, Michael Eager wrote:

> There's also __mode__ (__SI__) in include/sys/types.h

Not in GCC.  I don't know about the portability assumptions of newlib.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Michael Eager wrote:
> Joseph S. Myers wrote:
>> On Tue, 27 Nov 2007, Michael Eager wrote:
>>
>>> I think that there is a pervasive understanding that SImode is
>>> single precision integer, 32-bits long.
>>
>> Only among contributors not considering non-8-bit bytes.  SImode is 4 
>> times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not 
>> be particularly usable, much like the limitations on TImode on 32-bit 
>> targets) with large BITS_PER_UNIT.
> 
> I think you just described the majority of contributors.  :-)

> It may be that my current problem is limited to unwind-dw2.c.
> If so, then I may be able to work around it by simply not building it.

There's also __mode__ (__SI__) in include/sys/types.h
where it's used to define _ST_INT32.  The comments are
interesting:  This is meant to insure that the stat
struct layout doesn't change when sizeof(int) changes,
but forgets that SI not always 32 bits.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Michael Eager wrote:
> 
>> I think that there is a pervasive understanding that SImode is
>> single precision integer, 32-bits long.
> 
> Only among contributors not considering non-8-bit bytes.  SImode is 4 
> times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not be 
> particularly usable, much like the limitations on TImode on 32-bit 
> targets) with large BITS_PER_UNIT.

I think you just described the majority of contributors.  :-)

It's human nature not to recognize one's tacit assumptions or their
consequences.  It's also normal for people to focus on what they are
working on and pay far less attention to other targets.  Since there
is no working and supported 32-bit word-addressed target, there's
little to alert anyone that one of their assumptions is not valid.

It may be that my current problem is limited to unwind-dw2.c.
If so, then I may be able to work around it by simply not building it.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Joseph S. Myers]

On Tue, 27 Nov 2007, Michael Eager wrote:

> I think that there is a pervasive understanding that SImode is
> single precision integer, 32-bits long.

Only among contributors not considering non-8-bit bytes.  SImode is 4 
times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not be 
particularly usable, much like the limitations on TImode on 32-bit 
targets) with large BITS_PER_UNIT.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Joseph S. Myers wrote:
> On Mon, 26 Nov 2007, Michael Eager wrote:
> 
>> Well, can't do that.  This is not target dependent.
>> DImode gets defined, and used, for long long in unwind-dw2.c.
> 
> Is it defined what DWARF unwind information looks like when made up of 
> bytes wider than 8 bits?  Certainly GCC's code won't allow for it at 
> present.

I expect that the unwind code is broken unless long long is 8 bytes.
IIRC, unwind confuses host and target integer sizes.

> The string handling code is a major area which doesn't allow for target 
> and host bytes being different.  But everything target-independent 
> hardcoding integer modes wider than QImode is potentially wrong; with wide 
> bytes, many of those modes may not exist.

IMO, it looks like the absence of a supported 32-bit word-addressed
target let the support for BITS_PER_UNIT != 8 fall into disrepair.

I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Joseph S. Myers]

On Mon, 26 Nov 2007, Michael Eager wrote:

> Well, can't do that.  This is not target dependent.
> DImode gets defined, and used, for long long in unwind-dw2.c.

Is it defined what DWARF unwind information looks like when made up of 
bytes wider than 8 bits?  Certainly GCC's code won't allow for it at 
present.

The string handling code is a major area which doesn't allow for target 
and host bytes being different.  But everything target-independent 
hardcoding integer modes wider than QImode is potentially wrong; with wide 
bytes, many of those modes may not exist.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Richard Sandiford]

Michael Eager <eager@eagercon.com> writes:
> Ross Ridge wrote:
>> Miceal Eagar writes:
>>> I'm working with a target that has 32-bit word addressing,
>>> so there is a define of BITS_PER_UNIT = 32.
>> 
>> According to the documentation, this changes the size of a byte to 32
>> bits, instead of the more usual 8 bits.
>> 
>>> This causes a problem:  an error saying that there is
>>> no emulation for 'DI'.  DImode has a precision of 128 bits,
>>> which is clearly incorrect.  (All the other integer modes
>>> were incorrect as well.)
>> 
>> DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect
>> it to be 256 bits.  Trying use QImode and HImode for 32-bit and 64-bit
>> operations respectively.
>
> Well, can't do that.  This is not target dependent.
> DImode gets defined, and used, for long long in unwind-dw2.c.

But like Ross says, DImode is 256 bits, so its unwind-dw2.c that
needs to change.

(FWIW, I remember testing c4x for some pan-target changes after it was
slated for removal, and I just disabled the unwinding stuff.  Most other
things seemed to work fine.)

Richard

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Ross Ridge wrote:
> Miceal Eagar writes:
>> I'm working with a target that has 32-bit word addressing,
>> so there is a define of BITS_PER_UNIT = 32.
> 
> According to the documentation, this changes the size of a byte to 32
> bits, instead of the more usual 8 bits.
> 
>> This causes a problem:  an error saying that there is
>> no emulation for 'DI'.  DImode has a precision of 128 bits,
>> which is clearly incorrect.  (All the other integer modes
>> were incorrect as well.)
> 
> DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect
> it to be 256 bits.  Trying use QImode and HImode for 32-bit and 64-bit
> operations respectively.

Well, can't do that.  This is not target dependent.
DImode gets defined, and used, for long long in unwind-dw2.c.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Ross Ridge]

Miceal Eagar writes:
>I'm working with a target that has 32-bit word addressing,
>so there is a define of BITS_PER_UNIT = 32.

According to the documentation, this changes the size of a byte to 32
bits, instead of the more usual 8 bits.

>This causes a problem:  an error saying that there is
>no emulation for 'DI'.  DImode has a precision of 128 bits,
>which is clearly incorrect.  (All the other integer modes
>were incorrect as well.)

DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect
it to be 256 bits.  Trying use QImode and HImode for 32-bit and 64-bit
operations respectively.

					Ross Ridge

BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

I'm working with a target that has 32-bit word addressing,
so there is a define of BITS_PER_UNIT = 32.

This causes a problem:  an error saying that there is
no emulation for 'DI'.  DImode has a precision of 128 bits,
which is clearly incorrect.  (All the other integer modes
were incorrect as well.)

DI is defined in machmode.def as
   INT_MODE (DI, 8).

This is sort-of correct, DI is an 8 byte or 2 word value.

When this is used to generate insn-modes.c, its size is
generated as 8*BITS_PER_UNIT, not 2*BITS_PER_UNIT,
because, it seems, genmodes assumes that size in bits is
is bytesize*BITS_PER_UNIT.  In emit_mode_precision() in
genmodes.c the assumption is pretty clear.

I built the c4x target, since that's the only example of
a target with BITS_PER_UNIT set.  It looks like this target
is defunct and slated for removal.  It gets the same error.

If BITS_PER_UNIT should alway be bytesize, then it seems
unnecessary to have the definition of BITS_PER_UNIT.  Or
it looks like genmodes.c needs to have another define,
BYTES_PER_UNIT, so that it can correctly convert from
bytesize to the number of units for the target.  Or the
definition of integer sizes should be directly in bits,
without any reference to bytesize.

Is there a different way to define word-addressed targets?
Or should I just pretend it has byte addressing?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077