Now I have 2 skeptic/conservative opinions from sdcc developers and 2
optimistic replays from sdcc users.
I would like to have more opinions from sdcc users, so don't hesitate to
send a mail to sdcc-user or sdcc-devel mailing list.
In my previous post I asked sdcc users to help us (sdcc developers) in
some tasks, mainly in:
* change sdcc libraries license to GPL+LE:
collect the info and make a list of sdcc library files for which
the license can be changed, based on the agreement from authors
* documentation upgrade / review / reorganization
Anybody willing to take the challenge?
Sébastien Lorquet wrote:
> Agree too, for the same reasons :)
> On Thu, Jan 14, 2010 at 11:12 PM, steven.borley
> <steven.borley@... <mailto:steven.borley@...>> wrote:
> As a SDCC user I'd have no problem with the changes you propose.
> As for the deprecation of the keywords I long ago switch to using
> only the version that begin with the double underscore.
> One consequence of this would perhaps be to make porting code
> easier. Form experience I often find 'data' is used as a variable
> name, which currently causes some very odd error messages to an
> unsuspecting user.
> On 14 Jan 2010, at 06:54, Borut Razem wrote:
> > Hello Jesus,
> > here is the complete list of deprecated keywords:
> > non-compliant | compliant
> > keywords | keywords
> > ===============+=============
> > at | __at
> > bit | __bit
> > code | __code
> > critical | __critical
> > data | __data
> > far | __far
> > eeprom | __eeprom
> > fixed16x16 | __fixed16x16
> > flash | __flash
> > idata | __idata
> > interrupt | __interrupt
> > nonbanked | __nonbanked
> > banked | __banked
> > near | __near
> > pdata | __pdata
> > reentrant | __reentrant
> > shadowregs | __shadowregs
> > sfr | __sfr
> > sfr16 | __sfr16
> > sfr32 | __sfr32
> > sbit | __sbit
> > sram | __sram
> > using | __using
> > _naked | __naked
> > xdata | __xdata
> > _overlay | __overlay
> >> I believe this will create a whole bunch of compatibility issues.
> > It will produce a bunch of warnings if the code use
> non-compliant keywords.
> > The code will still compile correctly. And if somebody really
> don't want
> > to see the wraninings, he can use "#pragma disable_warning 197"
> in the
> > source file or "--disable-warning 197" command line option.
> > I actually already implemented this functionality and it was
> > just introduce the error message in SDCCerr.[ch] and change the
> > TKEYWORDSDCC macro in SDCC.lex, so it can be easily reverted if
> > are too many complains from sdcc users.
> > The harder work was correcting the regression tests, which used
> > non-compliant keywords a lot.
> > Best regards,
> > Borut
> > Jesus Calvino-Fraga wrote:
> >> Hi Borut,
> >> Can you explain why sdcc specific keywords need to be
> deprecated? I
> >> believe this will create a whole bunch of compatibility issues.
> >> Jesus
> >> At 11:31 AM 13/01/2010, you wrote:
> >>> Hello sdcc users and developers,
> >>> here is a list of tasks which by my opinion are candidates for
> the sdcc
> >>> 3.0 release:
> >>> * sdas merge with asxxxx 5.0
> >>> * change sdcc libraries license to GPL+LE
> >>> * review and merge "SDCC inline support and fixes"
> enhancements by
> >>> Pavel Pisa
> >>> see
> >>> * review and merge support for cs08 target by Gary Osborn
> >>> * deprecate warnings for sdcc specific keywords, not
> preceded with
> >>> two underlines (data, code, idata, xdata, ...) and
> announce in the
> >>> documentation that they will be removed in the future
> >>> * remove unsupported and broken targets xa51, avr
> >>> * review & merge patches in the bug tracker
> >>> * bug fixing
> >>> * ...
> >>> The list is quite long and you probably have additional
> >>> I propose to make a list of candidates on sdcc wiki,
> prioritize them and
> >>> find the persons which will work on them. There are many tasks
> that can
> >>> be done by non "core" sdcc developers: change sdcc libraries
> >>> changes, review and reorganization of the documentation, ...
> >>> So if there is anybody willing to help us, let us know!
> >>> Borut