Re: [gccsdk] LLVM

On 10/15/2012 04:00 PM, Martin Bazley 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? 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?
>

Having considered this in the past, EABI binaries (and let's assume
Linux ARM binaries for a concrete example), really assume a dynamic/
sparse memory arrangement for stack/heap handling. This is certainly
possible on RISC OS with probably some straightforward modifications,
but it does mean moving away from the 20(?) year old chunked stack
model, although you'd continue to support that for older code.
That might be a good thing, since chunked stacks have drawbacks too.

The bottom line is that you'd need RISC OS modifications to do this
at all, I think. But that might end up being less intrusive than say,
the 32-bit SCL stuff.

There might be alternate ways to do this, this is just my superficial
observation.





_______________________________________________
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