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.asterisk@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 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