Hi, let me explain in details why am I asking this question. I'm worked on a project using C51(with it's linker). I could say many positive and negative things about it, but it generated ~120k of rather good code for a 8051 device.
So, now, I need to port this project to SDCC.
When I tried to build small tests with SDCC, everything looks good. Code size is half bigger, than Keil's, but this is not a very big problem. But when I tried to compile the whole project, after some playing with banked calls and so on, I've got a huge amount of code. Over 400k (Keil makes 120k).
So, the main question is the following: What's wrong? How to optimize a code for SDCC? Any tips and tricks?
Also, there's a lot of SLOC's using, but, as far as I understand they can be removed only by complete code refactoring, to
make it more easy for sdcc. So any advices would be very helpful.
I don't think there's much you can do here. You can try -opt-code-size. Or you can try to find some often recurring assembly sequences that you can optimize with custom peephole rules. How many SLOCs do you have? Can they be fitted in the utterly small data memory? You could also try -stack-auto.
I've read a manual, and tried to follow it's recommendations. Tried a lot of options and so on. So, seems like I must try assembly optimizing, and this is the only way. I've looked for a C tips and tricks for SDCC, but with no success.
About SLOC - I have over 512 bytes of SLOCs. This is much more than directly addressed memory in my 8051.
-nogcse helped me to significally reduce SLOCs, but I'm still used to mark many of my function REENTRANT to disable SLOCS creating. But I think this is not a solution, because I think it will cause stack overflow later.
Instead of making a lot of functions reentrant it's easier to use -stack-auto. This puts all local variables and parameters on stack. This costs a lot of stack space but the stack is better accessable than xdata for an mcs51 so it can also save some SLOCs. Furthermore the stack automatically overlays the data and that is something SDCC is not very good at for normal SLOCs. And finally the stack can use all idata from 0x08 to 0xFF ideally where SLOCs need data space from 0x08 to 0x7F. If you can take the code getting even bigger you may even try -xstack which gives full 256 bytes for a data stack and return addresses and SLOCs will use the normal stack. But with 512 SLOCs which are probably not all single bytes I'm not sure you will ever get to a point where things are working.
To fit this project's SLOCs in memory I have to mark some functions reentrant, because with -stack-auto I'll get stack overflow. So, some functions are reentrant and the other are not. I'll try to use -xstack, seems it will help to make directly addressing memory less fragmented.