Thread: Re: [sdcc-devel] Plan for sdcc 2.7.0 (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi,

in the sdccman.lyx, chapter "4.6 The PIC16 port", there is a table of 
supported PIC devices, which I'm pretty sure is not complete.

Raphael, can you please review / update it?

Borut

Hi Borut,

> in the sdccman.lyx, chapter "4.6 The PIC16 port", there is a table of 
> supported PIC devices, which I'm pretty sure is not complete.
> 
> Raphael, can you please review / update it?

Done.

I revised the whole PIC14 and PIC16 documentation, added HOWTOs on 
adding devices to PIC14/16 ports, removed unused command-line options 
from pic16 port. Committed all as r4790; hopefully I did not break any 
LyX-related stuff...

Regards,
Raphael

I may have found something. When peepholes are applied 
it doesn't restart at the first replaced line but 
instead at the line following the first replaced line. 
When a peephole replaces with nothing (not even a 
comment) this means the next line is skipped.

This results in the following being only partially 
replaced (peephole 1):

ld b,a
ld c,c  ;should be removed
ld b,b  ;should be removed

becomes

ld b,a
ld b,b  ;but it isn't

Now the next rule (peephole 2) is applied incorrectly 
and it becomes:

ld b,b

Which eventually, after a restart will be eliminated 
too.

So the bug was peephole rule 2 not checking %1 and %3 
being the same. And it also should check %3 is not 
volatile.

It was obscured due to the fact that with --fverbose-asm 
the replacement was not empty, but a comment line which 
could be safely skipped anyway. And thus ld b,b was 
removed early as it was meant.

Maybe bug 1677178 (Some peephole rules ignored) is 
caused by this too.

Still investigating,
Maarten

> Ok, I built the libraries with and without --fverbose-
> asm and guess what, they show some significant 
> differences! The following z80 library modules are 
> different, but the same is happening for other targets.
> 
> \device\lib\build\z80\_atol.asm
> \device\lib\build\z80\ceilf.asm
> \device\lib\build\z80\printf_large.asm
> \device\lib\build\z80\time.asm
> 
> See the attached diff for the details.
> 
> My guess right now is that --fverbose-asm introduced a 
> bug that was not detected by the regression tests before 
> the latest z80 peephole rules were added. The simple 
> solution seems to be to always enable -fverbose-asm.
> 
> Maarten
> 
> > After the clean rebuild I reproduced the problem on Windows mingw too.
> > 
> > Borut
> > 
> > 
> > Borut Razem wrote:
> > > Maarten Brock wrote:
> > >> I did a clean checkout and could reproduce the problem also.
> > >>
> > >> Next I tried your proposed vpath but it fails with files it cannot 
> > >> find. I guess you cannot use it unless you've cleaned the original 
> > >> first.
> > >>
> > >>   
> > >
> > > Yes, that's right.
> > >
> > >> Instead I did another clean checkout now and will build it with the 
> > >> --fverbose-asm modification to the Makefile to see if that solves it 
> > >> again.
> > >>
> > >>   
> > >
> > > It is the best you can do to be sure that everything is OK.
> > >
> > >> I'm just guessing here because I can't think of anything better.
> > >>
> > >> Maarten
> > >>   
> > >
> > > In the mean time I tried to reproduce the problem on Windows with 
> > > mingw build, and (guess what?) I couldn't. Now I'll remove the build 
> > > directory and retry the build...
> > >
> > > Borut
> 
> 

Maarten,

I see that reg. tests passed in today's snapshot build, but I'm puzzled: 
is the bug fixed? Which change fixed it?

Borut

Maarten Brock wrote:
> I may have found something. When peepholes are applied 
> it doesn't restart at the first replaced line but 
> instead at the line following the first replaced line. 
> When a peephole replaces with nothing (not even a 
> comment) this means the next line is skipped.
>
> This results in the following being only partially 
> replaced (peephole 1):
>
> ld b,a
> ld c,c  ;should be removed
> ld b,b  ;should be removed
>
> becomes
>
> ld b,a
> ld b,b  ;but it isn't
>
> Now the next rule (peephole 2) is applied incorrectly 
> and it becomes:
>
> ld b,b
>
> Which eventually, after a restart will be eliminated 
> too.
>
> So the bug was peephole rule 2 not checking %1 and %3 
> being the same. And it also should check %3 is not 
> volatile.
>
> It was obscured due to the fact that with --fverbose-asm 
> the replacement was not empty, but a comment line which 
> could be safely skipped anyway. And thus ld b,b was 
> removed early as it was meant.
>
> Maybe bug 1677178 (Some peephole rules ignored) is 
> caused by this too.
>
> Still investigating,
> Maarten
>
>   
>> Ok, I built the libraries with and without --fverbose-
>> asm and guess what, they show some significant 
>> differences! The following z80 library modules are 
>> different, but the same is happening for other targets.
>>
>> \device\lib\build\z80\_atol.asm
>> \device\lib\build\z80\ceilf.asm
>> \device\lib\build\z80\printf_large.asm
>> \device\lib\build\z80\time.asm
>>
>> See the attached diff for the details.
>>
>> My guess right now is that --fverbose-asm introduced a 
>> bug that was not detected by the regression tests before 
>> the latest z80 peephole rules were added. The simple 
>> solution seems to be to always enable -fverbose-asm.
>>
>> Maarten
>>
>>     
>>> After the clean rebuild I reproduced the problem on Windows mingw too.
>>>
>>> Borut
>>>
>>>
>>> Borut Razem wrote:
>>>       
>>>> Maarten Brock wrote:
>>>>         
>>>>> I did a clean checkout and could reproduce the problem also.
>>>>>
>>>>> Next I tried your proposed vpath but it fails with files it cannot 
>>>>> find. I guess you cannot use it unless you've cleaned the original 
>>>>> first.
>>>>>
>>>>>   
>>>>>           
>>>> Yes, that's right.
>>>>
>>>>         
>>>>> Instead I did another clean checkout now and will build it with the 
>>>>> --fverbose-asm modification to the Makefile to see if that solves it 
>>>>> again.
>>>>>
>>>>>   
>>>>>           
>>>> It is the best you can do to be sure that everything is OK.
>>>>
>>>>         
>>>>> I'm just guessing here because I can't think of anything better.
>>>>>
>>>>> Maarten
>>>>>   
>>>>>           
>>>> In the mean time I tried to reproduce the problem on Windows with 
>>>> mingw build, and (guess what?) I couldn't. Now I'll remove the build 
>>>> directory and retry the build...
>>>>
>>>> Borut
>>>>         
>>     
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>   

Borut,

Peephole rule 2 was the real culprit. It needed to check 
%1 and %3 (in the original) were not the same. It also 
needed to check %2 for volatile. Since operandsNotSame 
can only check %1 and %2, I rearranged the operands and 
added the necessary checks. So much for code review btw 
:(

The other problem with continuing with the wrong line I 
will fix soon too.

I also fixed bug 1714204 for the ds390 today because it 
was easy.

Maarten

> Maarten,
> 
> I see that reg. tests passed in today's snapshot build, but I'm puzzled: 
> is the bug fixed? Which change fixed it?
> 
> Borut
> 
> 
> Maarten Brock wrote:
> > I may have found something. When peepholes are applied 
> > it doesn't restart at the first replaced line but 
> > instead at the line following the first replaced line. 
> > When a peephole replaces with nothing (not even a 
> > comment) this means the next line is skipped.
> >
> > This results in the following being only partially 
> > replaced (peephole 1):
> >
> > ld b,a
> > ld c,c  ;should be removed
> > ld b,b  ;should be removed
> >
> > becomes
> >
> > ld b,a
> > ld b,b  ;but it isn't
> >
> > Now the next rule (peephole 2) is applied incorrectly 
> > and it becomes:
> >
> > ld b,b
> >
> > Which eventually, after a restart will be eliminated 
> > too.
> >
> > So the bug was peephole rule 2 not checking %1 and %3 
> > being the same. And it also should check %3 is not 
> > volatile.
> >
> > It was obscured due to the fact that with --fverbose-asm 
> > the replacement was not empty, but a comment line which 
> > could be safely skipped anyway. And thus ld b,b was 
> > removed early as it was meant.
> >
> > Maybe bug 1677178 (Some peephole rules ignored) is 
> > caused by this too.
> >
> > Still investigating,
> > Maarten
> >
> >   
> >> Ok, I built the libraries with and without --fverbose-
> >> asm and guess what, they show some significant 
> >> differences! The following z80 library modules are 
> >> different, but the same is happening for other targets.
> >>
> >> \device\lib\build\z80\_atol.asm
> >> \device\lib\build\z80\ceilf.asm
> >> \device\lib\build\z80\printf_large.asm
> >> \device\lib\build\z80\time.asm
> >>
> >> See the attached diff for the details.
> >>
> >> My guess right now is that --fverbose-asm introduced a 
> >> bug that was not detected by the regression tests before 
> >> the latest z80 peephole rules were added. The simple 
> >> solution seems to be to always enable -fverbose-asm.
> >>
> >> Maarten
> >>
> >>     
> >>> After the clean rebuild I reproduced the problem on Windows mingw too.
> >>>
> >>> Borut
> >>>
> >>>
> >>> Borut Razem wrote:
> >>>       
> >>>> Maarten Brock wrote:
> >>>>         
> >>>>> I did a clean checkout and could reproduce the problem also.
> >>>>>
> >>>>> Next I tried your proposed vpath but it fails with files it cannot 
> >>>>> find. I guess you cannot use it unless you've cleaned the original 
> >>>>> first.
> >>>>>
> >>>>>   
> >>>>>           
> >>>> Yes, that's right.
> >>>>
> >>>>         
> >>>>> Instead I did another clean checkout now and will build it with the 
> >>>>> --fverbose-asm modification to the Makefile to see if that solves it 
> >>>>> again.
> >>>>>
> >>>>>   
> >>>>>           
> >>>> It is the best you can do to be sure that everything is OK.
> >>>>
> >>>>         
> >>>>> I'm just guessing here because I can't think of anything better.
> >>>>>
> >>>>> Maarten
> >>>>>   
> >>>>>           
> >>>> In the mean time I tried to reproduce the problem on Windows with 
> >>>> mingw build, and (guess what?) I couldn't. Now I'll remove the build 
> >>>> directory and retry the build...
> >>>>
> >>>> Borut
> >>>>         
> >>     
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > sdcc-devel mailing list
> > sdc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-devel
> >
> >   
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
> 

Maarten Brock wrote:
> Borut,
>
> Peephole rule 2 was the real culprit. It needed to check 
> %1 and %3 (in the original) were not the same. It also 
> needed to check %2 for volatile. Since operandsNotSame 
> can only check %1 and %2, I rearranged the operands and 
> added the necessary checks. So much for code review btw 
> :(
>
> The other problem with continuing with the wrong line I 
> will fix soon too.
>
>   

Maarten, I have a small problem: I'll be absent between (including) 12. 
and 19.05.2007, so I won't be able to make a release candidate in that 
period. Will you take care to make the RC1 build if it will be delayed 
after 11.05?

Borut

Borut,

>> The other problem with continuing with the wrong line I
>> will fix soon too.

I'll try to get this done this evening.

> Maarten, I have a small problem: I'll be absent between (including) 12.
> and 19.05.2007, so I won't be able to make a release candidate in that
> period. Will you take care to make the RC1 build if it will be delayed
> after 11.05?

I'm willing but don't know how. If you want to change the date to an
earlier one, just say so. I have no objections.

Maarten

Borut,

> >> The other problem with continuing with the wrong line I
> >> will fix soon too.
> 
> I'll try to get this done this evening.

I just commited it. Apart from the KnownBugs.html list I 
have nothing on my list for the 2.7.0 release anymore.

Greetings,
Maarten

I think that we are ready for the first 2.7.0 release candidate.

I plan to make the 2.7.0 RC1 build from tomorrow's (2007-05-10) snapshot 
build.
If anybody has a last minute wish, please me know ASAP.

Actually I have one ;-) :
we definitely have to explain that the inline functionality is in alpha 
quality. The question is where to put it: only to the "SDCC 2.7.0 
Feature List" or maybe also to sdccman?

Erik, can you please decide and put it somewhere (this can be also done 
after RC1 but before RC2 which will be probably considered as the 2.7.0 
release if nothing critical will be found)?

The KnownBugs.html probably won't be ready for RC1 too, but is should be 
in RC2.

Borut

Maarten Brock wrote:
> Borut,
>
>   
>>>> The other problem with continuing with the wrong line I
>>>> will fix soon too.
>>>>         
>> I'll try to get this done this evening.
>>     
>
> I just commited it. Apart from the KnownBugs.html list I 
> have nothing on my list for the 2.7.0 release anymore.
>
> Greetings,
> Maarten
>   

Borut Razem schrieb:

> Actually I have one ;-) :
> we definitely have to explain that the inline functionality is in alpha 
> quality. The question is where to put it: only to the "SDCC 2.7.0 
> Feature List" or maybe also to sdccman?

If it really is alpha quality I'd suggest a compiler warning when inline
functions are compiled.

Philipp

Philipp Klaus Krause wrote:
> Borut Razem schrieb:
>
>   
>> Actually I have one ;-) :
>> we definitely have to explain that the inline functionality is in alpha 
>> quality. The question is where to put it: only to the "SDCC 2.7.0 
>> Feature List" or maybe also to sdccman?
>>     
>
> If it really is alpha quality I'd suggest a compiler warning when inline
> functions are compiled.
>   

