Only the low bytes are compared. Originally, signed 16-bit compares were optimized into signed 8-bit compares. But, the sign bits are in the high bytes; and, they're equal. Therefore, the low bytes always must be compared as unsigned numbers.
Fixes#1348.
Certain scenarios (e.g. not running any Applesoft program at all since booting DOS 3.3) can make DOS 3.3 consider cc65 device input (e.g. getchar()) that reads a CR interpreting the command in the keyboard buffer. Setting the hibyte of the Applesoft currently executed line number to some value <> $FF (beside setting the input prompt to some value <> ']') makes DOS 3.3 understand that we're not in intermediate mode and that therefore I/O not preceded with ctrl-d mustn't be fiddled with (see DOS 3.3 routine at $A65E).
ca65's logical (Boolean) NOT operator was used where bitwise NOT should be used. The effect was that all sprites were shifted to the left side of a screen when the mouse sprite was put on the left side.
The old broken code defers the count until the end of the (parent function's) argument list. But, a nested function call clears the pointer to the deferred type. That leads to an access violation.
The new code defers only until the end of each argument. Fixes#1320.
I placed the Git tag V2.19 in hindsight at 555282497c. But I certainly don't want to rewrite the Git history just for the reported version, so I simply set the reported version at today's HEAD to 2.19.
When there is an integral constant like `3` in an expression, it has
type `int` according to the C spec, even though it can be represented
as an `unsigned char`. Change codegen (`hie_internal` and `typeadjust`)
to treat it as `unsigned char` instead of `int` so that faster,
unsigned operations can be used.
For the test case in #1298, reduces the cycles per iteration from
4311 to 1884. This is a great improvement, but still much worse than
the 1053 cycles/iter from `c4698df~`, so more work remains to be done.
Further partial fix for #1298 and #1308.
