Oleg Endo

It would require annotated function forward declarations everywhere. Otherwise the compiler can't know how to generate the call to the function.

I dug out my notes on that matter from a while ago. This is what I arrived at for a possibly improved mcs51 ABI: * call clobbered registers: r0-r3, a, b, dptr, carry flag * call saved registers: r4-r7, psw bank select bits * function arguments and return value: r0-r3 instead of { dpl, dph, b, a, r4. r5, r6, r7 } values are stuffed into registers as much as possible, the remaining go onto the stack. can pass/return 4x uint8_t, 2x uint16_t or 1x uint32_t directly in registers pointers are converted...

I know. But didn't want to do that for the bigger software. The asm diffs become difficult to check or so ;)

I had the carry flag working completely transparently, just like any other register. The reg set/use information should be already all there. The lines // If we don't know what it is, assume it might be used. // todo: allow a, and support it in removeDeadMove. // todo: allow dpl, dph, and support it in removeDeadMove. if (!(what[0] == 'r' && isdigit(what[1])) && !(what[0] == 'a' && what[0] == 'r' && isdigit(what[2]))) // Allow r? return (false); .. seem superfluous. scan4op will check it through...

Checked it again. Couldn't reproduce it. Probably my comparison setup was messed up. Your changes to pattern 302 don't seem to be causing this.

I've checked it again. Adding restart to peephole pattern 302 will give do the following in my software (see attached diff screenshot) In this case it's not a wrong-code. I guess it's actually not pattern 302 but another pattern that kicks in due to the restart. I see also several other improvements (more other patterns kicking in, e.g. for jumps ... ) when restart is added.

the 2 lines that you've added in [r14474] look buggy if (!strcmp (inst, "jnz") || !strcmp (inst, "jz")) aln->regsWritten = bitVectSetBit (aln->regsRead, A_IDX); should probably be: if (!strcmp (inst, "jnz") || !strcmp (inst, "jz")) aln->regsRead = bitVectSetBit (aln->regsRead, A_IDX);

I've spotted it by comparing the asm code of my software with some previous output of SDCC. It appears in the middle of larger functions... here's one example: mov ar2,r4 <<< unused store to ar2 mov ar3,r5 mov a,r3 jnb acc.7,00149$ mov r3,#0xff sjmp 00150$ My guess would be broken operand matching ..... there were quite a couple of cases which I ran into before, I wouldn't exlude any remaining bugs. Sorry, haven't checked though, just a guess.