Re: [gccsdk] LLVM (was: Parsing wget output)

In message <48cf43df52.martin@blueyonder.co.uk>
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> The following bytes were arranged on 15 Oct 2012 by John Tytgat :
>
> > If we would adopt EABI as new target, then the gcc compiler option remains
> > open and would make most of our patches redundant which is always a pro,
> > the less custom changes we have, the better.
> >
> > The question is whether there is sufficent momentum from RISC OS developer
> > community to support this all.
>
> Is there anything physically preventing EABI programs from running on
> RISC OS as-is?

Aside, with EABI I'm referring to BSAPI, AAELF and AAPCS standards at
arm.com, there are some choices to be made if we're going to use this
for RISC OS.

I'm not sure if this is intrinsic part of EABI but e.g. on Linux they
took the opportunity to change the syscall (swi) calling convention
by passing the SWI number via a register instead of having it encoded
in the SWI instruction itself. For obvious reasons, this is not an
option for RISC OS and I don't think this is a showstopper either as
a compiler is not emitting SWI/SVC instruction on its own unless it
concerns very platform specific support like threads or cache
synchronisation, stuff we need to customize anyway for RISC OS.

> As in, does any part of the operating system or commonly
> used components make key assumptions about APCS-32 such as interrupts,
> callbacks, SWIs, etc.?

I don't think so (perhaps debuggers).

> Could, for example, UnixLib cope with different
> applications calling the same functions at the same time using both EABI
> and APCS-32?

No, the calling convention is subtle different for some cases that I think
it is impossible to deal with both calling convention at runtime with the
same binary.

But I don't think this would be of any advantage. For static built
binaries, this doesn't matter (either you go for full APCS-32, either for
full EABI, just like APCS-26 vs APCS-32), either the right flavour
of UnixLib gets loaded as shareable library.

> Are there any other modules apart from UnixLib which are
> privy to the internal organisation of the code?

I don't think so. Unless you mean SharedCLibrary. I.e. when gccsdk gcc
uses SharedCLibrary (-mlibscl) you need APCS-32 calling convention
(including FPA as floating point support).

> I guess since RISC OS is quite accommodating about hand-written
> assembler programs doing whatever they please it can't be that fussy.
> Just wondered if it was entirely a private matter for an isolated binary
> or if it would require support elsewhere, and hence how difficult it
> would be to abandon APCS-32 altogether.

I don't think this really needs support apart from a module, just like
we have today as SharedUnixLibrary and/or SOManager.

John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK