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 it.
(also build_binary_op has misteriously lost last (default 0) argument).
Some changes may be mysterious, but this one is documented in the ChangeLog (2005-01-06).
And the demo breaks:
mtodorov@domac:~/rotltest$ cat rotl_bb.pas program rotlnnn (output);
var i0, i: Byte; j: Byte;
begin 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) else WriteLn ('OK') end. mtodorov@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@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