Menu
▾
▴
#93 NASM emits bogus FP constants
closed-accepted
nobody
None
4
2008-10-15
2003-05-30
Anonymous
No
There is a thread in the beginner's forum about this.
For example, NASM doesn't emit the proper sign=1 for
DD/DQ/DT -0.0.
Other cases don't seem to work properly either.
Until the cause has been isolated, all (and I mean ALL)
floating-point constants emitted by NASM should be
considered suspect, and not be relied upon.
I'm absolutely amazed that nobody has run into this
during the past couple of years of NASM being public.
I shudder to think how much NASM-generated code out
there will have to be re-generated once this problem
has been fixed.
In one word: ouch. :-(((
Logged In: NO
See
http://sourceforge.net/forum/forum.php?thread_id=875096&foru
m_id=167168 for the thread.
Logged In: YES
user_id=68913
I can think of a word besides "ouch", but this is a family
bug-tracker :)
I have no idea how to fix it. There *must* be a "reference
implementation" of this in portable C that we can borrow, no?
I've been filing federal taxes based on a Nasm program, too!
(but I double-check the results, and they're okay)
This might rate higher than "medium" priority (as if it
makes any difference). Definitely bad news, but thanks for
bringing it to us, Nobody.
Best,
Frank
Logged In: NO
I'm still looking at it. It appears as if exponents are
off by one, but get corrected later on. But then... by
now I might be seeing things. Time to take a break. :)
Also, I'm reluctant to just replace the existing FP code
with "something off the web", because of the potential
license rammifications.
Logged In: YES
user_id=608690
Does nasm have the ability to place hard-coded infinities and
NaN's?
koitsu
Logged In: NO
Currently FP constant overflows cause an error. With my
upcoming patch they will be rounded to positive/negative
infinity instead, accompanied by a warning.
As for NaNs -- you can emit their IEEE 754 encodings by
using integer constants, e.g. DD 7FFFFFFFh.
Logged In: NO
I believe that I have reached a break-through
point in chasing this problem. After re-writing
the code which handles underflows, denormals,
normals, and overflows, I seem to be getting
the expected results. There still is an issue
with rounding; however, I'm confident that I
can address that one as well.
I will look a more testcases over the next few
days. Stay tuned for more...
Logged In: NO
After some more work and plenty of
test cases I am satisfied with my
new FP constant parsing code. Only
one item remains to be addressed.
Besides allowing denormal numbers,
I have added support for treating
them as 0 -- to match the abilities
of x86 processors that support DAZ.
As of writing this my code defaults
to DAZ=disabled, to ensure that it
remains compatible with earlier NASM
versions (which allowed denormals).
However, I would like to make this
a user-controllable/visible option.
I'm not thrilled about introducing
a command line option for it, since
that would make it global -- I think
that it should be local instead.
So I'm thinking about adding support
for [DAZ] and [NODAZ] directives, a
set of DAZ and NODAZ macros, as well
as a set of __DAZ__ and __NODAZ__
variables -- in good NASM tradition.
However, I am concerned about adding
those DAZ and NODAZ macros, because
they might collide with existing code.
I know, I know, that's always a risk.
Does anyone have a better idea?
If not, any objections?
Logged In: NO
In addition to DAZ support I have just added
support for all four of the IEEE 754 rounding
modes (nearest even, down, up, and zero).
So my "new" plan is to add a [FPU] directive,
which will accept NODAZ and DAZ, as well as
NEAR, DOWN, UP, and ZERO as an argument.
Plus a corresponding FPU macro.
But no corresponding __...__ variables. (Why
not? See SourceForge tracker item #656015.)
PS: I chose [FPU] and FPU, because they are
similar to [CPU] and CPU. :-)
Logged In: YES
user_id=804543
Originator: NO
Attached find two files that might come in handy for FP16 testing.
One is a C source file -- it contains two different implementations
of FP16 (look for "source:" to see where they came from), a bit of
glue I had to add at the beginning, as well as a bunch of code at
the end which lets you spit out various numbers.
The other is an ASM file -- it compares pre-computed values and
the result of DW with FP16 constants. Look for the two $TODO$s
to see the cases where acfloat3 is, again, off by 1 for the LSB.
File Added: fp16.c.gz
Logged In: YES
user_id=804543
Originator: NO
File Added: fp16.asm.1of2.gz
1of2 (since SF limits uploads to 256K)
2of2 (since SF limits uploads to 256K)
Logged In: YES
user_id=804543
Originator: NO
File Added: fp16.asm.2of2.gz
Logged In: YES
user_id=58697
Originator: NO
The sign issue is fixed, and the current code can generate NaN and Inf, but the code still gives invalid mantissa values for valid constants. After studying a variety of papers etc. I'm convinced that the simplistic algorithm in NASM is simply wrong.
I'm attempting to integrate David M. Gay's "gdtoa" package instead, which has been heavily validated.
exhaustive boundary testcases
Logged In: YES
user_id=804543
Originator: NO
Attached find an updated version of fp.asm.
(from acfloat3.zip, now with FP16 testcases)
File Added: fp.asm
nearest even rounding testcase
Logged In: YES
user_id=804543
Originator: NO
Attached find a useful nearest even rounding testcase.
File Added: fp_near_0_5_down.asm
Logged In: YES
user_id=58697
Originator: NO
NASM 0.99.05 uses nasm64developer's code which should be accurate to within ±1 LSB. It is not perfect rounding, but it's a lot better than the old stuff (and as good as a lot of other compilers/assemblers), so I'm lowering the priority of this bug.
testnos3 cases from gdtoa