Experimental GCC supporting dynamic linking and shared libraries

John-Mark Bell jmb202 at ecs.soton.ac.uk
Fri Nov 25 13:00:45 PST 2005

On Fri, 25 Nov 2005, Lee Noar wrote:

> In article
> <Pine.LNX.4.62L.0511230013270.31989 at tarrant.ecs.soton.ac.uk>,
>   John-Mark Bell <jmb202 at ecs.soton.ac.uk> wrote:
>> The problem with storing executable code in a DA on 26bit
>> machines is that DAs may well end up being located above the
>> 64MB addressable boundary. I suppose a potential work-around
>> for this kind of thing could be to create the DA early on
>> (say, as part of the boot sequence) and hope that the OS
>> allocates one located below the 64MB boundary.
> Claiming a DA early during boot has crossed my mind, but what
> effect would it have on the RMA's position?

It shouldn't have any effect at all.

The RMA is based at &2100000 on all systems running non-32bit variants of 
RISC OS. (The memory map is entirely different on RO5 and I've no idea 
about Adjust32. Either way, it doesn't matter). It extends upwards a 
number of MB (11 on 3.5 < RO < 4, 15 on 4.xx).

On RO versions from 3.5 to 3.7, there are two address ranges allocated for 
dynamic areas:

&04000000 -> &7FFFFFFF and &A0000000 -> &FFFFFFFF

On RO4, there are three address ranges allocated for dynamic areas:

&04000000 -> &07FFFFFF, &08800000 -> &7FFFFFFF and &A0000000 -> &FF7FFFFF

All of these ranges lie above the 64MB addressable boundary (&04000000) so 
cannot contain code on 26bit machines. Thus my suggestion above is 
rubbish; I'd always assumed that at least part of the address space 
allocated to DAs lay below the 64MB boundary; PRM5a and the Ursula 
kernel document clearly state otherwise, however.

> On my machine (40MB + 2MB), the RMA is limited to about 15MB and starts 
> at &02100000. Is this limit imposed by the total amount of memory
> in the machine or the 26bit boundary?

Neither; it's hard-coded at ROM build time. The RMA is guaranteed to lie 
wholly below the 64MB boundary on 26bit OS variants, however.


More information about the gcc mailing list