Hello, On Thu, 16 Sep 2021, Richard Biener via Gcc-patches wrote:
> > Typically for the native_interpret/native_encode we punt if > > BITS_PER_UNIT != 8 || CHAR_BIT != 8 because nobody had the energy to > > deal with the weird platforms (especially if we have currently none, I > > believe dsp16xx that had 16-bit bytes had been removed in 4.0 and c4x > > that had 32-bit bytes had been removed in 4.3) - dunno if the > > DEFERRED_INIT etc. code has those guards or not and it clearly > > documents that this code is not ready for other configurations. A byte > > is not necessarily 8 bits, that is just the most common size for it, > > and TYPE_SIZE_UNIT is number of BITS_PER_UNIT bit units. > > OK, I'll do s/8/BITS_PER_UNIT/ - I also see that we have > int_size_in_bytes returning TYPE_SIZE_UNIT and that TYPE_SIZE_UNIT is > documented to yeild the type size in 'bytes'. For better or worse GCCs meaning of 'byte' is really 'unit'; I guess most introductions of the term 'byte' in comments and function names really came from either carelessness or from people who knew this fact and thought it obvious that 'byte' of course is the same as 'unit', but not the same as octet. FWIW: (for GCC) both mean the smallest naturally addressable piece of memory (i.e. what you get when you increase an address by 'one'), and that is not necessarily 8 bit (but anything else is bit-rotten of course). As modern use of 'byte' tends to actually mean octet, but old use of byte (and use in GCC) means unit, we probably should avoid the term byte alltogether in GCC. But that ship has sailed :-/ > I do believe that we should officially declare hosts with CHAR_BIT != 8 > as unsupported and as you say support for targets with BITS_PER_UNIT != > 8 is likely bit-rotten. (And characters are still something else entirely, except on those couple platforms where chars, units and octets happen to be the same :) ) But yes. Ciao, Michael.
