Most of the time it gets these right, but sometimes it decides to compare an 8bit value with a constant that will fit in 8bits by writing bizarre code where it loads registers with 0, ors them and carefully checks for zero/nonzero.
I finally managed to narrow down an example showing the bad case
sdcc #9369
sdcc -mz80 --max-allocs-per-node 200000 /tmp/silly.c
note how the second "if" is evaluated !
TOKENIZER_COMMA is an integer constant. SDCC casts the uint8_t to int, then compares. We are lucky that somehow SDCC manages to optimize the comparison into an unsigned int comparison (as signed comparisons on z80 are inefficient).
SDCC should optimize the comparison into an 8-bit comparison.
Workaround until SDCC is improved: Make TOKENIZER_COMMA an uint8_t.
Philipp
Hi,
I just compiled this to see if it affected stm8 too... but it does not seem to fail here currently for z80. At least i do not see any zeros loaded regs or the silly orring.
Did this disappear or move around?.
Thanks,
/pedro
I though this optimization has already been done by Philipp in reversion #9442 or reversion #9447.
TOKENIZER_COMMA is an unsigned int in AST but then optimized to unsigned char in the icode list.
Here is the AST and icode list by current SDCC.
Ticket moved from /p/sdcc/bugs/2429/
Can't be converted:
A bit late, but still I move this to feature requests because there was no bad code generated. Only a missed optimization.