ralf@ptavv.ka.sub.org (Ralf Wenk) (04/25/91)
Tonight when I try to compile lharc.c of the lharc 1.02 package I
got a misterious error message:
"cc000962.s", line 13: too big
Tracing this down to it roots I found that this part of a statement
causes the generation of a number which does not fit into the assembler
instruction it is assigned to.
int days;
days = 365 * ( year - 1970);
This is because the statement is calculated as
days = 356 * year - ( 365 * 1970 );
which is optimised by the compiler, regardless if the -O option is
used or not, to
days = 365 * year - 719050;
^^^^^^ is greater than 16 bit
The code generator generates a sub.w #719050,d? instruction which
is refused by the assembler as it should be. I do not know if this
is only a ACK ST problem. You can easily test it with:
main ()
{
int days, year;
year = 1991;
days = 365 * ( year - 1970);
pintf("days=%d\n", days );
} /* main */
--
--
Ralf Wenk -- ralf@ptavv.ka.sub.orgHBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (04/26/91)
Overflows when doing constant optimization is a mess -- I think c68 may well have problems with this, too. Stripping everything to 16 bits might be a solution, but causes unwanted results in other places. Stripping it to 16 bits when shipping out the assembler statement should be OK in all cases since all the constant terms are collected in a single additive term when folding such a constant. .. have to try this with c68 .. C.v.W>