bombadil@diku.dk (Kristian Nielsen) (01/24/91)
lkoop@pnet01.cts.com (Lamonte Koop) writes: >I have made an interesting discovery pertaining to SAS/Lattice 5.10a 881/882 >code generation. The following code is the culprit: > [listning deleted] >Suffice it to say that this code works (despite what might be wrong with what >you see here...I may have typoed or used a different version here, but htis >gives the general idea. Anyway, the problem isn't that it doesn't work. The >problem is the output. When compiled with standard IEEE math from the >compiler (no '881/882 code), it comes out as expected. With 881/882 code, the >results are off (dithering is off, etc...)... The SAME EXACT code is used, >with the exception that 881/882 code generation is turned on, and yes, I use >math.h for the normal code and m68881.h for the 881/882 code. [One item of >interest...the "colors" array are not color values...they correspond to a >color table entry subscript..). By inserting a printf() carfully in here and >testing the values of the variables p and q through the run, I found and >interesting item. For both the standard math, and for the 881/882 coded >routine, the values here are identical, UNTIL the 121st iteration comes >through, as follows: [...] > 121 0.00000e-01 N.aN000e+03 <--??? The IEEE standard for floating point includes the value 'Not a Number', which presumeably is what the N.aN bit means. It results from things like trying to evaluate the product of infinity and zero. I'm not quite sure that taking the square root of a negative number would result in the same thing, but this (WILD guess) could perhaps be the problem. Using the lattice math rutines I once did a major dumbo, something like 'if(a<0.0) b=sqrt(a)', and this ran just fine without any error message, but the result was slightly in error - took me ages to sort out! Now, say that, perhaps because of rounding errors, the program does something like sqrt(-1.0e-15); with the lattice rutines this could perhaps still run fine (with the illegal sqrt() returning some small value - at least the lattice version seems quite happy to do a 'negative root'), while the FPU NaN-value would wreck up the results. So, my suggestion is to check every argument to sqrt() using printf(), and perhaps even check for division by zero. You could also try testing the FP-error indicator variables - I seem to remember having heard of them, but I've never actually used them (lazy, I know...) BTW, if you try this out, and you can spare the time, how about mailing me a reply stating if you found out anything - I would be curious to know... > >Notice anything here? For about the next 8-12 iterations of the 881/882 >version BOTH p and q take on the strange value above, then return to normal, >until another line of the drawing (a beachball) comes around, then the process >repeats. The end result is incorrect shading (p and q are part of hte >determining variables for the shade color. Anyone have any ideas here? I >apologize for being vague (and wandering), but it's late here, and this one is >just too bizarre. >Oh, yes...the other difference in the 881/882 version vs. the "normal" version >is that the 'register' doubles declared are for the 881/882 version only..in >the normal version they are standard doubles. Kristian ========================================================================== Kristian Nielsen | /// Only the AMIGA Student at DIKU, University of Copenhagen | /// (Department of Computer Science) | \\\/// makes it possible! Denmark | \XX/ ==========================================================================