f



Is this right?

Am I right in making these assumptions?

When an application is linked to the shared C library it
calls XSharedCLibrary_LibInitAPCS_32, and this fills
in the stubs (that initially look like lots of MOV PC,#0
instructions) with branches to entry points of code
inside the CLib module.

Branches must be to addresses within + or - 8Mb, there
being only 24 bitsworth of offset in the branch instruction.

Ergo, the CLib module must be stored within 8Mb of the area
in which applications run.

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
0
gavin4770 (200)
10/6/2006 12:41:22 PM
comp.sys.acorn.programmer 2499 articles. 0 followers. Post Follow

8 Replies
542 Views

Similar Articles

[PageSpeed] 24

On Fri, 06 Oct 2006 13:41:22 +0100, Gavin Wraith wrote:

> Am I right in making these assumptions?
> 
> When an application is linked to the shared C library it
> calls XSharedCLibrary_LibInitAPCS_32, and this fills
> in the stubs (that initially look like lots of MOV PC,#0
> instructions) with branches to entry points of code
> inside the CLib module.
> 
> Branches must be to addresses within + or - 8Mb, there
> being only 24 bitsworth of offset in the branch instruction.
> 
> Ergo, the CLib module must be stored within 8Mb of the area
> in which applications run.

Hmm.  Interesting question.  I always seem to recall them being branches,
but it can't be that simple for precisely the reasons you describe.

Are you sure they're branches, rather than say, a load of LDR PC,
someaddress, where someaddress is near the trampoline and is also filled
in by the Shared C Library?

(I don't have a RISC OS box handy to check.)

B.

0
nntp550 (4244)
10/6/2006 2:36:09 PM
Gavin Wraith wrote:
> Am I right in making these assumptions?
>
> When an application is linked to the shared C library it
> calls XSharedCLibrary_LibInitAPCS_32, and this fills
> in the stubs (that initially look like lots of MOV PC,#0
> instructions) with branches to entry points of code
> inside the CLib module.
>
> Branches must be to addresses within + or - 8Mb, there
> being only 24 bitsworth of offset in the branch instruction.

Instructions are always word aligned. The offset is effectively 26bit,
with the lower 2 bits obtained by left shifting the offset two places.


>
> Ergo, the CLib module must be stored within 8Mb of the area
> in which applications run.

The real restriction is plus/minus 32Mb.

(Which is only an issue with a 32bit-PC OS)

>
> --
> Gavin Wraith (gavin@wra1th.plus.com)
> Home page: http://www.wra1th.plus.com/

-- 
Matthew

0
10/6/2006 3:04:33 PM
In message <1160147073.381903.154100@h48g2000cwc.googlegroups.com>
          "Matthew Wightman" <matthew.wightman@gmail.com> wrote:

> Gavin Wraith wrote:
>> Am I right in making these assumptions?
>>
>> When an application is linked to the shared C library it
>> calls XSharedCLibrary_LibInitAPCS_32, and this fills
>> in the stubs (that initially look like lots of MOV PC,#0
>> instructions) with branches to entry points of code
>> inside the CLib module.
>>
>> Branches must be to addresses within + or - 8Mb, there
>> being only 24 bitsworth of offset in the branch instruction.
> 
> Instructions are always word aligned. The offset is effectively 26bit,
> with the lower 2 bits obtained by left shifting the offset two places.

Yes, this means that in 26-bit mode, ANY address can be reached with a 
branch from any other address because the program counter only has a 
26-bit range, too.

>> Ergo, the CLib module must be stored within 8Mb of the area
>> in which applications run.
> 
> The real restriction is plus/minus 32Mb.

It would be if branches were used, but branches are only used in 
26-bit mode. In RISC OS 5, the RMA is about 512MB away from 
application space, so branches are out of the question. Instead, as 
Rob suggested, the instruction LDR PC,xxx is used, which does not have 
any range restriction.

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
   ArtWorks 2 -- Designing stunning graphics has never been easier
spamtrap@mw-software.com      [replace "spamtrap" by "info" to reply]
0
spamtrap3075 (2307)
10/6/2006 3:40:58 PM
In message <e8b1a0714e.martin@bach.planiverse.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:



> It would be if branches were used, but branches are only used in 
> 26-bit mode. In RISC OS 5, the RMA is about 512MB away from 
> application space, so branches are out of the question. Instead, as 
> Rob suggested, the instruction LDR PC,xxx is used, which does not have 
> any range restriction.

Thanks, Rob, Matthew, Martin. That clears up two of my
misconceptions.

Another query: has anybody made any other shared libraries (in RISC OS,
of course) apart from the standard C library? Of course, lots of
applications use modules as a resource, but I am thinking of this
business of filling in an array of LDR PC,xxx instructions as a faster
alternative to SWI calls. Has anybody made a tool to take an AOF
file of relocatable code, with no external dependencies except to
the shared C library, and convert it to a shareable library module?

-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
0
gavin4770 (200)
10/6/2006 4:07:18 PM
In message <241ba3714e.wra1th@wra1th.plus.com>
          Gavin Wraith <gavin@wra1th.plus.com> wrote:

> Another query: has anybody made any other shared libraries (in RISC OS,
> of course) apart from the standard C library? Of course, lots of
> applications use modules as a resource, but I am thinking of this
> business of filling in an array of LDR PC,xxx instructions as a faster
> alternative to SWI calls.

It is difficult to come up with a good scenario when that would really 
be necessary. In most cases a SWI call is fast enough, most notably in 
the case when the called routine does some non-trivial amount of work. 
If you really need to call a specific library routine very frequently, 
you can add a SWI to the module that returns the address of the 
routine. Then, the caller can call it directly without the SWI call 
overhead.

> Has anybody made a tool to take an AOF file of relocatable code, with
> no external dependencies except to the shared C library, and convert
> it to a shareable library module?

Not that I know of. If you want fully transparent shared libraries 
with fast function calls, I suggest waiting for the ELF-based GCC 
toolchain that is under development at the moment. It will do exactly 
what you want out of the box.

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
   ArtWorks 2 -- Designing stunning graphics has never been easier
spamtrap@mw-software.com      [replace "spamtrap" by "info" to reply]
0
spamtrap3075 (2307)
10/6/2006 6:25:07 PM
On 6 Oct 2006 Martin Wuerthner <spamtrap@mw-software.com> wrote:
> In message <241ba3714e.wra1th@wra1th.plus.com>
>           Gavin Wraith <gavin@wra1th.plus.com> wrote:
>> In message <e8b1a0714e.martin@bach.planiverse.com>
>>           Martin Wuerthner <spamtrap@mw-software.com> wrote:
>> > It would be if branches were used, but branches are only used in 
>> > 26-bit mode. In RISC OS 5, the RMA is about 512MB away from 
>> > application space, so branches are out of the question. Instead, as 
>> > Rob suggested, the instruction LDR PC,xxx is used, which does not have 
>> > any range restriction.

It should be noted that the 32bit compatible stubs needs to contain
8 bytes for each entry point rather than 4, to enable it to be filled with
both the LDR PC,[PC,offset] instruction, and the actual routine address
address which that instruction loads.
 
> > Another query: has anybody made any other shared libraries (in RISC OS,
> > of course) apart from the standard C library? Of course, lots of
> > applications use modules as a resource, but I am thinking of this
> > business of filling in an array of LDR PC,xxx instructions as a faster
> > alternative to SWI calls.
> 
> It is difficult to come up with a good scenario when that would really 
> be necessary. In most cases a SWI call is fast enough, most notably in 
> the case when the called routine does some non-trivial amount of work. 

The main advantage is that the code in the shared library then runs in user
mode, rather than SVC mode making any crashes less likely to be fatal. The
library code could also use facilities of the main programs runtime such as
memory allocation for the stack and heap, rather than the rather limited
stack space which is afforded to C code running in SVC mode, and heap taken
from the RMA.

> If you really need to call a specific library routine very frequently, 
> you can add a SWI to the module that returns the address of the 
> routine. Then, the caller can call it directly without the SWI call 
> overhead.

This is done for a few critical assembler routines, but I don't know of much
APCS compatible code which can be called directly by C/C++.
 
> > Has anybody made a tool to take an AOF file of relocatable code, with
> > no external dependencies except to the shared C library, and convert
> > it to a shareable library module?

Not that I know of. The only really worth while candidates would be something
like UnixLib for the same reason as SCL is. The same sort of stub mechanism
could have been copied and used there, but it probably wasn't consider worth
the effort at the time.
 
> Not that I know of. If you want fully transparent shared libraries 
> with fast function calls, I suggest waiting for the ELF-based GCC 
> toolchain that is under development at the moment. It will do exactly 
> what you want out of the box.

I've only used the recently released version a little, but it seems to work
well.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
0
news5843 (7461)
10/6/2006 7:08:44 PM
In message <a2b7b3714e.druck@druck.freeuk.net>
          druck <news@druck.freeuk.com> wrote:


> It should be noted that the 32bit compatible stubs needs to contain
> 8 bytes for each entry point rather than 4, to enable it to be filled
> with both the LDR PC,[PC,offset] instruction, and the actual routine
> address which that instruction loads.

Thanks. I had worked that one out :).
  

> > It is difficult to come up with a good scenario when that would
> > really be necessary. In most cases a SWI call is fast enough,
> > most notably in the case when the called routine does some
> > non-trivial amount of work. 
> 
> The main advantage is that the code in the shared library then runs
> in user mode, rather than SVC mode making any crashes less likely to
> be fatal. The library code could also use facilities of the main
> programs runtime such as memory allocation for the stack and heap,
> rather than the rather limited stack space which is afforded to C
> code running in SVC mode, and heap taken from the RMA.

The use I have in mind is the Lua core library and its standard
auxiliary libraries. The idea of Lua is to link it in to other
applications. For example, I did this with PDFLib to produce a
way of scripting PDF files. A previous version of RiscLua I implemented
as a relocatable module, but I reverted to making it an application when
I found problems with error handling in the module version. The Lua
core is very robust for error handling, as embedded software has to be.
So I would keep the outer interpreter of RiscLua, and the libraries that
provide SWI calling, as part of an application, with the safe stuff
provided as a shareable library. My Weave website construction
application uses Lua, so, at least for me, it makes sense to have the
Lua core as a shareable resource.

> > Not that I know of. If you want fully transparent shared libraries 
> > with fast function calls, I suggest waiting for the ELF-based GCC 
> > toolchain that is under development at the moment. It will do
> > exactly what you want out of the box.
> 
> I've only used the recently released version a little, but it seems
> to work well.

I must knuckle down to experiment with it. Most Lua addons, and in fact
the Lua package library, assume that you have dynamic linking.
 
-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
0
gavin4770 (200)
10/6/2006 9:19:55 PM
On Fri, 06 Oct 2006 22:19:55 +0100, Gavin Wraith wrote:

> I must knuckle down to experiment with it. Most Lua addons, and in fact
> the Lua package library, assume that you have dynamic linking.

Perhaps time to investigate rink?  It's not an implementation of shared
libraries, but it is dynamic linking.  It may solve your problem, but I've
never looked at it closely.  It might be possible to adapt Lua's shared
object loading to use it.  Hey, if it can be adapted to work with Mac OS
X's insane SO system, it can be adapted to use any :)

B.
0
nntp550 (4244)
10/6/2006 10:56:47 PM
Reply: