Still wondering about the feasability of marking all non-static functions as banked. Any suggestions how I could go about this? Is it something I could easily add into sdcc?
On Tue, Dec 22, 2009 at 9:51 AM, Anthony Asterisk < anthony.aster...@gmail.com> wrote: > Since the codebase is large and open any externally visible method could > be called from any bank. I think I would need a flag that forces these > functions to be treated as banked. I don't think there is a command line > flag like this. A pragma wouldn't work since it would require changing > numerous files that are nonspecific to the 8051 port. > > If sdcc can provide some way to make all functions banked (ie accessed via > trampoline) then my work become feasible. The overhead is unfortunate but > cannot be avoided. How difficult would it be to add a command line switch > to mark all methods as banked? > > > 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 > customershttp://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Sdcc-user mailing > listsdcc-u...@lists.sourceforge.nethttps://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 > customershttp://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Sdcc-user mailing > listsdcc-u...@lists.sourceforge.nethttps://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
