#220 Allow >256 byte paged memory area

open
nobody
None
5
2007-09-20
2007-09-20
Julian Lamb
No

I happen to do most of my 8051 programming in assembly, so I've run across the 256 byte paged area limit many times with SDCC. In commercial compilers I've used, there is no limit to the sixe of a paged area. They only ensure that each relocatable paged segment does not cross a 0x00 boundary. During allocation, if a segment does cross a 0x00 boundary, then it merely pads the segment until it starts at the next 0x00 point. This ensures that you don't have to worry about DPH changing while you are accessing data in that particular segment.

I've attached a crude patch to as/mcs51/link/lkarea.c which allows for >256 byte paged area. I'm sure I'm missing tons of stuff in the patch, but it works with my projects so I thought I would pass it along. It simply checks if each paged segment crosses a 0x00 boundary, and moves it to the next 0x00 starting point if it does. Also, to make best use of the space, it checks to see if any following segments fit into any padding area it created. This causes some problems with the final size calculation for the segment, which I've fixed by changing the calculation at the end.

Cheers--

Discussion

  • Julian Lamb

    Julian Lamb - 2007-09-20

    patch for as/mcs51/link/lkarea.c

     
  • Maarten Brock

    Maarten Brock - 2007-09-20

    Logged In: YES
    user_id=888171
    Originator: NO

    For the compiler the paged area is where it uses @Ri instead of @DPTR. And it does not set P2 or _XPAGE before accessing the area except during initialization. That is why the paged area is limited to one page.

     
  • Julian Lamb

    Julian Lamb - 2007-09-20

    Logged In: YES
    user_id=1709675
    Originator: YES

    I see. I guess I don't use the C compiler much, so I didn't realize it was using PSEG for 8-bit XDATA accesses without setting the page. Scratch this request then. :)

    Cheers-

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks