IA64 / Pascal / Floatingpoint problem

[Martin Michalecz]

I have two sources (Examples at the end). They are identical except at one point. One source inherits the definition of MTH$RANDOM from SYS$LIBRARY:PASCAL$MTH_ROUTINES while the second source has the definition copied (in textual form) directly into its source from SYS$LIBRARY:PASCAL$MTH_ROUTINES.PAS.

Source one fails with an error stating floating point incompatibilities, source 2 compiles OK.

I did not make a functional test of source 2 yet. It's no real option to copy system definitions into several files.

Questions:
a) Any idea whats going on here ?
b) Which floatingpointformat do the MTH Routines on IA64 support? Looking at SYS$LIBRARY shows only 4 MTHRTL*.exe's which seem to be binary translated (i.e. MTHRTL_D53_TV_AV.EXE) Does the binary translator change floating point format ?

-------------------

Examplesources:

-------------------------------------

SGDEV6::MM:000000 >type test_mth.pas
[INHERIT ('sys$library:pascal$mth_routines')]
PROGRAM Test(OUTPUT);
VAR
UU : UNSIGNED := 123;

!![ASYNCHRONOUS] FUNCTION mth$random (
!! VAR seed : [VOLATILE] UNSIGNED) : SINGLE; EXTERNAL;

BEGIN

WRITELN ( MTH$RANDOM ( UU ) * SNGL ( 1123 ) );

END.

-------------------------------------

(B) SGDEV6::MM:000000 >type test_mth2.pas
!![INHERIT ('sys$library:pascal$mth_routines')]
PROGRAM Test(OUTPUT);
VAR
UU : UNSIGNED := 123;

[ASYNCHRONOUS] FUNCTION mth$random (
VAR seed : [VOLATILE] UNSIGNED) : SINGLE; EXTERNAL;

BEGIN

WRITELN ( MTH$RANDOM ( UU ) * SNGL ( 1123 ) );

END.

-------------------------------------

(B) SGDEV6::MM:000000 >pascal /float=ieee test_mth.pas

WRITELN ( MTH$RANDOM ( UU ) * SNGL ( 1123 ) );
............................^
%PASCAL-E-IVCOMBFLOAT, Illegal combination of floating point types
at line number 11 in file TCORA_SPECIFIC:[SRC]TEST_MTH.PAS;20
%PASCAL-E-ENDDIAGS, PASCAL completed with 1 diagnostic

-------------------------------------

(B) SGDEV6::MM:000000 >pascal /float=ieee test_mth2.pas
(B) SGDEV6::MM:000000 >

-------------------------------------

Environment:
HP Pascal I64 V6.0-107 on OpenVMS 8.2-1 on IA64

[Kris Clippeleyr]

Martin,
Might this be an issue like the one we had with LIB$WAIT? The MTH$ routines date from the VAX era, and are very good in handling F-, D-, G- & H-Floats. I'm not sure they can handle IEEE-floats.
Regards,
Kris (aka Qkcl)

[Kris Clippeleyr]

Martin,
Could it be that the inherited stuff for the MTH$ routines somehow indicate that MTH$RANDOM should return an F-float? And that therefor your compiler is complaining (multiplying an F-float with an IEEE-float could be difficult). In the second source, you explicitly declare the MTH$RANDOM to be a funcion returning a SINGLE. So to your compiler that is a single-precision IEEE-float, so no problem there.
Regards,
Kris (aka Qkcl)

[Martin Michalecz]

Well I assumed that the file PASCAL$MTH_ROUTINES.PEN is constructed at the traget system from PASCAL$MTH_ROUTINES.PAS during some installation (i.e. the Pascal Compiler). So I wonder why the binary and the textual version differ.

I think John Reagen will read and comment this as soon as he has some time.

In the orginal source I omitted the SNGL and the code compiles (if it's working I dont know yet).

Anyway: If the routine returns F_FLOAT how can I use this variable in pascal compiled with IEEE floting ?

Martin

[Ian Miller.]

parhaps you can use the cmpl random routine
http://h71000.www7.hp.com/doc/73final/6118/6118pro_003.html#randomx

or you could convert the F float to IEEE float
using CVT$CONVERT_FLOAT

[Martin Michalecz]

Thanks for the hints.
I've been told in the meantime, that pascal has an internal RANDOM function. So the random problem seems to be fixable.

But in general I would like to know where there are (older ?) systemservices / library routines handling G_/F_float. And how to work with these routines in an pascal envorinmant compoling with ieee.

[John Gillings · Accepted solution]

Martin,

When the PASCAL$MTH_ROUTINES was compiled to produce the PEN file, the type "SINGLE" was interpreted and written to the PEN file. Because of the way it was compiled, the function type is F_FLOAT. When your test program was compiled, with default floating type IEEE, inheriting the precompiled environment, the compiler correctly flagged the type incompatibility between the F_FLOAT and your IEEE float variables.

In your second example, the type "SINGLE" is interpreted at compile time as IEEE. There is no longer an incompatibility, BUT the code is wrong because MTH$RANDOM returns F_FLOAT! So the generated code will interpret the F_FLOAT return value as IEEE, and will be wrong.

To use other floating point formats you need to perform explicit conversions. Sometimes that will involve encapsulating routines inside modules. In most common cases there are variant routines for each floating point type. Even better is to use the language defined routine, like Pascal's "random" which will automatically do the right thing.

Note that the default floating point types between Alpha and I64 compilers are different. This WILL cause problems if you want to maintain common code using floating point between the two platforms. You need to be very aware of exactly what type each object inherits. Make sure you compile with /LIST/SHOW=STRUCTURE and check your listing file "Structure Layout Listing".

[Martin Michalecz]

John,
you wrote:
----------
When the PASCAL$MTH_ROUTINES was compiled to produce the PEN file, the type "SINGLE" was interpreted and written to the PEN file. Because of the way it was compiled, the function type is F_FLOAT.
----------

Maybe it's to hot in Austria at the moment or I need some holidays...

I always assumed, that the PEN File is compiled at the target system using the pas file. So the only way I could imagine was, that this compilation during the pascal installation (?) was performed using /FLOAT=G_FLOAT (or something like this).

Is this assumption correct ?


Lets summarize:

-) Recompiling ANY .PAS from SYS$LIBRARY at the targetsystem with default parameters (= IEEE settings) might produce wrong results. Right ?

