RE: Fixed-point branch?

[Fu, Chao-Ying]

Bernd Schmidt 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?)
> 

  Ok. I got it.  Maybe we treat fixed-point modes as the first class 
modes like other scalar modes (integer, floating, etc.), so we pre-define them.
We can argue that how about making machine modes (ex: floating-point, decimal 
floating-point)
not pre-defined, similar to vector modes.

  I think, the default fixed-point formats are the efficient ones
for 32-bit/64-bit processors (with or without hardware supports).
One of the goals for the fixed-point extension is that all targets in GCC will
enable the extension, so efficient formats may be set by default.

  We have all FRACT and ACCUM sizes in defaults.h.  Thanks!

#ifndef SHORT_FRACT_TYPE_SIZE
#define SHORT_FRACT_TYPE_SIZE BITS_PER_UNIT
#endif

#ifndef FRACT_TYPE_SIZE
#define FRACT_TYPE_SIZE (BITS_PER_UNIT * 2)
#endif

#ifndef LONG_FRACT_TYPE_SIZE
#define LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 4)
#endif

#ifndef LONG_LONG_FRACT_TYPE_SIZE
#define LONG_LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 8)
#endif

#ifndef SHORT_ACCUM_TYPE_SIZE
#define SHORT_ACCUM_TYPE_SIZE (SHORT_FRACT_TYPE_SIZE * 2)
#endif

#ifndef ACCUM_TYPE_SIZE
#define ACCUM_TYPE_SIZE (FRACT_TYPE_SIZE * 2)
#endif

#ifndef LONG_ACCUM_TYPE_SIZE
#define LONG_ACCUM_TYPE_SIZE (LONG_FRACT_TYPE_SIZE * 2)
#endif

#ifndef LONG_LONG_ACCUM_TYPE_SIZE
#define LONG_LONG_ACCUM_TYPE_SIZE (LONG_LONG_FRACT_TYPE_SIZE * 2)
#endif

Regards,
Chao-ying

Re: 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

RE: Fixed-point branch?

[Fu, Chao-Ying]

Bernd Schmidt wrote:

> >   I attached a diff file for 14 files of the new structures
> > and documents.  You and other maintainers are welcome to
> > check it.  Thanks a lot!
> > 
> > Note: 14 files are =>
> > genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
> > tree.c rtl.def rtl.h rtl.c fixed-value.h fixed-value.c
> > doc/extend.texi doc/rtl.texi doc/c-tree.texi doc/md.texi
> 
> Random comments..
> 
> > +  unsigned saturating_flag : 1; /* FIXME.  This new flag 
> increases the size of
> > +  tree_common by a full word.  */
> 
> Sounds undesirable.  We need to look hard for a way to avoid this.

  Yes, we can get one of 24 spare bits for this flag.  We just fixed this
issue last week.

> 
> > +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);

> 
> > +int
> > +fixed_zerop (tree expr)
> > +{
> > +  return TREE_CODE (expr) == FIXED_CST
> > +&& double_int_zero_p (TREE_FIXED_CST (expr).data);
> > +}
> 
> Formatting - this needs parentheses.  Elsewhere too.

  Ok.

> 
> > +static tree
> > +make_or_reuse_fract_type (unsigned size, int unsignedp, int satp)
> 
> Comments before functions.

  Ok.  Thanks!

Regards,
Chao-ying

Re: Fixed-point branch?

[Bernd Schmidt]

Fu, Chao-Ying wrote:
>   I attached a diff file for 14 files of the new structures
> and documents.  You and other maintainers are welcome to
> check it.  Thanks a lot!
> 
> Note: 14 files are =>
> genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
> tree.c rtl.def rtl.h rtl.c fixed-value.h fixed-value.c
> doc/extend.texi doc/rtl.texi doc/c-tree.texi doc/md.texi

Random comments..

> +  unsigned saturating_flag : 1; /* FIXME.  This new flag increases the size 
> of
> +  tree_common by a full word.  */

Sounds undesirable.  We need to look hard for a way to avoid this.

> +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)?

For vectors, we let the targets define the supported modes.  Why do we
want something else for fractional support?

> +int
> +fixed_zerop (tree expr)
> +{
> +  return TREE_CODE (expr) == FIXED_CST
> +&& double_int_zero_p (TREE_FIXED_CST (expr).data);
> +}

