Question Re: predef.h
ih8mj at fjf.gnu.de
Tue Feb 21 03:58:16 CET 2006
Mirsad Todorovac wrote:
> Now, I was digging into it, and the new version keep complaining about the
> invalid operands to RotateLeft/RotateRight when argument is even a ''Byte''
> The predef.def lines look like (inherited from Pred/Succ, and worked
> before, in 2003 versions):
> PREDEF_ROUTINE (RotateLeft, "xv,r|", ER_CONST, GNU_PASCAL)
> PREDEF_ROUTINE (RotateRight, "xv,r|", ER_CONST, GNU_PASCAL)
> In fact, I was going through the source quite a bit before and now, and I
> still can't seem to catch all the tricks of this "signature" string ...
Searching for the character in '' in predef.c sometimes helps:
case 'r': case 'e': if (!INT_REAL (code)) errstr = "argument %d to `%s' must be a real or an integer"; break;
case 'v': if (!ORDINAL_OR_REAL_TYPE (code) && code != POINTER_TYPE) errstr = "argument %d to `%s' must be of ordinal, real or pointer type"; break;
I don't think you want real types here. (You probably took it from
`Succ', but `Succ' for reals is a GPC extension.) You probably don't
want pointers either (pointer arithmetics *can* be strange, but
rotation, well, no :-).
The `,' means optional parameters follow (for `Succ' that's
according to the standards, for rotations we'd have to decide if we
want it -- if so, the code in predef.c must handle this case and
supply the missing parameters, here probably 1). The part after `|'
is the signature of the RTS routine which may be the same as the
Pascal-level one (then `|...' is omitted), or different if the
compiler does some magic, or missing for completely inlined
routines, such as here (then there's nothing after the `|').
BTW, feel free to write this up more formally and completely as a
chapter in internals.texi. :-) I'm afraid I don't have the time to
do it (but I could proofread your writing if you do) ...
> I see that now build_binary_op is depracated and abandoned in favor of
> build_pascal_binary_op. Is that the problem
Probably not the problem, though you should do the same when you add
> (also build_binary_op has
> misteriously lost last (default 0) argument).
Some changes may be mysterious, but this one is documented in the
> And the demo breaks:
> mtodorov at domac:~/rotltest$ cat rotl_bb.pas
> program rotlnnn (output);
> var i0, i: Byte;
> j: Byte;
> i0 := 1;
> j := BitSizeof (i0) + 1;
> i := RotateLeft (i0, j);
> if i <> RotateLeft (i0, 1) then
> WriteLn ('failed : i: Byte = 1; j: Byte = ', j, '; RotateLeft(i, j) = ', i)
> WriteLn ('OK')
> mtodorov at domac:~/rotltest$ gpc rotl_bb.pas
> rotl_bb.pas: In main program:
> rotl_bb.pas:13: error: invalid operands to `RotateLeft'
> rotl_bb.pas:14: error: invalid operands to `RotateLeft'
> mtodorov at domac:~/rotltest$
This message doesn't come from predef.c, but from expressions.c (you
find the text in binary_op_error()) which is called from
build_binary_op() (`if (!result_type)') -- all the other calls are
for specific operands or types, so it must be this one. So you'd
have to add some code in build_binary_op() (and
build_pascal_binary_op()) to support it.
But, BTW, you remember of discussions back then about principal
problems such as well-defined results (here: RotateLeft (i0 + 0, j)
would yield a different result, when `+' is evaluted in `Integer',
very strange), and my suspicion that it might not be worth the
trouble to build it in? (Perhaps a pseudo-procedure with a
pseudo-var-parameter would help to avoid the type-size issues. I
think we've talked about this, but I don't remember the conclusion.
If you don't have the old mails handy, I could probably look it up.)
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
More information about the Gpc