murphy@pur-phy (William J. Murphy) (04/24/89)
>#define MODULE_EXTENT #include "ray.h" node *masternp = NULL; node **nppstack[100] = { &masternp,}; int nppsp = 0; #ifdef MCH_AMIGA #define HUGE ((float)1.7e+38) #endif #define curnpp (nppstack[nppsp]) #define pushnpp(npp) (nppstack[++nppsp] = npp) #define popnpp (nppstack[nppsp--]) >void getextent(np,re) >node *np; >rextent *re; > { > rextent newre; > > cv(HUGE,HUGE,HUGE,re->min); > cv(-HUGE,-HUGE,-HUGE,re->max); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > while (np) { > switch (np->kind) { > case EXTENT : getextent(eptr(np)->sub,&newre); > setextent(np,&newre); > break; > case SPHERE : sphere_rextent(np,&newre); break; > case TRIANGLE: triangle_rextent(np,&newre); break; > case QUAD : quad_rextent(np,&newre); break; > case RING : ring_rextent(np,&newre); break; > } > unionrextent(re,&newre,re); > np = np->next; > } > } I downloaded the dbw.zoo from bach.berkeley.eduand was trying to compile the sources for the Amiga with Manx 3.6a and came across an error 205 which reads cv(HUGE, HUGE, HUGE, re->min); ^ ext.c: ### : ERROR 205: : Overflow converting to FFP format! This section of code comes from module ext.c and is only a sample from the complete module. This line of code occurs 6 times in the module ext.c and each of them generate 3 errors 205 FFP conversion overflow. I tried to find what the FFP HUGE is supposed to defined as, but I could not find it in my compiler manual. As you can see it is defined as ((float)1.7e+38) which is the limit for single precision floating point. My question is this, I am sure that someone else has compiled this program, Have you seen this error? If so, then what do you do? The manual points out that errors above 200 means that there is a problem with the compiler. Is this a previously reported bug with 3.6? I believe that DBW_Render was originally compiled on Manx 3.4. Well, I haven't given up the ghost, but I thought others may be interested. Bill Murphy murphy@newton.physics.purdue.edu
bjornmu@idt.unit.no (04/25/89)
Bill Murphy reported problems with the HUGE vaule when compiling DBW_Render. > cv(HUGE,HUGE,HUGE,re->min); (from the file ext.c) The point is, the #define in the same file is inside an #ifdef: >#ifdef MCH_AMIGA >#define HUGE ((float)1.7e+38) >#endif But the macro MCH_AMIGA is undefined. So instaed of using this value for HUGE, the one from "math.h" is used. (math.h is #include'd by ray.h). That HUGE value is intended for double precision and is too big for float. To solve the problem, simply remove the #ifdef, or define MCH_AMIGA as 1 (in ray.h). BTW, has anyone tried to compile DBW_Render (I'm talking about the modified version by Ofer Licht) with Lattice 5.02 and run it on a 68020? I get all sorts of GURU's or garbage output, depending on the floating point options. The only option that works is FFP. But what I really want, of course, is in-line code for the 68881. Anyone succeeded in compiling with "lc -m2 -f8d" ????? I strongly suspect a compiler bug, but that may be possible to get around. Bj|rn Munch ("The Man With a Pipe in His Name") ....who is finally able to read the articles in comp.sys.amiga!! :-)
raz@kilowatt.uucp (Raz- Berry) (04/25/89)
In article <2185@pur-phy> murphy@pur-phy (William J. Murphy) writes: > cv(HUGE, HUGE, HUGE, re->min); > ^ >ext.c: ### : ERROR 205: : >Overflow converting to FFP format! > >This section of code comes from module ext.c and is only a sample from >the complete module. The solution is to compile the program with the -fi option and link with the mal, mal32, or other suitable libraries. As a nice side effect DBW will run faster (I will know how much faster when I get home tonight) because it will use the new 1.3 math libraries. If I am mistaken here, some one please correct me. The wierd part of seeing this is that I just did exactly the *SAME* thing this weekend. >Bill Murphy >murphy@newton.physics.purdue.edu -- Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com "Fate, it protects little children, old women, and ships named Enterprize"
warren@wucs1.wustl.edu (Warren Burnett) (04/27/89)
In article <2185@pur-phy> murphy@pur-phy (William J. Murphy) writes: >#define HUGE ((float)1.7e+38) ....... > cv(-HUGE,-HUGE,-HUGE,re->max); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I downloaded the dbw.zoo from bach.berkeley.eduand was trying to compile >the sources for the Amiga with Manx 3.6a and came across an error 205 >which reads > > cv(HUGE, HUGE, HUGE, re->min); > ^ >ext.c: ### : ERROR 205: : >Overflow converting to FFP format! > .......... >My question is this, I am sure that someone else has compiled this >program, Have you seen this error? Yes, I got the same error when I tried to compile it. I believe that changing the #define so that HUGE is 1.7e+18 will allow it to compile. The program seems to work correctly with this change, but I haven't tested it extensively. Does anyone know if this is in fact a problem with the compiler? There is a #define in the include file math.h for something called HUGE_VAL, or something like that; As I remember, it is something like 1.79e+308. Ray would not compile using this either (resulted in same error). Does anyone know if this is a real problem or just something weird about the DBW source? Warren Burnett warren@wucs1.wustl.edu
raz@kilowatt.uucp (Raz- Berry) (04/27/89)
In article <8904242330.AA20426@fenris.idt.unit.no> bjornmu@idt.unit.no writes:
)Bill Murphy reported problems with the HUGE vaule when compiling DBW_Render.
)
)) cv(HUGE,HUGE,HUGE,re-)min);
)
)(from the file ext.c)
)
)The point is, the #define in the same file is inside an #ifdef:
)
))#ifdef MCH_AMIGA
))#define HUGE ((float)1.7e+38)
))#endif
)
)But the macro MCH_AMIGA is undefined. So instaed of using this value
)for HUGE, the one from "math.h" is used. (math.h is #include'd by
)ray.h). That HUGE value is intended for double precision and is too
)big for float.
)
)To solve the problem, simply remove the #ifdef, or define MCH_AMIGA as
)1 (in ray.h).
There is NO PROBLEM if you are compiling with MANX. The MCH_AMIGA is defined
by default in 3.6a. Lettuce, is another problem. I would stick a define
in the compiler line ( -DMCH_AMIGA ) before I modified the source though.
AGAIN, compile with -fi (or -ff for MANX's floating routines) and link with
-lma32, -lmal32, -lma, -lmal (or -lm32 -lml32 -lm -lml) depending on the
CODE model and int size you are using.
--
Steve -Raz- Berry Disclaimer: I didn't do nutin!
UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com
"Fate, it protects little children, old women, and ships named Enterprize"murphy@pur-phy (William J. Murphy) (04/27/89)
In article <829@wucs1.wustl.edu> warren@wucs1.UUCP (Warren Burnett) writes: >In article <2185@pur-phy> murphy@pur-phy (William J. Murphy) writes: > >>#define HUGE ((float)1.7e+38) >....... >> cv(-HUGE,-HUGE,-HUGE,re->max); > >Yes, I got the same error when I tried to compile it. I believe that changing >the #define so that HUGE is 1.7e+18 will allow it to compile. The program >seems to work correctly with this change, but I haven't tested it extensively. > >Does anyone know if this is in fact a problem with the compiler? There is >a #define in the include file math.h for something called HUGE_VAL, or >something like that; As I remember, it is something like 1.79e+308. Well, since I started this thread, maybe I can tie it up. Raz-Berry in an earlier posting suggested compiling with the option +fi in Manx which will then use the IEEE library ma.lib, mal.lib, ma32.lib, or mal32.lib depending upon the other flags you set when compiling and linking. I tried Raz's suggestion and IT WORKS!!! Warren's comment about redefining the value HUGE to 1.7e+18 is not necessary. That value is correct according to ACCCK* PPHHHT*!@ Microsoft C 5.1 which lists the limits for the float as 1.7e+38 and 1.7e-38. (MSC5.1 uses the IEEE spec for numbers. and I couldn't find this figure in Manx's cruddy documentation.) The other number is the value/limit for double precision IEEE floating point. Thanks Raz, Warren and whomever else postedabout this. Bill Murphy murphy@newton.physics.purdue.edu
murphy@pur-phy (William J. Murphy) (04/28/89)
In article <2205@pur-phy> murphy@newton.physics.purdue.edu.UUCP (William J. Murphy) writes: > >Warren's comment about redefining the value HUGE to 1.7e+18 is not necessary. >That value is correct according to ACCCK* PPHHHT*!@ Microsoft C 5.1 which >lists the limits for the float as 1.7e+38 and 1.7e-38. (MSC5.1 uses the IEEE ^^^^^^^^^^^^^^^^^^^^ OOOPPS!! this is supposed to be 3.4e+38 and 3.4e-38. I was writing without the manual in front of me. SOORRYY! Bill Murphy murphy@newton.physics.purdue.edu