Re: small numerical differences in floating point result between wintel and Sun/SPARC

From: James Van Buskirk (not_valid_at_comcast.net)
Date: 12/15/04 

Date: Wed, 15 Dec 2004 09:41:47 GMT

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:BbTvd.1097101$Gx4.553006@bgtnsc04-news.ops.worldnet.att.net...

> But, as I say, I don't think we need to worry about integers that
> happen to have NaN bit patterns when interpreted as floats, or
> other such issues. They will only arise when (and if) the result
> of TRANSFER is actually used in a float operation.

Exactly this is a recurring problem. In the original Pentium
Classic, the widest registers you could access without RDMSR/
WRMSR were its x87 FP stack. Many times people would try to
move data around 64 bits at a time via FLD QWORD PTR x[8*ecx]/
FSTP QWORD PTR y[8*ecx] sequences. They would then be surprised
because some of the data would have one bit changed. The right
way to use the FP stack to move data, of course, was to use
FILD QWOR PTR x[8*ecx]/FISTP QWORD PTR y[8*ecx] because SNANs
would never get loaded into the FP registers in this way. Even
though the instruction timings were worse for the latter
sequence, if the data transfer was between memory locations
this was quite unimportant and using the FP stack with a
carefully unrolled and scheduled loop could be the fastest
way to move big aligned chunks of data around with that processor.
I would have thought it desirable when designing a low-level
primitive like TRANSFER that one might as well assume that the
user knows what he's doing so that for example an implementation
could assume that a user knows what kind of data he's TRANSFERring
into a floating point mold so that it would be OK for the Fortran
processor to touch it with its FPU. The TRANSFER back and forth
clause in the standard document seems to require otherwise,
though. It seems to put some kind of requirement on what a
Fortran processor has to do with the holes in data structures
under some circustances -- what if the result of TRANSFER is
used as an actual argument, then the associated dummy argument...

But maybe I am thinking about this all wrong, and the word 'shall'
in the standard is saying the the Fortran programmer had better
not write expressions where the values and appropriately preserved? 

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
P.S. conversion from integer to real and resulting TRANSFER of
the real back to integer is the fastest way on some processors
to implement a LEADZ function.  I'm tired too, so working out
an example for IEEE-754 single precision representation is
left to the early risers to enjoy with their worms.

Relevant Pages

  • Re: 2nd RfD: Separate FP Stack
    ... Anton Ertl wrote: ... also expects floats on the stack. ... conventions pass integers in integer registers and floats in FP ... And even on the IA-32 a unified stack does not necessarily make the ...
    (comp.lang.forth)
  • Re: Fortran memory allocation (stack/heap) issues
    ... > rather than Fortran, ... dynamic allocation, and relatively little stack allocation. ... value return and arrays by reference. ...
    (comp.lang.fortran)
  • Re: amazing discoveries...
    ... but I've seen some BSD code that pushed data ... Replying belatedly to this item (about pushing data onto the stack) I ... Since Fortran is possibly the oldest language this method of call ...
    (comp.lang.asm.x86)
  • Re: LSE64 release 0.3
    ... consistent language rather than two confusingly ... I like particulary the mix REAL/INT on the same 64 bit stack. ... Do you have investigated the idea to use only double floats on the ... In theory there is no difference between theory and practice. ...
    (comp.lang.forth)
  • Re: recursion, stack, fortran
    ... Fortran programmers have been implementing ... implement a stack in software, but that wasn't usual for the IBM ... Man is a sick fly taking a dizzy ride on it. ... I have programmed in Fortran on an IBM 360/95. ...
    (comp.lang.fortran)