Thanks, guys. I think Adriaan's reply makes the reply that I was preparing unnecessary. Still, my 2 cents' worth below.
Jerry
On Nov 29, 2005, at 12:49 AM, Adriaan van Os wrote:
Frank Heckenbach wrote:
Do I need to use (non-portable) Mac math libraries? If so, is fp.p still the preferred interface?
You might want to let us know which functions you actually need ...
I've made a list of the math-related functions from the GPC docs so that I can make a more-informed decision about whether to involve Apple's fp.p in my code. There is a bit richer list than I had been able to discern earlier, with less manual-browsing. And, I do appreciate that many functions accept complex-valued arguments--very handy for me. Plus, I'll use the SplitReal procedure to implement my mantissa and exponent functions from days gone by.
The answer to the second question is 'yes'.
In the case of more common functions such as trig stuff, does fp.p override the Pascal built-ins?
If they have the same name and (in case of routines declared in gpc.pas) you import your module after gpc.pas, then yes.
We took some care to circumvent conflicts in the Mac interfaces, e.g. we disabled the 'pow' keyword and we renamed trunc en round in fp.pas to truncd and roundd respectively.
I believe that pow() is a problem with respect to conflicts and I see that some headers seem to note this in a compiler directive.
Well, pow is an operator, not a function, in Extended Pascal. But as long as you don't use strict EP mode, GPC should allow overriding it with a function. (BTW, what kind of compiler directive?)
{$disable-keyword=pow}
Also, I see that floating point types Double and Real are the same and eight bytes, while Extended and LongReal are 16 bytes--is that correct?
Yes. (The exact sizes are platform dependent, but the equivalence of the two pairs of types is always so. Real is 8 byte on most if not all current targets, LongReal e.g. is 10 bytes on IA32.)
For the Mac, the situation is somewhat confusing.
On Mach-O Intel, the size of LongReal and Extended will be 16 bytes. Note that the Extended and LongReal types are still crashing in the Mach-O Intel compiler download from my website (because the size was wrongly 12 bytes and this was only recently fixed). Whatever the size, the precision is only 80 bits because of the 387 coprocessor (which is absurd but I can not help it).
On Mach-O PowerPC, the size of LongReal and Extended is 8 bytes. However, we may change it to 16 bytes, because Apple now supports 128-bit doubles in Mac OS X 10.3.9 and higher (this would mean building the compiler and runtime with mlong-double-128 but I haven't tried it yet).
Thanks--very helpful. BTW, doesn't Ada have a (portable) type for the longest native floating point format supported on each processor? That seems rather useful.
Regards,
Adriaan van Os