Hex Flt Constants at CRI

[Tom MacDonald]

> > Recently we started a project to implement hex floating-point constants
> > in the Cray Research C compiler.  ...
> > I would appreciate hearing any reactions to this deviation from the
> > Floating-point C Extensions Document, and if anyone else has encountered
> > similar problems.
> 
> 
> Overall, it's less work and less disruptive to other tools if you don't
> change the syntax of the language.  KSR stole Fortran 90's TRANSFER
> intrinsic to get the same effect, much like Cray Pascal's VIEWING
> statement.  E.g.,

This is almost interesting (by definition computer science can never be
interesting) because we had a debate about using something similar to the
F90 transfer intrinsic.  It's more general (as you point out).  However, I
believe the _transfer intrinsic is also _new_ syntax.  It's not like I can
write the _transfer routine and put it in a library for those
implementations that don't support it as a builtin.  It's new syntax.

The internal proposal I saw circulating around here also allowed for
structures and unions.  I believe it was more like:

	_transfer ( 0xffffffff , double )

instead of:

	_transfer ( 0xffffffff , 1.0 )

which, I must admit, I like a little better.  It's apparent that _transfer
is an operator builtin to the language, and allows for struct types
without having to introduce a dummy variable of that type.

I believe the reason CRI chose the new hex constants is because we were
trying to solve a specific problem with a small feature that could be
implemented in a short amount of time.  It may give us 80% of what we
need and be enough.  That's a different story than a more general
language feature that isn't portable anyway.

(The union tricks you mention are _not_, technically speaking, blessed
by the C standard.)

though-I've-seen-as-many-implementations-that-disallow-union-tricks-as-
I've-seen-applications-that-rely-on-"sqrt(-0.0)==(-0.0)"-ly yours,

Tom MacDonald
tamacray.com
uunet!cray!tam