Fixed-point branch?

[Bernd Schmidt]

Fu, Chao-Ying wrote:

>>> +ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
>>> +ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
>>> +ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
>>> +ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
>> Lots of predefined types and modes in this patch.  What about targets
>> with other requirements (the Blackfin has 40 bit (8 + 32) 
>> accumulators)?
> 
>   In "bfin-modes.def", we can adjust the DA mode to (s7.32) by using
> ADJUST_IBIT(DA, 7)
> ADJUST_FBIT(DA, 32)
> 
>> For vectors, we let the targets define the supported modes.  Why do we
>> want something else for fractional support?
> 
>   I am not clear about this question.  The new modes (FRACT, UFRACT, ACCUM,
> and UACCUM) enables GCC to recognize the formats of the underlying values
> to perform constant folding (e.g., + - * /).
>   To use the DA mode for vector, we can use:
> VECTOR_MODE (ACCUM, DA, 2);

No, I was trying to make an analogy of how ports explicitly define the 
modes their hardware supports, e.g. for arm:

/* Vector modes.  */
VECTOR_MODES (INT, 4);        /*            V4QI V2HI */
VECTOR_MODES (INT, 8);        /*       V8QI V4HI V2SI */
VECTOR_MODES (INT, 16);       /* V16QI V8HI V4SI V2DI */
VECTOR_MODES (FLOAT, 8);      /*            V4HF V2SF */
VECTOR_MODES (FLOAT, 16);     /*       V8HF V4SF V2DF */

I'm wondering whether it's a good idea to have a lot of pre-defined 
fractional modes and types that may or may not match the target 
hardware.  Not saying it's necessarily wrong; I'm just interested to 
hear why you chose to do it this way.  (I also just noticed that things 
like SHORT_ACCUM_TYPE_SIZE are used but apparently not defined in the 
patch - does it actually compile?)


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif