26/32-bit OSLib

[Kevin Bracey]

In message <14ec37964b.rick at ravine.kpo.org.nz>
          Rick Hudson <rhudson at paradise.net.nz> wrote:

> On 16 Nov you wrote:
> 
> > In message <a10726964b.rick at ravine.kpo.org.nz>
> >           Rick Hudson <rhudson at paradise.net.nz> wrote:
> > 
> >> Does this mean there is no 26/32 neutral version?
> > 
> > The 32 bit build is 26/32 bit neutral.
> > 
> > Because it is APCS-32 anything linked with it must also be APCS-32 and must
> > therefore use the new SharedCLibrary. For that reason we also maintain an
> > APCS-R build (the 26 bit version) for anybody that still needs to create
> > executables for people without the new SharedCLibrary.
> 
> Sorry - I don't think I thought things through properly before asking the
> question. As long as the code itself runs on any processor (ie the 32-bit
> version) then I guess it doesn't really matter whether its call standard is
> APCS-32 or APCS-R/32 because any code that has been compiled with a neutral
> compiler (that calls an OSLib function) won't care whether OSLib preserves
> flags or not.

Wait a mo - it's not generally possible to mix APCS-R and APCS-32 code, and
the linker will warn if you try to. That's why there are APCS-R and APCS-32
versions of OSLib. Hopefully everyone will be building APCS-32 soon, but
until then some people will need APCS-R versions (maybe they're linking with
APCS-R libraries).

> That then makes me wonder what is the interaction make makes the version of
> SharedCLibrary important? OSLib doesn't call it does it?!

It's complicated. The C library calls the program in a few places and the old
version absolutely requires flag preservation across calls, so wouldn't work
with APCS-32 code. Also the structure of the stubs has had to change
significantly to work on a 32-bit system (where you can't use B to branch to
the C library). You need a new C library to support those stubs.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/