I think that Erik should decide about that.
Erik, what actually happens when the address of a inlined function is taken?

Borut

On Wed, 9 May 2007, Borut Razem wrote:

> >> Actually I have one ;-) :
> >> we definitely have to explain that the inline functionality is in alpha 
> >> quality. The question is where to put it: only to the "SDCC 2.7.0 
> >> Feature List" or maybe also to sdccman?
> >>     
> >
> > If it really is alpha quality I'd suggest a compiler warning when inline
> > functions are compiled.
> >   
> 
> I think that Erik should decide about that.
> Erik, what actually happens when the address of a inlined function is taken?

Nothing special happens at the moment; that is the problem. Here are the
three cases to consider:

1) Function is declared "static inline". The linkage is internal, so no
other files can reference this function. The compiler assumes that it can
inline the function when needed and so does not generate a stand-alone
version of the function. If a stand-alone version of the function is
eventually needed (to satisfy the address-of reference), currently the
linker will throw an error because the stand-alone version won't be found.

2) Function is declared "inline" but not "static" or "extern". The linkage
is external, but the C standard requires that the programmer also provides
a non-inline definition. No stand-alone version of the inlined function is
generated and any references to a stand-alone version of the function must
be satisfied by the non-inlined definition of the function. The address-of
operator should work as long as the programmer follows the C standard.

3) Function is declared "extern inline". The linkage is external and the C
standard states that this inline definition of the function is also the
external definition. Thus a stand-alone version is generated from this
definition, but inlining is also performed where possible. The address-of
operator always works.

After enumerating these cases, it looks like an easy fix would be to go
ahead and always generate the stand-alone version in case #1. The
generated code size would be less than ideal in most cases, but at least
it should be functionally correct.

  Erik

Dear sdcc developers,

please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and small fixes in the documentation (wrong version number, spelling mistakes, ...) can be committed.

The SDCC 2.7.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.7.0+Release.

Borut

SDCC 2.7.0 Release Candidate 1 source, doc and binary packages for x86 Linux, 32 bit Windows and ppc Mac OS X are available at:
http://sdcc.sourceforge.net/snapshots/sdcc-2.7.0-rc1
and
http://sdcc.sourceforge.net/snap.php

If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li....

Borut

SDCC 2.7.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and ppc Mac OS X are available at:
http://sdcc.sourceforge.net/snapshots/sdcc-2.7.0-rc2
and
http://sdcc.sourceforge.net/snap.php

If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li....

Borut

Borut,

    SDCC 2.7.0 RC2 Z80 port works well with our software. Hope to see 2.7.0 
final soon.

Woody

AR1688/PA1688 based IP phone mailing list --  
http://groups.yahoo.com/group/pa1688/
VOIP/AR1688 BLOG -- http://aredfox.spaces.live.com/
MSN: wo...@ar...

----- Original Message ----- 
From: "Borut Razem" <bor...@si...>
To: "Development chatter about sdcc" <sdc...@li...>
Cc: "Sdcc-User" <sdc...@li...>
Sent: Wednesday, May 23, 2007 2:20 AM
Subject: [Sdcc-user] SDCC 2.7.0 Release Candidate 2

> SDCC 2.7.0 Release Candidate 2 source, doc and binary packages for x86 
> Linux, 32 bit Windows and ppc Mac OS X are available at:
> http://sdcc.sourceforge.net/snapshots/sdcc-2.7.0-rc2
> and
> http://sdcc.sourceforge.net/snap.php
>
> If you find a mistake, please send a mail to sdcc-devel mailing list 
> sdc...@li....
>
> Borut
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 

Lin Rongrong wrote:
> Borut,
>
>     SDCC 2.7.0 RC2 Z80 port works well with our software. Hope to see 2.7.0 
> final soon.
>   

Thank you very much for the report. I just released the SDCC 2.7.0 RC3. 
Can you try this one too?

The final release is planned for 2007-05-31.

Borut

Borut,

    Sure, we will include it in daily test on Monday, May 28.

Woody

AR1688/PA1688 based IP phone mailing list --  
http://groups.yahoo.com/group/pa1688/
VOIP/AR1688 BLOG -- http://aredfox.spaces.live.com/
MSN: wo...@ar...

