Anthony, In the past I already worked on this a bit and I'm currently back at it to introduce a new memory model called --model-huge. But it doesn't pass regression tests yet.
Happy New Year, Maarten > refresh... > > I am still looking for a way to deal with a code base that I cannot > modify to insert __banked keyword on the functions. Maarten it seemed > like you were proposing a command line switch to add banked tag to all > functions. This could be further enhanced by only adding it to all > non-static (ie externally visible) functions. I would be glad to help > implement or test this functionality with some assistance. > > Please let me know how I can proceed... > > what would be the best place to begin digging into sdcc code to > implement this feature? > or > how can I best aid someone else in testing a new feature? > > > anthony* > > > Maarten Brock wrote: > > Hi Anthony, > > > > Currently all C-library code is compiled without any bankswitching > > directive which places the code in CSEG. The linker will put CSEG in the > > common bank (0x0000-0x7FFF) so there is no banking problem. > > > > Instead of preprocessing your source code I think what you want is a > > pragma or commandline switch to turn on and off banked functions. The > > switch should be on for both the implementation and the prototype of your > > functions. The switch probably needs to be off for the C-library. > > > > The downside is that all functions will become banked including the > > overhead. Judicious use of the banked keyword on some toplevel tasks which > > only use non-banked functions or functions in the same bank will greatly > > reduce this overhead. > > > > Maarten > > > > > >> Although I have bankswitching working as described in the sdcc manual, > >> I'm still stuck with a couple of issues. I'm wondering if anyone has > >> suggestions on how to work around these... > >> > >> * printf routine is linked into a non-home bank and is not marked as a > >> banked routine. Bad things happen when banked code calls printf. > >> Is there anyway to force printf into the first bank at linking time? > >> Would a banked wrapper function in the same bank as printf be a > >> reasonable work around? (the main limitation would be that all banked > >> code must be modified to call the wrapper instead of printf) > >> > >> * source code must be modified with __banked tag to move them into > >> non-default banks and keep them accessible. I'm working on porting an > >> open source operating system to an 8051 cpu. The OS already supports > >> numerous platforms. It will be difficult and undesirable to modify all > >> of the source code in a way that is only required for a single > >> platform. Sure it is possible to keep the code portable with > >> pre-processor macros, but the core developers will not be interested in > >> diluting their code base with non-standard, cpu/compiler specific flags. > >> > >> It would be really neat if the compiler could accept an additional > >> file that could specify on a per routine basis additional tags such as > >> banked, and the desired bank/area. hey i can dream right!? > >> > >> My only other recourse short of forking the OS code base is writing a > >> c re-compiler that can preprocess all the code and add in the required > >> tags. I have done something similar with http://codeworker.free.fr/ > >> before but this seems overkill. Is there some easier way? > >> > >> > >> Anthony* > >> > >> ------------------------------------------------------------------------------ > >> This SF.Net email is sponsored by the Verizon Developer Community > >> Take advantage of Verizon's best-in-class app development support > >> A streamlined, 14 day to market process makes app distribution fast and > >> easy > >> Join now and get one step closer to millions of Verizon customers > >> http://p.sf.net/sfu/verizon-dev2dev > >> _______________________________________________ > >> Sdcc-user mailing list > >> Sdcc-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > >> > >> > >> > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > Sdcc-user mailing list > > Sdcc-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > >
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: modelhuge.patch
Date: 29 Dec 2009, 10:33
Size: 2466 bytes.
Type: Unknown
modelhuge.patch
Description: Binary data
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
