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

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? 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.? Could, for example, UnixLib cope with different
applications calling the same functions at the same time using both EABI
and APCS-32? Are there any other modules apart from UnixLib which are
privy to the internal organisation of the code?

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.

--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================

_______________________________________________
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