On 03/08/2021 12:06, Theo Markettos wrote:
> On Mon, Aug 02, 2021 at 08:04:45PM +0100, Lee Noar wrote:
>> Unfortunately, GCC 10 does not support module generation as yet which
>> is why GCC 4 is still our main compiler.
>> The problem is that libscl which is the interface to the SharedCLibrary
>> and what modules are linked against needs to be built as hard-float+FPA,
>> however, FPA code generation was removed from GCC some years ago and is
>> no longer supported. Really, what we need is a SharedCLibrary that
>> supports VFP. Obviously, being able to build C modules is important to
>> RISC OS and until GCC 10 can do that, we can't really have it as our
>> main compiler.
>
> I did wonder whether it would be feasible to add another ABI 'personality'
> to SharedCLibrary - APCS_32_VFP or something -
Yes, that was the kind of thing I was thinking about, a new
initialisation SWI that targets VFP to compliment the existing ones
(off the top of my head I think APCS-R and APCS-32).
> so I took a look. Yikes:
> https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/blob/master/s/cxsupport
> There's quite a lot of FPA assembler lurking in there, with hand coded
> assembler for doing math lib functions and in other places. Reimplementing
> that for VFP (even in C) and getting it right would not be much fun.
I wonder if there are BSD licensed, tried and tested versions that could
be adopted rather than writing them from scratch.
> I did wonder how much usefulness there is in the SharedCLibrary concept
> nowadays. It's primarily designed for reducing the size of ROM modules, but
> ISTM it doesn't actually do a whole lot as far as the user is concerned
> (only basic ANSI C library functions plus bits like _kernel_swi), and its
> interfacing with the system is relatively slim (memory management, file I/O,
> stdin/out).
>
> So I was wondering whether it would be feasible to instead use a third party
> tiny libc like newlib. That has all the C stuff already implemented
> (including optimised versions for ARM), and only needs the backend plumbing
> to be implemented:
> https://interrupt.memfault.com/blog/boostrapping-libc-with-newlib
> https://sourceware.org/newlib/libc.html#Syscalls
>
> Of course it's not going to be as small as SharedCLibrary, but
> is it would be thread safe, portable and easier to maintain.
> It wouldn't help building ROM modules with GCC though.
It's a bit of a conundrum!
Lee.
_______________________________________________
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
No comments:
Post a Comment