This brings up the thing that disturbs me most about the original
code fragment. It assumes a double is in IEEE format and little endian.
both dangerous assumptions. I do not believe the C standard specifies
IEEE floating point semantics or types for math. The alpha in particular
has and may be optimized for other floating point representations. I'm
sure the alpha isn't the only system to do things differently.
Just my 2 cents from the porting business,
Chris
On Wed, Apr 18, 2001 at 06:18:13PM -0400, Uncle George wrote:
> Its not my code segment, and from my experience a union might be better.
> although from this discourse not safe either.
>
> the code as stated should:
> 1) take address of x
> 2) make into int ptr
> 3) add 1 to ptr ( value of 4 bec its an int ptr )
> 4) fetch integer from the address as calculated.
>
> It should not matter if at x there is 8 bytes of a double, as that
> distinction is superflous to the equation.
>
> anyway the segment was taken from a floor() function (akin to glibc:
> ./sysdeps/ieee754/dbl-64/s_floor.c).
>
> static double huge = 1.0e300;
> #endif
>
> #ifdef __STDC__
> double __floor(double x)
> #else
> double __floor(x)
> double x;
> #endif
> {
> int32_t i0,i1,j0;
> u_int32_t i,j;
> EXTRACT_WORDS(i0,i1,x); <== Majic happens behind this macro
> which I suppose is tailored for each system
> j0 = ((i0>>20)&0x7ff)-0x3ff;
>:
>
>
> Michal Jaegermann wrote:
>
> > On Wed, Apr 18, 2001 at 11:13:59AM -0400, Uncle George wrote:
> > > Any compiler that does not produce the correct code has a bug - baring
> > > any error messages.
> >
> > Indeed, but you should also add "from a correct source" for clarity.
> >
> > > I suppose one has to deceide if an error message should be produced
> > > OR proper code should be produced.
> >
> > Can you explain what you intended to see from your example and why?
> > I was looking at that code yesterday and scratching my head. I am
> > still not absolutely sure what the _real_ meaning was supposed to be.
> >
> > If you want overlay different types you have 'union' construct for
> > that. Playing loose with pointers was not guaranteed to work ever.
>
>
>
> _______________________________________________
> Axp-list mailing list
> Axp-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/axp-list
_______________________________________________
Axp-list mailing list
Axp-list@redhat.com
https://listman.redhat.com/mailman/listinfo/axp-list
This archive was generated by hypermail version 2a22 on Sat May 5 06:18:13 2001 PDT
Send any problems or questions about this archive to webmaster@alphalinux.org.