Why 2.95.4 ? (and libscl)
nick at dsvr.net
Thu Feb 7 06:17:08 PST 2002
Peter Naulls <peter at chocky.org> writes:
> Some of the things I'd like us to consider are:
> - Modules, relocatable code, DLLs and all the code generation
> requirements that go with them.
Tricky. I don't think this has been achieved on any ARM target yet.
> - Following the mainline ARM GCC development as closely as possible.
> There's lots of work being done there, and obviously there is plenty
> of stuff that isn't relevant. But (IME), the differences between
> generating code for RISC OS, and generating it for ARM Linux are
> very minor indeed. Plus there's the oppurtunity to pick up on
> the on the other compilers - Objective-C, Java and ADA come to mind.
I don't think this is feasible due to the speed and relative instability
of mainline GCC. We are better off picking a GCC snapshot and porting
that. Then updating several months later.
We really would need to reduce the patch differences between RISC OS
GCC and mainline GCC. To achive this, we really would need to use
`fp' based local variables rather than `sp' based ones.
> - This SP vs FP variable access. Nick, if you can collect your
> thoughts on this one, I'd be interested to hear why this change is
Simply because it reduces the ARM backend code changes required for
RISC OS down to a few lines rather than about 150Kb of diffs. This
is not necessarily my laziness, but I think that by sticking to sp-based
local variables, we will lose out in the long run.
I would like to get an initial port of GCC 3.1 working based on fp-based
variables then consider the issues that arise after.
More information about the gcc