Formatting - this needs parentheses.  Elsewhere too.

> +static tree
> +make_or_reuse_fract_type (unsigned size, int unsignedp, int satp)

Comments before functions.


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

Re: [fixed-point] Fixed-point branch merge plan

[Mark Mitchell]

Fu, Chao-Ying wrote:

>   As Mark requested, we propose a merge plan for the fixed-point branch
> as follows.

I think this is a good plan.  Since there have been no negative
comments, let's go with this approach.

I've looked at the big patch you posted, and I think it looks very good
overall.  You will still need approval for the patches at each stage of
the merge, though.  I am hoping the appropriate maintainers will step up
to review each piece.  However, if the process gets stuck, let me know,
and I will step in to help.

Please wait until the PTR_PLUS branch is merged before beginning your
merge.  However, you may of course start preparing your patches, and
posting them for review, if you like.  I just want you to let Andrew go
first in terms of actually checking in the changes.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

[fixed-point] Fixed-point branch merge plan

[Fu, Chao-Ying]

Hi,

  As Mark requested, we propose a merge plan for the fixed-point branch
as follows.

1. Merge in machine modes to support signed and unsigned
fract and accum modes.  Handle scalar and vector modes.

2. Merge in fixed-value.h and fixed-value.c to handle fixed-point values.
 
3. Merge in TREE structures for fixed-point types and constants.

4. Merge in C front-end changes to parse _Sat, _Fract and _Accum.

5. Merge in RTL structures for fixed-point constants and operators.

6. Merge in libcpp to parse fixed-point constants.

7. Merge in changes to support "case" of FIXED_POINT_TYPE, FIXED_CST,
and CONST_FIXED in .c and .h files.

8. Merge in the MIPS backend that supports fixed-point instructions.

9. Merge in configure/build system changes for the runtime library.

10. Merge in testsuite (from gcc.dg/fixed-point) that only run
when the compiler is configured to enable fixed-point.

  This plan is similar to the DFP merge plan from this link.
http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html
Our changes will be active for the mips target and all other targets
should not be affected.  For each step, we will wait for some days
to fix any breakage.  Comments are welcome!

  Thanks a lot!

Regards,
Chao-ying

Re: Fixed-point branch?

[Mark Mitchell]

Fu, Chao-Ying wrote:

>   Right now, the fixed-point support is a configure-time option. 
> Each target can decide to support it or not.  I think there is no 
> harm to enable for every target.  But, each target needs to modify
> tm.h tm.c tm-modes.def to set or change some target macros.

I would suggest making it a configure-time option, and eliminating the
target hook.  Then, people can turn it on when they want.  If they try
to turn it on for a target that doesn't have the necessary support, the
compiler will break, and they can fix it.

>   It's hard to pick up a name.  Maybe we will change it to
> the following as Nigel suggested.
> 
> /* Conversions involving fractional fixed point types without
>saturation, including:
>  fractional to fractional (of different precision),
>  signed integer to fractional,
>  fractional to signed integer,
>  floating point to fractional,
>  fractional to floating point.  */
> DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY)

Yes, I think that's better.

Thanks!

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

RE: Fixed-point branch?

[Fu, Chao-Ying]

Mark Mitchell wrote:

> >   I attached a diff file for 14 files of the new structures
> > and documents.  You and other maintainers are welcome to
> > check it.  Thanks a lot!
> 
> Thank you for posting this.
> 
> Things about which I am clueless:
> 
> What is the difference between a _Fract type and an _Accum type?  I'm
> gathering that _Fract types have no integer part, i.e., they always
> represent a number between (-1,1), whereas _Accum types 
> contain both an
> integer and a fractional part.  Is there any other difference?

  No other differences.  For _Fract and _Accum, there are signed and unsigned
types.  The unsigned _Fract and _Accum types are always >= 0.

> 
> Substantive issues:
> 
> +  unsigned saturating_flag : 1; /* FIXME.  This new flag 
> increases the
> size of
> +tree_common by a full word.  */
> 
> We need to fix that, if it's true.  Grab a bit out of 
> tree_base::spare,
> if need be.

  Yes.  Will get one spare bit for saturating_flag.

