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