-) Are all (!) standard .pen environmentfiles providing PASCAL$_.... and STARLET.PEN compiled with non IEEE mode ? Is there any change to check the IEEE format used in the environmentfile ?

-) Using an systemroutine using floating point in non IEEE mode will require code changes; either wrappers or modified entrypoints. Right ?

-) I do not yet see a possibible "conversion" between IEEE and non IEEE Formats. Even if I know that variable A_gf is g_flot formatted and B_ieee ist IEEE Format I do not see a possibility to declare them in ONE Pascal module and to convert from one to the other. Dius I miss some option to explizitly specify the floating format for an pascal variable / type ? An if I could specify the type, how would I perform the conversion (the compiler can't do that, I assume. Otherwise it would simple perform the task and not raise an error.

At the moment the problem / reason is clear. But I do not have an solution. I assume, that there will be other routines used in the application besides random which do not have an language builtin replacemant.

Kan you or anybody else give me an hint (or link)

Thanks and sorry if the question is to trivial.

Martin

[Brian Reiter]

Hi Martin,

We ended up specifying the default float using the /FLOAT switch on the compiler.

Did this, rather than digging through code fixing individual problems. Made life simple as it only affected the build procedures rather than the code, allowing us to keep the code common between the alpha and itanium version.

cheers

Brian

[Martin Michalecz]

Brian,

I guess you mean, you specified /FLAOT=G_FLOAT to force non-IEEE mode.

We are forced to use IEEE mode as oracle precomplers do not support any other floating point mode startin with oracle 10. This affects not only IA64 (where no oracle 9.x exists) but also AXP! (On AXP we currently plan to stay on Oracle 9 until end of life of the HW).

Thank's for your feedback, but I'm afraid we cannot go this way.

Martin

[John Reagan]

Lets see if I can answer all the questions:

- Yes, the PEN files built at Pascal installation time are compiled with /FLOAT=G_FLOAT

- Given the way SDL works and how we organize our SDL files, we end up with IEEE-flavor routines and VAX-flavor routines in the same Pascal source that wants to be pre-compiled. SDL doesn't have the ability to track F_FLOAT vs S_FLOAT. It just has a REAL type. So regardless of what qualifier we use, one will be wrong.

- Since Pascal is the only language with precompiled headers and floating support, you don't notice this from other languages. In C, you process the header each time you compile and you only call the routine that matches your float type. IE, you call MTH$RANDOM with /FLOAT=G_FLOAT or you call MTH$SRANDOM with /FLOAT=IEEE. You'll get the wrong behavior if you call the wrong one of course.

- Pascal is also the only language where we make an attempt to allow both flavors of floating formats in the same module. You can have F_FLOAT and S_FLOAT variables in the same module or even routine. Just don't try to mix them.

- If you want convert between VAX and IEEE, you have to call CVT$CONVERT_FLOAT (see SYS$LIBRARY:PASCAL$CVT_ROUTINES). Pascal will not do it for you.

- You can override parameter type checking by using foreign mechanism specifiers so you can do things like:

VAR S : S_FLOAT := 1.0;

LIB$WAIT(%REF S,,LIB$K_IEEE_S)

without the %REF, the compiler will tell you that the S_FLOAT actual parameter conflicts with the F_FLOAT formal from PASCAL$LIB_ROUTINES.PEN file. Routines like LIB$WAIT that aren't strongly typed (or if you prefer, overloaded) don't map well to Pascal's strong typing.

However, new for V6.0, you can now do

LIB$WAIT(%F_FLOAT 1.0);

even when IEEE floating is enabled. The compiler will do the right thing.

- While you can override the argument type checking and passing mechanisms by using foreign mechanism arguments, it isn't as easy to override floating function returns. On Alpha, floating results come back in F0/F1 for both VAX float and IEEE float. The compiler generates the same code for either. However on OpenVMS I64, IEEE float results come back in F8/F9 but VAX float results come back in R8/R9. So if you have a definition like MTH$SRANDOM (which isn't in PASCAL$MTH_ROUTINES for this reason) that would be compiled into a PEN file with /FLOAT=G_FLOAT, you couldn't call it from an IEEE-floating module since the compiler has been incorrectly told that that the floating result is VAX float, not IEEE float.

- So either use the Pascal random() function or use the %FLOAT lexical to determine what the default floating setting is and use either MTH$RANDOM from PASCAL$MTH_ROUTINES or declare and use MTH$SRANDOM.