This is the mail archive of the gcc@gcc.gnu.org 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: How to define a built-in 24-bit type?


Joseph S. Myers wrote:
> On Fri, 20 Jan 2012, Georg-Johann Lay wrote:
> 
>> Hi.
>>
>> avr-gcc implements a 24-bit scalar integer types __int24 and __uint24 in
>> avr.c:TARGET_INIT_BUILTINS like so:
>>
>>   tree int24_type  = make_signed_type (GET_MODE_BITSIZE (PSImode));
>>   tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode));
>>
>>   (*lang_hooks.types.register_builtin_type) (int24_type, "__int24");
>>   (*lang_hooks.types.register_builtin_type) (uint24_type, "__uint24");
>>
>> PSImode is defined in avr-modes.c:
>>
>> FRACTIONAL_INT_MODE (PSI, 24, 3);
>>
>> Is this the right definition of a built-in type?
> 
> FRACTIONAL_INT_MODE should work after Bernd's patch series from last July 
> relating to 40-bit types, though it's certainly possible there are issues 
> that appear with 24-bit types but not 40-bit types.
> 
>> The question is because __int24 shreds the compiler, see PR51527
>>
>> So the question is if there is something missing or broken in the definition
>> above or if it's actually a flaw in the front-end.
>>
>> For the __int128 there is much more code sprinkled over the compiler sources,
>> so maybe it's not that easy to introduce a new, built-in type completely in the
>> back-end?
> 
> See my discussions with Bernd from last July.  In essence, I don't think 
> we should spread such code across the compiler for each non-power-of-2 
> size; ultimately we should go the other way, stop having any TImode or 
> __int128 references in files outside config/, libgcc/config/ etc. and have 
> targets using those modes and types choose to use the relevant source 
> files for them.  (And, further along, the existence of HImode, SImode, 
> DImode ought to be target-dependent as well, with files in config/ that 
> are used by targets with 8-bit bytes but maybe not by any targets with 
> wider bytes.)

You mean that thread?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00064.html
and
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00079.html

For the 128-bit integers there is just one type __int128 and unsigned variant
is unsigned __int128, whereas for the 24-bit types are are two types: __int24
for signed and __uint24 for unsigned flavor.

Is there an advantage of one approach over the other?

Johann






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