From: Anthony A. <ant...@gm...> - 2009-12-22 17:52:24
|
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 customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |