Code size optimization question

Den Akopov
2011-04-05
2013-03-12
  • Den Akopov
    Den Akopov
    2011-04-05

    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.

    Regards,
    Den

     
  • Maarten Brock
    Maarten Brock
    2011-04-06

    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.

    Maarten

     
  • Den Akopov
    Den Akopov
    2011-04-06

    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.

     
  • Maarten Brock
    Maarten Brock
    2011-04-06

    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.

     
  • Den Akopov
    Den Akopov
    2011-04-07

    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.