|WANTED: One good retargettable compiler back end firstname.lastname@example.org (Kim Lux) (2005-12-08)|
|Re: WANTED: One good retargettable compiler back end email@example.com (Ian Lance Taylor) (2005-12-08)|
|Re: WANTED: One good retargettable compiler back end firstname.lastname@example.org (Uncle Noah) (2005-12-08)|
|Re: WANTED: One good retargettable compiler back end email@example.com (glen herrmannsfeldt) (2005-12-11)|
|Re: WANTED: One good retargettable compiler back end firstname.lastname@example.org (2005-12-29)|
|From:||glen herrmannsfeldt <email@example.com>|
|Date:||11 Dec 2005 19:58:04 -0500|
|Posted-Date:||11 Dec 2005 19:58:04 EST|
Ian Lance Taylor wrote:
(snip regarding gcc)
> Actually the biggest difficulty I've seen is that the tests in the
> testsuite tend to assume large memory space, 8-bit memory access,
> 32-bit ints, etc., so you wind up having to look at the tests
> individually to see which ones will never work on your processor, and
> which ones indicate actual problems.
I know some people recently working on a port to IBM S/370 (that is,
not XA/370 or ESA/390) have had problems getting it to run native with
ONLY about 8M bytes available. As a cross compiler it is fine.
It does seem that writing a compiler to run on small memory machines
is a lost art.
[GCC and other Gnu programs have always assumed that they have vast amounts
of address space available. The target of GCC may have a tiny memory, but
the host better not. On the other hand, the original PDP-11 Unix C
compiler ran in about 24K bytes, with two passes and generated pretty good
Return to the
Search the comp.compilers archives again.