Question Re: predef.h

[Frank Heckenbach]

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 at 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 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

-- 
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8