[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gm2] LONGREAL
From: |
Jan Carpay |
Subject: |
[Gm2] LONGREAL |
Date: |
Fri, 15 Aug 2014 13:07:59 +0200 |
Hello,
I am trying to compile the libraries we used years ago with a Metrowerks
compiler on the mac with GM2 (in the mean time, we used Oberon, but I like M2
more).
Some of these are numerical and I wanted to compile them using LONGREALs by
putting REAL= LONGREAL in the def module, as I do not know of a compiler switch
that does that.
(A welcome side effect of this type redefinition was that a so-called spill
error, which has to do with the code generated by a .c file, disappeared, which
I could not manage in another way. It seems a bug in the toolchain.
)
Unfortunately this type change may generate a lot of work, as some expressions
involving real constants are not accepted.
E.g. in this routine (which compiles without errors in this version):
PROCEDURE RROUND(arg: REAL; places: INTEGER): REAL;
VAR Eplaces: REAL;
BEGIN
Eplaces:=PWI(1.0E1,places);
IF arg<0.0 THEN RETURN -LFLOAT(LTRUNC(LFLOAT(-arg*Eplaces+5.0E-1)))/Eplaces
ELSE RETURN LFLOAT(LTRUNC(LFLOAT(arg*Eplaces+5.0E-1)))/Eplaces
END;
END RROUND;
the inner LFLOAT in the RETURNs is required and cannot be placed around the
5E-1 alone. Similar strange requirements arise in other statements and they may
disappear when one of them is met (by adding some LONG conversion). All REAL
variables and parameters are seen as LONGREAL without problem.
Other procedures are not so short, so I forsee a lot of L-work.
I hope someone can shed a light on why/when real constants / expressions may
(not) be accepted, or even on the spill error (I use the version 1.0.1. of
april with gcc 4.1.2).
Thanks,
Jan Carpay
- [Gm2] LONGREAL,
Jan Carpay <=