Hi,
during some debugging I noticed that GPC generates very hairy code
for the `mod' operator with signed arguments. A closer look revealed
that the code contains a lot of branching on conditions which can be
determined on compile time, and most surprisingly, the value of
X mod Y is recomputed _twice_, if X is negative. (I've attached
a commented assembler dump.)
This may be partially a back-end problem (CSE?), but I feel there's
something wrong in the relevant code in gpc-common.c (…
[View More]build_pascal_binary_op)
as well. `exp1 mod exp2' gets translated into something like
exp2 <= 0 ? error :
exp1 >= 0 ? exp1 mod exp2 :
((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2
This arranges that both arguments supplied to the "internal mod"
are non-negative, but this information is not passed on -- the arguments
are still declared as signed types, which apparently makes the back-end
to produce the mess it does. I've done a little test: the following
replacement for `mod', which differs from the built-in one essentially
just by the type-casts to `Cardinal',
inline operator xmod (X, Y: Integer) = Z: Integer;
begin
if Y <= 0 then RuntimeError (714);
if X >= 0 then Z := Cardinal (X) mod Y
else begin
Z := Cardinal (-X) mod Y;
if Z <> 0 then Z := Y - Z
end
end;
indeed generates a better code, it measures about 15% faster for
positive X and more than twice faster for negative X. YMMV.
If this is possible in user code, it should work in the compiler
internals as well :)
The result type of the whole `mod' expression looks dubious too.
IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result
of `mod' is guaranteed to be nonnegative and to fit in the type of exp2
(or more precisely, it is in 0 .. High (type of (exp2)) - 1),
whereas it needn't have anything to do with the type of exp1:
consider
var
X, Z: Integer;
Y: LongInt;
begin
X := -8;
Y := High (LongInt);
Z := X mod Y { -> overflow }
end
Or am I missing something?
Emil
(BTW, where is fjf434c.pas?)
[View Less]
Hi Gnu Pascal list,
we're currently using IBM's xpc pascal compiler on IBM AIX 5.3.
New machines are being shipped with AIX 6, and IBM's xpc is no longer
supported there - for the time being, it actuall works (the xpc frontend
generated intermediate code, and the second stage compiler still groks
it).
Management is not happy about this, as it might break any day, and I have
been asked to "provide GPC" on AIX 6.
Googling seems to suggest that the earliest release of GCC to work on
AIX 6 is …
[View More]gcc 4.2.4
This mailing list's archive suggests that GPC and GCC 4.2 do not yet
work together, due to larger efforts required due to backend changes
(Waldek's mail from March 12, 2008).
I reported this to management ("there is no GPC on AIX 6"), and they
came back with the question "if we pay one of the GPC developers to do
a GPC port to a recent GCC, to support AIX 6, how much would that
cost?".
Here we go - I'm posing this question to you. Is one of you capable
and willing to make GPC work on AIX 6? And if yes, what would your
conditions be (estimated time to do this, estimated costs)?
(I can't promise anything, but will report back to management and they
will decide...)
thanks,
gert
--
Gert Doering gd(a)medat.de
MEDAT Muenchen Tel: 089/126808-0 Fax: -50
[View Less]