4 ms·
Code generation is probably missing somewhat trivial optimizations. Here's one example: int func(int x) { return x * 1; } ...still produces unnecess
by vardump 10y ago
Code generation is probably missing somewhat trivial optimizations. Here's one example:
int func(int x) {
return x * 1;
}
...still produces unnecessary stack manipulation:
0000 C1 [10] 56 pop bc
0001 E1 [10] 57 pop hl
0002 E5 [11] 58 push hl
0003 C5 [11] 59 push bc
0004 C9 [10] 60 ret
Plain "ret" would have been enough.
- Lerc 10y agoDepends on how it expects the parameter and the result. If the parameter is the second item down on the stack and the compiler wants the result in hl with the stack unchanged. pop bc pop hl push hl push bc isn't redundant stack manipulation. it's moving stack values to bc and hl while keeping the stack unchanged. Of course at another level a compiler should be able to inline x=>x*1 but that depends on the build architecture. If it's a linkable function then the contents may be opaque to the code that calls it.
- vardump 10y agoOk, seems like you're right. In SDCC function params are always passed on stack, but return value in HL. So pop hl/push hl moves function parameter to return value register HL. (pop/push bc is of course just used to get past return address value in stack.) Seems odd compiler doesn't pass parameters in registers in a relatively register rich z80 arch.
- Questron 10y agoThere's also something else: Try shifting unsigned char x to right. >> 1 through 3 produce correct results, 4 changes the shift to some optimization too early, and the >> 5 the correctly optimized version. It's definitely not a very good compiler.