> 
> +  /* Fixed-point types. */
> +  if (targetm.fixed_point_supported_p ())
> 
> I thought there was an emulation library for fixed-point operations?
> So, why would this be supported only on some targets?  Is there a harm
> in supporting it everywhere?  If there is, should it be enabled
> per-target, or via a configure-time option?

  Right now, the fixed-point support is a configure-time option. 
Each target can decide to support it or not.  I think there is no 
harm to enable for every target.  But, each target needs to modify
tm.h tm.c tm-modes.def to set or change some target macros.

> 
> I don't see any constant-folding code for fixed-point; is 
> there no need
> for that?  Is it somewhere else in the codebase?

  I will post a diff file that has everything including
constant-folding code soon.

> 
> Stylistic points:
> 
> Every function needs a comment saying what it does, what 
> every argument
> is, and what the return value is.  You have some new 
> functions that are
> missing comments.

  Ok.  Will fix it.

> 
> +   fixed-point <- real,
> 
> Please write as "real to fixed point" to avoid ambiguity with 
> the errors.

  Ok.  Will fix it.

> 
> +DEF_RTL_EXPR(FIXED_ALL, "fixed_all", "e", RTX_UNARY)
> 
> Why FIXED_ALL?  That doesn't seem mnemonic.

  It's hard to pick up a name.  Maybe we will change it to
the following as Nigel suggested.

/* Conversions involving fractional fixed point types without
   saturation, including:
 fractional to fractional (of different precision),
 signed integer to fractional,
 fractional to signed integer,
 floating point to fractional,
 fractional to floating point.  */
DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY)

> 
> > +  sat_short_fract_type_node = 
> make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE);
> > +  sat_fract_type_node = make_sat_signed_fract_type 
> (FRACT_TYPE_SIZE);
> > +  sat_long_fract_type_node = 
> make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE);
> > +  sat_long_long_fract_type_node = 
> make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE);
> 
> Can we macroize some of this goo?  There are several places 
> in the patch
> where you have very long sequences of types, modes, etc.  I would hope
> that by naming things consistently, we might be able to compact this a
> lot, and reduce the chance that we've got something wrong in just one
> place.  Like:
> 
>   #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \
>  set_##WIDTH_##KIND_type_node = make_##SAT_...
> 
> and then:
> 
>   #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \
> MAKE_FIXED_TYPE_NODE(_short, KIND); \
> MAKE_FIXED_TYPE_NODE(_, KIND); \
> MAKE_FIXED_TYPE_NODE(_long, KIND); \
> MAKE_FIXED_TYPE_NODE(_long_long, KIND);
> 
> and then:
> 
>   MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract);
>   MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum);
> 
> etc.
> 
> That's not right, but you get the idea. :-)

  Ok.  We will try to shorten C code.  Thanks!

Regards,
Chao-ying

Re: Fixed-point branch?

[Mark Mitchell]

Fu, Chao-Ying wrote:

>   I attached a diff file for 14 files of the new structures
> and documents.  You and other maintainers are welcome to
> check it.  Thanks a lot!

Thank you for posting this.

Things about which I am clueless:

What is the difference between a _Fract type and an _Accum type?  I'm
gathering that _Fract types have no integer part, i.e., they always
represent a number between (-1,1), whereas _Accum types contain both an
integer and a fractional part.  Is there any other difference?

Substantive issues:

+  unsigned saturating_flag : 1; /* FIXME.  This new flag increases the
size of
+  tree_common by a full word.  */

We need to fix that, if it's true.  Grab a bit out of tree_base::spare,
if need be.

+  /* Fixed-point types. */
+  if (targetm.fixed_point_supported_p ())

I thought there was an emulation library for fixed-point operations?
So, why would this be supported only on some targets?  Is there a harm
in supporting it everywhere?  If there is, should it be enabled
per-target, or via a configure-time option?

I don't see any constant-folding code for fixed-point; is there no need
for that?  Is it somewhere else in the codebase?

Stylistic points:

Every function needs a comment saying what it does, what every argument
is, and what the return value is.  You have some new functions that are
missing comments.

+   fixed-point <- real,

Please write as "real to fixed point" to avoid ambiguity with the errors.

+DEF_RTL_EXPR(FIXED_ALL, "fixed_all", "e", RTX_UNARY)

Why FIXED_ALL?  That doesn't seem mnemonic.

