[fixed-point] Machine modes in Fixed Point Extension

[fixed-point] Machine modes in Fixed Point Extension

[Mohamed Shafi]

Hello,

I am trying to add the fixed point patches to gcc 4.1.1 to provide
fixed point support to a non gcc/private architecture.

According to the patches submitted by Mr. Chao-Ying Fu the format for
the fixed point machine modes are as follows

Quarter Fract (QQ) - s.7
Half Fract (HQ) - s.15
Fract  (SQ) - s.31
Double Fract (DQ) - s.63
Tetra Fract (TQ) - s.127

Half Accum (HA) - s8.7
Accum  (SA) - s16.15
Double Accum (DA) - s32.31
Tetra Accum (TA) - s64.63

The size of the fixed point data type that *can* be used is

SHORT_FRACT_TYPE_SIZE 16    -  HQ
FRACT_TYPE_SIZE 32                 -  SQ
LONG_FRACT_TYPE_SIZE 64      -  DQ
LONG_LONG_FRACT_TYPE_SIZE  64 - DQ

SHORT_ACCUM_TYPE_SIZE 32   - SA
ACCUM_TYPE_SIZE 64                - DA
LONG_ACCUM_TYPE_SIZE 64     - DA
LONG_LONG_ACCUM_TYPE_SIZE 64 - DA

Now, irrespective of the machine mode that are available, will any
target support all the fixed point formats ?
If not each the formats has to converted to the target supported
format in the backend, right ?

My target has a 'fixed point ALU' which will accept data from a 48 bit
long fixed point register in s7.40 format. No other format is
accepted.
So my target has load/store instruction which will load the 48bits from 64 bits
properly(32 bits from 1st memory word and 16 bits from the higher half
word of the second memory word) in to the fixed point
register.Similarly there is 8,16,32 load/store instructions which pack
the 48bit register properly, so that data is in s7.40 format.All the
machine mode thus has to converted into s.40 or s7.40 format before
any arithmetic can be done.So bringing the size of largest data type
possible to less than or equal to 64 bits reduces a lot of overhead.

So the format that is decided for my target is as follows

short fract -           8 bits  s.7    QQmode
fract         -          32 bits  s.23  SQmode
long fract  -          32 bits  s.23   SQmode
long long fract -    64 bits  s.40   DQmode

short accum -          15 bits  s4.7    HAmode
accum         -          32 bits  s5.23   SAmode
long accum  -          32 bits  s5.23   SAmode
long long accum -    64 bits  s7.40   DAmode

With the help of  ADJUST_IBIT  and ADJUST_FBIT i will be able to
change the fractional and integral bits of a machine mode in
target-modes.def in the backend, say for SA mode

ADJUST_IBIT  (SA, 5);
ADJUST_FBIT (SA, 23);

Can someone point out any potential problem due to this?
Even though sizeof( accum ) returns 32 , target is actually using only
the 29 bits. So how will the front end take care of the unused bits?
If so how is it (wil it be converted to 0 or left blank)?Or is it the
job of backend?Will this effect any operations?

Is it required to have the size of long long accum to be twice the
size of fixed point register (2 x 48). or is it just a convention?

If my target doesn't need to support a machine mode say long long
accum is there a way to describe that , something like
RESET_FLOAT_FORMAT (SF, 0) ?

Shouldn't there be a comment for ADJUST_IBIT and ADJUST_FBIT  in
machmode.def just like that of RESET_FLOAT_FORMAT ?

Thanks for the reply in advance.

Regards,
Shafi

Re: [fixed-point] Machine modes in Fixed Point Extension

[Chao-ying Fu]

> Now, irrespective of the machine mode that are available, will any
> target support all the fixed point formats ?
> If not each the formats has to converted to the target supported
> format in the backend, right ?
I will add the emulation library in GCC to support all operators for
all fixed-point modes.

> Can someone point out any potential problem due to this?
I think your formats are ok.

> Even though sizeof( accum ) returns 32 , target is actually using only
> the 29 bits. So how will the front end take care of the unused bits?
> If so how is it (wil it be converted to 0 or left blank)?Or is it the
> job of backend?Will this effect any operations?
The unused bits will be signed-extend for signed data types, or
zero-extended for unsigned data types, as in fixed-value.c for
constant-folding.  And, the emulation library should take care of this.

> Is it required to have the size of long long accum to be twice the
> size of fixed point register (2 x 48). or is it just a convention?
No.  From the spec, the acccum type should have at least the
same number of the fractional bits as the corresponding fract type.
You can decide the number of the integral bits.

> If my target doesn't need to support a machine mode say long long
> accum is there a way to describe that , something like
> RESET_FLOAT_FORMAT (SF, 0) ?
You can have the following to disable undesirable modes.
Ex: (in mips.c, we support the fixed point modes up to 2*BITS_PER_WORD)
#undef TARGET_SCALAR_MODE_SUPPORTED_P
#define TARGET_SCALAR_MODE_SUPPORTED_P mips_scalar_mode_supported_p

