Hi Dmitry,
Thanks for your analysis. Apart from the bug affecting the -O3 option,
it seems like this is just a trade-off issue of speed versus size, which
is fine. Speed is usually good :-) I was just surprised, since both the
overall size and speed of most things I have tried are better with mspgcc.
I do DSP with a hand crafted 16x16->32 Booth multiply routine for
software multiplies on a 1232 and a 135. Even here, when the software
spends a large proportion of its time in this one routine, mspgcc
achieves a substantial overall speedup, which really impressed me when I
first tried it.
Regards,
Steve
Dmitry wrote:
even more.
I just compiled this tcpip code and got about 11K data size.
Well... (I just installed xp and so I can check it with IAR)
this is true and probably cause of:
1. As I see IAR does lots of stuff as a subprogramm call. This is a serious
performance hit when, for example, one perform a multiplication within a
loop.
2. IAR does subprogram call for shifts and some other obviouses...
3. IAR keeps many local vars on stack and reload them as necessary.
This is a performance hit as well, yet can save some code space.
and I have no idea what's wrong with -O3. There was such an error a while ago
and it seems to me that only tcpip code can cause this error.
Also, in gcc still not implemented coloured reg allocater. So, there might be
some unnecessary register moves. I cannot do anything about it.
Concerning tcp/ip stack:
I cannot see any stupid register moves or redsudant code there. (except 2
places which are only 1 word rududant. for example:
mov r13,r12
clr r12
bis r14,r12
bis r15,r13
line 2 can be removed and line 4 changed)
However, for example, function 'PrepareICMP_ECHO' and others which do
something with MAC addresses are using inline 'memcpy' which are about 12
bytes each. Also, state-of-the-art peepholes make function 'GetTempVal' very
small :))
I actually cannot imagine how to make some stuff smaller. If you got any idea
- please let me know.
cheers,
~d
