#220 Allow >256 byte paged memory area
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--
patch for as/mcs51/link/lkarea.c
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.
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-
Logged In: YES
user_id=589052
Originator: NO
while the paged area (in the sense of pdata) is limited to 256 byte,
it still would make sense to have other data 256 byte aligned:
https://sourceforge.net/tracker/index.php?func=detail&aid=1017497&group_id=599&atid=350599
Greetings,
Frieder