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
On Wednesday 27 November 2002 17:41, Steve Underwood wrote:
> Hi Dmitry,
>
> Well, I tried:
>
> -O0 and got 0x3120 bytes
>
> -O1 and got 0x2D40 bytes
>
> -O2 and got 0x2CD0 bytes
>
> -O3 and got
> "tcpip.c:603: Internal compiler error in verify_local_live_at_start,
> at flow.c:583"
> "Please submit a full bug report,"
>
> So, here is my bug report. Me thinks the last one give the minimum
> output code - zero bytes!
>
> Seriously, I don't know if the -O3 issue is a bug or something that is
> just not implemented yet in mspgcc. However, I am surprised that IAR
> achieves a size more like 0x2200 bytes. Its quite a big difference. I'll
> have to look through the source code and see if there are any material
> differences between the original code and the mspgcc version. This is
> the first time I have found IAR produce a smaller binary.
>
> On the other hand IAR always seems to beat mspgcc hands down on floats
>
> :-) That said, IARs performance on floats is not very good, so I guess
>
> there is substantial room for improvement in mspgcc.
>
> Regards,
> Steve
>
> Dmitry wrote:
> >this probably some optimization issue.
> >
> >Try different -O options.
> >
> >The thing I know for sure is that run time performance now is much better.
> >
> >~d
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
