We have run into problems where the code optimizer
generates wrong assembler code under certain conditions.
Here is a piece of sample code which triggers the problem:
unsigned char Instruction_einlesen(unsigned data char
unsigned data char rw=0;
unsigned data char c=0;
unsigned data char i=0;
unsigned data char *ins1=ins;
The optimizer rearranges the for loop to count from 8
down to 1. Therefore ins1 is written in reverse order.
I send the resulting assemble code as attachment, which
shows the effect in detail.
We have used win32 binaries, versions 2.3.1-pj1 and the
snapshot from February 7, both show the same effect.
sdcc 2.2.1 on linux does NOT exhibit this wrong
behaviour, i.e. it compiles the same code sequence