/* Target hook for scalar_mode_supported_p.  */

static bool
mips_scalar_mode_supported_p (enum machine_mode mode)
{
  if (ALL_FIXED_POINT_MODE_P (mode)
      && GET_MODE_PRECISION (mode) <=  2 * BITS_PER_WORD)
    return true;

  return default_scalar_mode_supported_p (mode);
}

> Shouldn't there be a comment for ADJUST_IBIT and ADJUST_FBIT  in
> machmode.def just like that of RESET_FLOAT_FORMAT ?
Yes.  Need to update the document.

Regards,
Chao-ying


----- Original Message ----- 
From: "Mohamed Shafi" <shafitvm@gmail.com>
To: "Fu, Chao-Ying" <fu@mips.com>
Cc: <gcc-patches@gcc.gnu.org>
Sent: Sunday, January 07, 2007 10:06 PM
Subject: [fixed-point] Machine modes in Fixed Point Extension


> Hello,
>
> I am trying to add the fixed point patches to gcc 4.1.1 to provide
> fixed point support to a non gcc/private architecture.
>
> According to the patches submitted by Mr. Chao-Ying Fu the format for
> the fixed point machine modes are as follows
>
> Quarter Fract (QQ) - s.7
> Half Fract (HQ) - s.15
> Fract  (SQ) - s.31
> Double Fract (DQ) - s.63
> Tetra Fract (TQ) - s.127
>
> Half Accum (HA) - s8.7
> Accum  (SA) - s16.15
> Double Accum (DA) - s32.31
> Tetra Accum (TA) - s64.63
>
> The size of the fixed point data type that *can* be used is
>
> SHORT_FRACT_TYPE_SIZE 16    -  HQ
> FRACT_TYPE_SIZE 32                 -  SQ
> LONG_FRACT_TYPE_SIZE 64      -  DQ
> LONG_LONG_FRACT_TYPE_SIZE  64 - DQ
>
> SHORT_ACCUM_TYPE_SIZE 32   - SA
> ACCUM_TYPE_SIZE 64                - DA
> LONG_ACCUM_TYPE_SIZE 64     - DA
> LONG_LONG_ACCUM_TYPE_SIZE 64 - DA
>
> Now, irrespective of the machine mode that are available, will any
> target support all the fixed point formats ?
> If not each the formats has to converted to the target supported
> format in the backend, right ?
>
> My target has a 'fixed point ALU' which will accept data from a 48 bit
> long fixed point register in s7.40 format. No other format is
> accepted.
> So my target has load/store instruction which will load the 48bits from 64
bits
> properly(32 bits from 1st memory word and 16 bits from the higher half
> word of the second memory word) in to the fixed point
> register.Similarly there is 8,16,32 load/store instructions which pack
> the 48bit register properly, so that data is in s7.40 format.All the
> machine mode thus has to converted into s.40 or s7.40 format before
> any arithmetic can be done.So bringing the size of largest data type
> possible to less than or equal to 64 bits reduces a lot of overhead.
>
> So the format that is decided for my target is as follows
>
> short fract -           8 bits  s.7    QQmode
> fract         -          32 bits  s.23  SQmode
> long fract  -          32 bits  s.23   SQmode
> long long fract -    64 bits  s.40   DQmode
>
> short accum -          15 bits  s4.7    HAmode
> accum         -          32 bits  s5.23   SAmode
> long accum  -          32 bits  s5.23   SAmode
> long long accum -    64 bits  s7.40   DAmode
>
> With the help of  ADJUST_IBIT  and ADJUST_FBIT i will be able to
> change the fractional and integral bits of a machine mode in
> target-modes.def in the backend, say for SA mode
>
> ADJUST_IBIT  (SA, 5);
> ADJUST_FBIT (SA, 23);
>
> Can someone point out any potential problem due to this?
> Even though sizeof( accum ) returns 32 , target is actually using only
> the 29 bits. So how will the front end take care of the unused bits?
> If so how is it (wil it be converted to 0 or left blank)?Or is it the
> job of backend?Will this effect any operations?
>
> Is it required to have the size of long long accum to be twice the
> size of fixed point register (2 x 48). or is it just a convention?
>
> If my target doesn't need to support a machine mode say long long
> accum is there a way to describe that , something like
> RESET_FLOAT_FORMAT (SF, 0) ?
>
> Shouldn't there be a comment for ADJUST_IBIT and ADJUST_FBIT  in
> machmode.def just like that of RESET_FLOAT_FORMAT ?
>
> Thanks for the reply in advance.
>
> Regards,
> Shafi
>