> +  sat_short_fract_type_node = make_sat_signed_fract_type 
> (SHORT_FRACT_TYPE_SIZE);
> +  sat_fract_type_node = make_sat_signed_fract_type (FRACT_TYPE_SIZE);
> +  sat_long_fract_type_node = make_sat_signed_fract_type 
> (LONG_FRACT_TYPE_SIZE);
> +  sat_long_long_fract_type_node = make_sat_signed_fract_type 
> (LONG_LONG_FRACT_TYPE_SIZE);

Can we macroize some of this goo?  There are several places in the patch
where you have very long sequences of types, modes, etc.  I would hope
that by naming things consistently, we might be able to compact this a
lot, and reduce the chance that we've got something wrong in just one
place.  Like:

  #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \
 set_##WIDTH_##KIND_type_node = make_##SAT_...

and then:

  #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \
MAKE_FIXED_TYPE_NODE(_short, KIND); \
MAKE_FIXED_TYPE_NODE(_, KIND); \
MAKE_FIXED_TYPE_NODE(_long, KIND); \
MAKE_FIXED_TYPE_NODE(_long_long, KIND);

and then:

  MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract);
  MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum);

etc.

That's not right, but you get the idea. :-)

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Fixed-point branch?

[Mark Mitchell]

Fu, Chao-Ying wrote:

>> 2. Joseph, at that point, would you please invest a a little 
>> bit of time
>> (a couple of hours) to look at the branch, and provide some feedback?
>> Please provide comments to Chao-Ying, and also please let me know
>> whether you think the work is nearly ready for inclusion?
> 
>   Maybe you could first check if new machine modes, new TREE structures
> (a saturating bit, fixed-point type, fixed-point constant), 
> new RTL structures (fixed-point constant and operators) are ok.

I had not realized that there were so many changes outside of the C
front end.  I think that it does indeed make sense to have someone look
at some of that stuff.  I will be happy to take a look.  Will you please
send me a patch (and CC the list) for the middle-end changes?  It
doesn't have to apply to mainline cleanly, but that will give me -- and
people who know better than I! -- a chance to look over the
infrastructure changes.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

RE: Fixed-point branch?

[Fu, Chao-Ying]

> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 31, 2007 9:05 AM
> To: Joseph S. Myers
> Cc: Fu, Chao-Ying; Richard Henderson; GCC
> Subject: Re: Fixed-point branch?
> 
> 
> Joseph S. Myers wrote:
> 
> > I haven't examined it.  When the branch maintainers 
> consider it ready to 
> > merge I hope a proposal along the lines of the DFP one 
> > <http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html> will be 
> posted (see also 
> > subsequent discussion in that thread, and on the submitted patches).
> 
> I would like to avoid the situation in which Chao-Ying et. 
> al. work hard
> to come up with a plan, factor the patches, etc., and then we decide
> that the code is not going to be ready for 4.3.  I had 
> originally pushed
> this work back to 4.4, but as 4.3's been delayed, perhaps there's an
> opportunity for it in 4.3.  If, however, the work isn't 
> ready, then I'd
> rather not take up a lot of Chao-Ying's time now; instead, we can just
> wait for 4.4 to get closer.
> 
> At the same time, of course, there's not much point in you 
> investing in
> looking at the branch if Chao-Ying doesn't think it's ready.
> 
> So, let's do this:
> 
> 1. Chao-Ying, would you please work on any remaining issues that you
> feel need resolution.  Then, post your merge plan, ala DFP.

  Yes.  We will work on remaining issues and post our merge plan.

> 
> 2. Joseph, at that point, would you please invest a a little 
> bit of time
> (a couple of hours) to look at the branch, and provide some feedback?
> Please provide comments to Chao-Ying, and also please let me know
> whether you think the work is nearly ready for inclusion?

  Maybe you could first check if new machine modes, new TREE structures
(a saturating bit, fixed-point type, fixed-point constant), 
new RTL structures (fixed-point constant and operators) are ok.

  Thanks a lot!

Regards,
Chao-ying

Re: Fixed-point branch?

[Mark Mitchell]

Joseph S. Myers wrote:

> I haven't examined it.  When the branch maintainers consider it ready to 
> merge I hope a proposal along the lines of the DFP one 
>  will be posted (see also 
> subsequent discussion in that thread, and on the submitted patches).

