View Single Post
Old 03 June 2019, 12:01   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,538
Quote:
Originally Posted by Bruce Abbott View Post
You could work around the bug by using the code I posted from V37.1 instead of calling the library function.
Yes. That's the best solution for me. Also the conversion routine is not as complicated as I feared, so I can easily put it into a linker library.
I hope there are not many more issues in V34 math libraries...

Quote:
Originally Posted by Thomas Richter View Post
The typical math models are either: 1) FLOAT=DOUBLE=mathffp.
Didn't ANSI-C define that the IEEE Std 754 has to be used for floating point data representation?

Quote:
2) FLOAT=DOUBLE=mathieeedoubbas. In this math model, singbas/trans are neither used.
I would guess that storing float variables as 8 bytes double precision causes a lot of problems here.

Quote:
The Manx compiler handled it similarly. It could either use mathffp math, or mathieeedoubbas, or 68881 math. single precision IEEE does not play any role.
Right. I remember the various options. I used Aztec-C V3.4 in the 80s.

My current math model for vbcc's m68k-kick13 target is to use shared libraries for everything (as I did for the OS2+ target), but due to the lack of IEEE single precision support all "float" artihmetics are done by mathffp/mathtrans (converting IEEEsingle to FFP back and forth). Maybe I should better convert everything to IEEEdouble - but that might be slower.
phx is offline  
 
Page generated in 0.04140 seconds with 11 queries