ark (10/21/82)
There is a bug in the Berkeley Pascal compiler which surfaces
whenever an integer constant in the range [128,255] or [32767,65535]
is assigned to a real variable. Essentially, the code generator
realizes the number can be contained in an unsigned byte (or word),
and if the destination were an integer it would generate a movzbl
(or movzwl) instruction. However, since the destination is real, it
goes ahead and generates a cvtbd (or cvtwd) instruction, which gives
the wrong answer. The fix is in /usr/src/cmd/pcc/UClocal2.c:
--> line 239 in our version r->in.type = (r->tn.lval >= 0 ?
(r->tn.lval <= 63 ? INT
: ( r->tn.lval <= 127 ? CHAR
: (r->tn.lval <= 255 ? UCHAR
: (r->tn.lval <= 32767 ? SHORT
: (r->tn.lval <= 65535 ? USHORT
: INT ))))) : r->in.type );
--> start of inserted code /*
* we can convert unsigned byte->long with
* movzbl, but there is no corresponding
* unsigned byte -> float instruction.
* Thus, if the destination is float, force
* the source to be signed.
*/
if (l->in.type==FLOAT || l->in.type==DOUBLE) {
if (r->in.type == UCHAR)
r->in.type = SHORT;
else if (r->in.type == USHORT)
r->in.type = INT;
--> end of inserted code }
}
else
{
printf("moval");
printf(" ");
acon(r);
printf(",");
adrput(l);
return;
}