Re: [sdcc-devel] 8051 banking with different base address (and related proposal)

[Paul K. <co...@pa...>]

Hey,

Le mercredi 14 juin 2017 à 22:15 +0200, Maarten Brock a écrit :
> To start with, 4KiB is a range from 0x0000 to 0x0FFF. Your mentioned
> ranges are 16KiB.

Oopsie, you're totally right, my ranges are indeed 16 kiB.

> You need to attack this in two steps. First you must map the banks to:
> 0x0C000-0x0FFFF: bank 1
> 0x1C000-0x1FFFF: bank 1
> 0x2C000-0x2FFFF: bank 2
> 0x3C000-0x3FFFF: bank 3
> 
> This way they all have a correct linkable 16 bit address. The high byte
> you use to select the bank in the jump routine.
> 
> SDCC will output a hexfile with all banks at their linked address. To move
> them to the right place in the 128kiB storage you will have to
> post-process the hexfile. The srec-cat tool is a good choice for that.

I had not thought of that and it definitely looks easier than modifying the
linker. I suppose I could manage doing things this way.

Thanks for the suggestion!

Cheers,

Paul

> > I am working on a 8051-based platform where there is only 128 kiB storage
> > (the
> > bottom of which is automatically mapped to the usual 64 kiB code memory
> > size),
> > with 4 kiB segments that can be remapped to any 4 kiB-multiple offset in
> > storage.
> > 
> > There are actually two such segments (0-0x3fff and 0xc000-0xffff) and I'm
> > only
> > using the latter (to not have to duplicate the interrupt handlers and have
> > common rodata sections in the other one). Thankfully, banking support in
> > SDCC is
> > in a pretty good shape, so I was able to write bank switching asm routines
> > and
> > correctly assign each file to a given segment.
> > 
> > I am looking to only remap the top 4 kiB but would still like to make full
> > use
> > of the top 64 kiB I have left in storage. Currently, each bank must be
> > stored
> > with the same lower 64 kiB address, which makes my use case impossible. To
> > make
> > this more clear, it means that I can remap 0x1c000-0x1ffff to
> > 0xc000-0xffff but
> > I cannot remap e.g. 0x10000-0x13fff to 0xc000-0xffff. This is what I want
> > to do.
> > 
> > I have identified where the address gets truncated (relr3 calling adb_2b),
> > during symbols relocation. What I would like to propose is a command-line
> > parameter, similar to -b, that would specify the relocation base address
> > (where
> > the code will actually be mapped when executed). This would be stored in a
> > member of the area and areax structures associated with each segment and
> > would
> > be used in favor of their a_addr member when doing symbols relocation. Of
> > course, a fallback should fill that new member with the a_addr value when
> > the
> > command line argument is not provided so that this does not change current
> > behavior.
> > 
> > I would be quite interested in feedback about this idea and would like to
> > start
> > implementing this ASAP, so that my use case can be supported in future
> > release.
> > 
> > Cheers,
> > 
> > --
> > Paul Kocialkowski, developer of free digital technology and hardware
> > support
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/