----- Original Message ----- 
From: "Borut Razem" <bor...@si...>
To: "Development chatter about sdcc" <sdc...@li...>
Sent: Saturday, May 26, 2007 10:06 PM
Subject: Re: [sdcc-devel] [Sdcc-user] SDCC 2.7.0 Release Candidate 2

> Lin Rongrong wrote:
>> Borut,
>>
>>     SDCC 2.7.0 RC2 Z80 port works well with our software. Hope to see 
>> 2.7.0
>> final soon.
>>
>
>
> Thank you very much for the report. I just released the SDCC 2.7.0 RC3.
> Can you try this one too?
>
> The final release is planned for 2007-05-31.
>
> Borut
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
> 

SDCC 2.7.0 Release Candidate 3 source, doc and binary packages for x86 Linux, 32 bit Windows and ppc Mac OS X are available at:
http://sdcc.sourceforge.net/snapshots/sdcc-2.7.0-rc3
and
http://sdcc.sourceforge.net/snap.php

This is an additional unplanned release candidate where all currently known bugs, planned for sdcc 2.7.0 release, are fixed.
The target date for sdcc 2.7.0 release is still 2007-05-31.

If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li....

Borut

Borut,

This RC3 is not referenced on the SDCC home page.

And I just looked in the manual and found that 8.3 ANSI-
Compliance still mentions inline as non-supported. Maybe 
that line should be removed.

I was looking because of the new bug 1726590 which I do 
not consider critical for the release, but could be 
fixed with some addition to the manual. We could make 
the request for a better error an RFE.

Maarten

> SDCC 2.7.0 Release Candidate 3 source, doc and binary packages for x86 Linux, 32 bit Windows and ppc Mac OS X are available at:
> http://sdcc.sourceforge.net/snapshots/sdcc-2.7.0-rc3
> and
> http://sdcc.sourceforge.net/snap.php
> 
> This is an additional unplanned release candidate where all currently known bugs, planned for sdcc 2.7.0 release, are fixed.
> The target date for sdcc 2.7.0 release is still 2007-05-31.
> 
> If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li....
> 
> Borut
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
> 

SDCC 2.8.0 Release Candidate 1 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available at:
http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc1
and
http://sdcc.sourceforge.net/snap.php

If you find a mistake, please send a mail to sdcc-devel mailing list sdc...@li....

I would appreciate any reports about a success or failure of running pre-compiled binary packages, specially on Mac OS X platforms:
- ppc Mac OS X 10.4.x and 10.5.x
- i386 Mac OS X 10.4.x and 10.5.x

Borut

Just tested the Z80 port of release candidate 1, no obvious bug found so 
far, but I noticed a 2%-5% increase in code size comparing with 2.7.0.

Woody

AR1688 and PA1688 based IP phone mailing list --  
http://groups.yahoo.com/group/pa1688/
VOIP and AR1688 BLOG -- http://aredfox.spaces.live.com/
MSN: wo...@ar...

----- Original Message ----- 
From: "Borut Razem" <bor...@si...>
To: "Development chatter about sdcc" <sdc...@li...>
Cc: "Sdcc-User" <sdc...@li...>
Sent: Sunday, March 09, 2008 9:19 PM
Subject: [sdcc-devel] SDCC 2.8.0 Release Candidate 1

> SDCC 2.8.0 Release Candidate 1 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available at:
> http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc1
> and
> http://sdcc.sourceforge.net/snap.php
>
> If you find a mistake, please send a mail to sdcc-devel mailing list 
> sdc...@li....
>
> I would appreciate any reports about a success or failure of running 
> pre-compiled binary packages, specially on Mac OS X platforms:
> - ppc Mac OS X 10.4.x and 10.5.x
> - i386 Mac OS X 10.4.x and 10.5.x
>
> Borut
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lin Rongrong schrieb:
> Just tested the Z80 port of release candidate 1, no obvious bug found so 
> far, but I noticed a 2%-5% increase in code size comparing with 2.7.0.
> 

Can you provide some code samples where the code size increase is most
noticeable, along with the generated .asm files from both 2.7.0 and
2.8.0 RC1? What are the command line options you used?

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH1C3dbtUV+xsoLpoRAhZrAKCMtmvWCf29fMd5no+YgU2rf42CLgCgvm7g
RoW7QscppXcZQEupYpYUerE=
=NXlj
-----END PGP SIGNATURE-----

Just tested a small MCS51 program of mine, with 2.7.0 the binary size is 
2797 bytes, with 2.8.0 RC1 the binary size is 2755 bytes
My Z80 programs are rather large, totally near 190k bytes in binary, will 
check detail difference later.

Woody

AR1688 and PA1688 based IP phone mailing list --  
http://groups.yahoo.com/group/pa1688/
VOIP and AR1688 BLOG -- http://aredfox.spaces.live.com/
MSN: wo...@ar...

----- Original Message ----- 
From: "Lin Rongrong" <wo...@di...>
To: "Development chatter about sdcc" <sdc...@li...>
Cc: <sdc...@li...>
Sent: Monday, March 10, 2008 2:51 AM
Subject: Re: [sdcc-devel] SDCC 2.8.0 Release Candidate 1

> My command line option is most common "-mz80 -c --codeseg CODE".
> I will check details asm difference tomorrow.
>
> Woody
>
> AR1688 and PA1688 based IP phone mailing list --
> http://groups.yahoo.com/group/pa1688/
> VOIP and AR1688 BLOG -- http://aredfox.spaces.live.com/
> MSN: wo...@ar...
>
>
> ----- Original Message ----- 
> From: "Philipp Klaus Krause" <pk...@sp...>
> To: "Development chatter about sdcc" <sdc...@li...>
> Cc: <sdc...@li...>
> Sent: Monday, March 10, 2008 2:35 AM
> Subject: Re: [sdcc-devel] SDCC 2.8.0 Release Candidate 1
>
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Lin Rongrong schrieb:
>>> Just tested the Z80 port of release candidate 1, no obvious bug found so
>>> far, but I noticed a 2%-5% increase in code size comparing with 2.7.0.
>>>
>>
>> Can you provide some code samples where the code size increase is most
>> noticeable, along with the generated .asm files from both 2.7.0 and
>> 2.8.0 RC1? What are the command line options you used?
>>
>> Philipp
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFH1C3dbtUV+xsoLpoRAhZrAKCMtmvWCf29fMd5no+YgU2rf42CLgCgvm7g
>> RoW7QscppXcZQEupYpYUerE=
>> =NXlj
>> -----END PGP SIGNATURE-----
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel 

My command line option is most common "-mz80 -c --codeseg CODE".
I will check details asm difference tomorrow.

Woody

AR1688 and PA1688 based IP phone mailing list --  
http://groups.yahoo.com/group/pa1688/
VOIP and AR1688 BLOG -- http://aredfox.spaces.live.com/
MSN: wo...@ar...

----- Original Message ----- 
From: "Philipp Klaus Krause" <pk...@sp...>
To: "Development chatter about sdcc" <sdc...@li...>
Cc: <sdc...@li...>
Sent: Monday, March 10, 2008 2:35 AM
Subject: Re: [sdcc-devel] SDCC 2.8.0 Release Candidate 1

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lin Rongrong schrieb:
>> Just tested the Z80 port of release candidate 1, no obvious bug found so
>> far, but I noticed a 2%-5% increase in code size comparing with 2.7.0.
>>
>
> Can you provide some code samples where the code size increase is most
> noticeable, along with the generated .asm files from both 2.7.0 and
> 2.8.0 RC1? What are the command line options you used?
>
> Philipp
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFH1C3dbtUV+xsoLpoRAhZrAKCMtmvWCf29fMd5no+YgU2rf42CLgCgvm7g
> RoW7QscppXcZQEupYpYUerE=
> =NXlj
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel 

Thread: Re: [sdcc-devel] Plan for sdcc 2.7.0 (Page 2)

The Small Device C Compiler (SDCC), targeting 8-bit architectures

sdcc-devel