With GCCSDK GCC 4.1.1 Release 2 now being out of the door, I would like
to propose some development ideas and would appreciate some feedback.
For all clearness, this is what I can see myself doing for the coming
months/year(s ?) but not a promise it will actually be done. If other
people want to help out, of course feel free to join ;-)
First of all, as some of these following ideas can be quite disruptive,
I've created a stable gccsdk/branches/release_4_1_1 branch where we can
do all assumed safe bug fixing and this could possible be used to spin
off a GCC 4.1.1 Release 3 from it.
1. Some time I've investigated to upgrade binutils 2.17 we're currently
using, to 2.19 (atm 2.20 is the latest release) while sticking to
the stable GCC 4.1.1. Frankly this turned out to be a nightmare as
the latest binutils and gcc releases have migrated to autotools 2.64
and having to use in the same tree autotools 2.64 (for binutils
2.19/2.20) and autotools 2.59 (for gcc 4.1.1) is just asking for
trouble.
Hence, I've experimented to build binutils and gcc separately instead
of doing this in one tree and that works out fine (see svn
gccsdk/branches/joty/binutils-gcc-separation). This allows us to
have different autotools versions to be used and migrate binutils
and gcc independently from each other.
This change is a also using a Makefile instead of the build-it script
which allows more easily to continue (or re-do a part of) the total
build.
Actually I plan to merge this to trunk very soon.
2. Upgrade gcc 4.1.1 to something more recent. I did some experiments
with 4.4.0 and got reasonably far but it is too soon to know for sure
if this is going to work and be stable.
BTW, that's another reason to have binutils and gcc built separately
so that the binutils upgrade is not blocked by the gcc one.
3. I'm wondering if it wouldn't be worthwhile to have UnixLib configurable
for AEBI, i.e. basically no longer use stack chunks as mandated by
APCS-32.
It would free more registers for general use, have less prologue
overhead and we can probably more easily fallback on existing code
for shared libraries, thread support, debugging. Note the R9/SWI
calling convention is not something we can change of course.
Looks worthwhile to investigate and experiment with and could help
with trying out point 5 (see below).
Note I don't want to remove APCS-32 capability of UnixLib for the time
being.
4. Merge SCL stubs (libscl) and UnixLib : not really convinced yet this
would be an overall win but again worthwhile to investigate.
Pro:
- The reasoning is that currently libscl is missing out network/socket
support which is a pity as we can't build network related modules
(I don't think libscl has any advantages on UnixLib for normal
applications, binary footprint size aside).
- We could solve this particular network issue by migrating the
relevant bits from UnixLib to libscl but it could very well be that
we get nearly freebies as well by doing the libscl & UnixLib
merge : pthread support (perhaps), C++ (because missing runtime
routines are available as UnixLib runtime routines).
- It would eliminate several nasty hacks in our gcc tree to have
two runtime libraries which are enabled/disabled depending on the
multilib configuration we're building.
The basic idea is that we still have this one unified runtime library
between SCL and UnixLib mode based on the presence/absence of
-mlibscl option in the current multilib configuration.
This would also help out with point 5.
Contra:
- It risks to complicate the code base.
5. Since several of years there is a new kid around the block in 'free'
compiler land : LLVM http://www.llvm.org/. Basically it is a compile
infrastructure/JIT/code transformer/code analyser/etc of which one of
its usecases is just compile C/C++ with apparently respectful or even
impressive results. The C/C++ frontend is still a bit immature and
not 100% ready for cross-compile purposes but I've already been playing
a bit with it (gccsdk/branches/joty/llvm) to get a better understanding
what this could mean as RISC OS compiler.
So far, I'm well impressed as well and I think we should further followup
on this. Hence, also the reason to have point 3 so that we don't have
to initially go for APCS-32 support (if libscl support is wanted for
llvm, APCS-32 support is required of course).
I won't rule out that it might be more interesting on the long run to
invest in LLVM on RISC OS and forget about upgrading GCC to a later
version (point 2 above).
Looking forward to some feedback, and perhaps there are some other ideas
which can be put on the table as well ?
John.
--
John Tytgat, in his comfy chair at home BASS
[email protected] ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list [email protected]
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
