I tried posting this to the Mac Pascal (Pascal Central) list but for some reason it is not making it.
===============================
I might be confused about how to import math functions in GPC.
GPC itself doesn't seem to have the functions that I need (I'm looking in gpc.pas), but in the docs there is a mention of math.pas. However, I can't find such a file in my GPC installation.
Do I need to use (non-portable) Mac math libraries? If so, is fp.p still the preferred interface? In the case of more common functions such as trig stuff, does fp.p override the Pascal built-ins? Or conflict with them? 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.
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? To make old code work that assumed that Extended is eight bytes, can I write type Extended = Real without my computer exploding?
FWIW, I'm porting my own set of tools which needs the math functions and which was originally made on THINK Pascal, then ported to Metrowerks, and now to GPC.
Thanks for any help.
Jerry
lanceboyle@bluebottle.com wrote:
I might be confused about how to import math functions in GPC.
GPC itself doesn't seem to have the functions that I need (I'm looking in gpc.pas), but in the docs there is a mention of math.pas. However, I can't find such a file in my GPC installation.
This file is part of the GPC source distribution. Its interface are the functions in gpc.pas indeed.
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 ...
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.
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?)
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.)
To make old code work that assumed that Extended is eight bytes, can I write type Extended = Real without my computer exploding?
Yes (though I decline any warranty for hardware destruction ;-).
Frank
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 ...
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).
Regards,
Adriaan van Os
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
Adriaan van Os wrote:
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
Did you do it just to be sure, or were there actually problems when not doing so (and overriding `pow')?
lanceboyle@bluebottle.com wrote:
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.
GPC has LongestReal for the longest available real type. Portable ... well, it's defined everywhere, but of course, it's not the same type everywhere (I suppose the same would go for Ada), so care is required when using it for data exchange or such.
Frank
Jerry (me) said this:
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.
Then Frank said this:
GPC has LongestReal for the longest available real type. Portable .... well, it's defined everywhere, but of course, it's not the same type everywhere (I suppose the same would go for Ada), so care is required when using it for data exchange or such.
Frank
In another post, Adriaan said this:
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).
Regards,
Adriaan van Os
Now, I'm saying this:
But isn't there potentially a difference between the longest _natively_supported_ float per hardware, and the longest float, which might be partially software-implemented? For speed, it would still seem like a good idea to have a type which defaults to the longest natively supported length.
Sorry if this is beating the subject to death.
Jerry
On Tue, 29 Nov 2005 lanceboyle@bluebottle.com wrote:
Now, I'm saying this:
But isn't there potentially a difference between the longest _natively_supported_ float per hardware, and the longest float, which might be partially software-implemented? For speed, it would still seem like a good idea to have a type which defaults to the longest natively supported length.
Sorry if this is beating the subject to death.
I think going to manual brings us to the fact (LongestReal:: in index):
type LongestReal = LongReal; { might get bigger than LongReal someday }
while on the Real Types page we read:
| Note that not all machines support longer floating point types, so | `LongReal' is the same as `Real' on these machines. Also, some machines | may support a longer type, but not do all arithmetic operations (e.g. | the `Sin' function, *Note Sin::) in a precision higher than that of | `Real'. If you need higher precision, you can look at the `GMP' unit | (*note GMP::) which provides rational and real numbers with arbitrary | precision, but their usage is different from normal real types. | | The following real types are guaranteed to be compatible to the real | types of GNU C. The sizes given, however, are _not_ guaranteed. They | are just typical values used on any IEEE compatible floating point | hardware, but they may be different on some machines. | | type name alternative name GNU C equivalent size in bits | (typically) | ShortReal Single float 32 | Real Double double 64 | LongReal Extended long double 80
So, essentially this means that GPC will support hardware supported types with GPC native types, while for software extended precision GMP (or other) library is required.
My $0.02
Regards, Mirsad
Frank Heckenbach wrote:
Adriaan van Os wrote:
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
Did you do it just to be sure, or were there actually problems when not doing so (and overriding `pow')?
I see it is not strictly necessary, the following works.
program testpow; function pow(x: double; y: double): double; external name 'pow'; begin writeln( pow( 1.2, 3.4)) end.
I can't remember if there were actual compiler problems when we did the port to GPC or that it was added just to be sure or that it was done because of a lack of understanding of gpc.
Regards,
Adriaan van Os
lanceboyle@bluebottle.com wrote:
I tried posting this to the Mac Pascal (Pascal Central) list but for some reason it is not making it.
Are you using mac-pascal@listman.sonic.net for the MacPascal mailing list address? A while ago Bill Catambay the list owner made the slight "-" change to the mailing list address in an atempt to dodge SPAMmers who had latched onto the previous address.
If you are using that address, you might want to contact Bill Catambay directly through the Pascal Central support form at http://excaliburworld.com/support.html to see what the problem might be and get some direct assistance on resolving the problem.
===============================
I might be confused about how to import math functions in GPC.
GPC itself doesn't seem to have the functions that I need (I'm looking in gpc.pas), but in the docs there is a mention of math.pas. However, I can't find such a file in my GPC installation.
Do I need to use (non-portable) Mac math libraries?
It depends upon which Mac math libraries routines from fp.p your existing code is using. While GPC does add a few math function to the standard Pascal language package one had when using Metrowerks/CodeWarrior Pascal or THINK Pascal, GPC does't provide direct support for the full set of routines in fp.p.
If so, is fp.p still the preferred interface?
Yes. However, I'll note the file name for the GPC compatible fp unit is fp.pas.
In the case of more common functions such as trig stuff, does fp.p override the Pascal built-ins? Or conflict with them?
If you use (or import) the fp unit, the fp routines will scope hide/override the Pascal language built-ins. I will note with the GPC version of the fp unit interface, the previous declaration conflicts between fp and standard Pascal for round and trunc have been fixed by renaming the respective fp routines to roundd and truncd. (Note: Even though they are renamed at the Pascal language level, GPC fp.pas declares them in a manner so that they still link to the correct Apple supplied library function.) If your existing code made use of fp's round and trunc implementations and relied upon scope hiding to hide the Pascal language built-in round and trunc, you'll need to make some code changes to keep things working correctly.
Although fp's round and trunc were renamed in the GPC version of fp.pas, I'll note that it wasn't really necessary to do so. GPC supports several Extended Pascal languages features which aren't supported by Metrowerks/CodeWarrior Pascal or THINK Pascal to handle name conflicts like this. Depending upon the version of GPC you're using, selective "only" imports, import renaming, qualified imports, and function/procedure block level versus unit/module block level importing are in the supported toolkit to handle this type of conflict. In case it isn't readily obvious, these language features also give you a quite a bit of flexibility in choosing between whether your code uses the Pascal built-in implementation or the Apple library supplied implementation of the common functions.
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.
Frank Heckenbach wrote:
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} is the compiler directive. When fp.pas was first ported for GPC use, I believe that directive was necessary to get the unit to compile. Since that first port, GPC has undergone some pretty extensive changes in this area so I'm not sure whether that directive is still needed.
lanceboyle@bluebottle.com wrote:
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? To make old code work that assumed that Extended is eight bytes, can I write type Extended = Real without my computer exploding?
Instead of rolling your own type size specific master type declarations, I suggest you use the master sized type declarations in MacTypes.pas as long as you're working with Mac OS [X] code. In using MacTypes.pas master types, type size issues like this one have already been addressed by the maintainers of the Mac OS [X] interfaces and the compiler appropriate declaration needed to yield the specified type size is already there in the interfaces for the presently supported FPC, GPC, and Metrowerks/CodeWarrior Pascal compilers and architecture targets and will be there for any future supported compilers and targets such as GPC Mac OS X Intel. For this particular case, the MacTypes.pas Float64 type will alyways result in an eight byte sized floating point type regardless of whatever sizing quirks there might be with the built-in types for the compiler you're using or the architecture you're targetting.
Gale Paeper gpaeper@empirenet.com