[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] MiNT1.17 Changes
Hi,
On torstai 30 joulukuu 2010, Helmut Karlowski wrote:
> =?utf-8?q?Jean-Fran=C3=A7ois?= Lemaire wrote:
> > How about the alternatives, vbcc and ahcc, wich are both currently
> > maintain= ed?=20
>
> Some time ago I tried vbcc on a TT and it was awfull. With optimisation
> gcc is 20x faster, without the code is crap.
>
>> Can't they compile the kernel?
Somebody would at least need first either:
- write AHCC project files for kernel, or
- add AHCC support to the kernel Makefiles
(It has different compiler & linker options etc.)
Then one can start looking into how to get around C level differences
in GCC & AHCC. AHCC for example has only partial C99 support,
instead of inline assembly it uses its own intrinsics etc. GCC 2.95
compatibility fixes probably will help for former.
As an example of this kind of effort, EmuTOS was modified year ago to be
(more) compatible with AHCC and Henk added some extra features to AHCC for
this. Some of the changes that Henk did and Thomas integrated to EmuTOS are
listed & discussed in my 7th of January mail on emutos-devel mailing list
and its replies:
http://sourceforge.net/mailarchive/message.php?msg_id=24317306
(AHCC changes you can see from AHCC changelog entry around that time.)
I haven't looked into this (or to MiNT kernel sources in 14 past years),
but I would assume this to be more feasible for MiNT kernel than e.g. for
MiNTlib and GNU software relying extensively on GCC features.
> Ask Henk for AHCC, would be great if it could do it.
At least earlier when I've asked Henk about this kind of stuff, he said that
he wasn't particularly interested in GCC compatibility[1] and it's enough
for him to be able to bootstrap GEM (e.g. on ColdFire) by being able to
re-build:
- AHCC
- EmuTOS
- Teradesk
with AHCC.
[1] just PureC and C standards compatibility, when standards are sane
_and_ can be implemented with reasonable effort.
I.e. if somebody wants to make extra software compatible with AHCC,
they're welcome to it and if there are clear bugs in AHCC those may
eventually get fixed, but Henk (understandably) wasn't interested himself
in porting extra SW to compile with AHCC.
Henk, please correct me, if I got it wrong. :-)
Another thing to remember is that AHCC is relatively simple/straightforward
compiler. If the C-code it compiles is efficient as-is, the compilation
result might not be that much slower than GCC compiled code. However, AHCC
doesn't go to any great lenghts to optimize stupid code. Slow code will
remain slow code with AHCC although GCC would be able to optimize it a lot
(inlining static stuff, removing dead code, pre-calculating invariant
values, deducting more correct/faster types for variables etc).
- Eero