I would like to avoid the situation in which Chao-Ying et. al. work hard
to come up with a plan, factor the patches, etc., and then we decide
that the code is not going to be ready for 4.3.  I had originally pushed
this work back to 4.4, but as 4.3's been delayed, perhaps there's an
opportunity for it in 4.3.  If, however, the work isn't ready, then I'd
rather not take up a lot of Chao-Ying's time now; instead, we can just
wait for 4.4 to get closer.

At the same time, of course, there's not much point in you investing in
looking at the branch if Chao-Ying doesn't think it's ready.

So, let's do this:

1. Chao-Ying, would you please work on any remaining issues that you
feel need resolution.  Then, post your merge plan, ala DFP.

2. Joseph, at that point, would you please invest a a little bit of time
(a couple of hours) to look at the branch, and provide some feedback?
Please provide comments to Chao-Ying, and also please let me know
whether you think the work is nearly ready for inclusion?

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Fixed-point branch?

[Joseph S. Myers]

On Mon, 28 May 2007, Mark Mitchell wrote:

> Joseph, Richard --
> 
> As C maintainers, have either of you looked at Chao-Ying's fixed-point
> branch?

I haven't examined it.  When the branch maintainers consider it ready to 
merge I hope a proposal along the lines of the DFP one 
<http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html> will be posted (see also 
subsequent discussion in that thread, and on the submitted patches).

> (a) whether implementing N1169 is likely to be dangerous, in the sense
> that the committee might eventually adopt a substantially conflicting
> version of the specification,

N1169 is the current version, with various defects addressed relative to 
the published TR18037 but has not yet been published as a new revision of 
the TR because of ISO bureaucracy.  (To quote the draft London minutes, 
"TR 18037 (embedded) has had all defects addressed. SC 22 secretariat is 
requiring a NWI ballot for revising this, which is against the JTC 1 
procedures.")

If any of this is included in (an Annex to) C1x, it remains to be seen if 
the committee will follow the expressed principle of standardising 
existing practice without changing it incompatibly.  If it just moves from 
being a TR to being an IS, I wouldn't expect problems with changes there.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Fixed-point branch?

[Nigel Stephens]

Mark Mitchell wrote:

Chao-Ying, I'm also interested in whether or not these changes have any
impact on C++.  With your changes, does GNU C++ now accept any
fixed-point constructs? 


Chao-ying's on vacation this week. AFAIK Chao-ying's code does nothing explicit 
to support, or not support, C++. The front-end code was based on the Decimal 
floating point extension, so should currently behave in a similar fashion to 
that with regards C++.



 If so, are you aware of any effort to
standardize any of this functionality in C++?  


Annex F (page 96) of the N1169 spec 
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf) does give some 
"guidelines" for C++ usage, but only a very hand-wavy couple of paragraphs. I 
guess we can ask the committee members if there is any work going on in this area.



(I think that my
preference, in the short term, would be to disable this functionality in
C++ -- although, of course, we will eventually want to turn it on so
that GNU C++ is as much as possible a superset of GNU C.)

  


OK

Nigel

Fixed-point branch?

[Mark Mitchell]

Joseph, Richard --

As C maintainers, have either of you looked at Chao-Ying's fixed-point
branch?

My understanding (from the note on the Wiki page) is that the
fixed-point support is now in reasonably good shape, and works on all
architectures, using an emulation library.  So, I'm wondering if we
should get this into GCC 4.3.

I'm interested in your impressions of:

(a) whether implementing N1169 is likely to be dangerous, in the sense
that the committee might eventually adopt a substantially conflicting
version of the specification,
(b) the quality of the implementation,
(c) risks you would forsee to other parts of the compiler.

For the purposes of this discussion, I'm less interested in your
impressions (if any) of the MIPS back-end changes; those can be looked
at by a MIPS maintainer in due course.  The first step would be to get
this functionality into the C front-end.

Chao-Ying, I'm also interested in whether or not these changes have any
impact on C++.  With your changes, does GNU C++ now accept any
fixed-point constructs?  If so, are you aware of any effort to
standardize any of this functionality in C++?  (I think that my
preference, in the short term, would be to disable this functionality in
C++ -- although, of course, we will eventually want to turn it on so
that GNU C++ is as much as possible a superset of GNU C.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713