Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!svin02!wsinfo11!rcpieter
From: rcpieter@wsinfo11.info.win.tue.nl (Tiggr)
Newsgroups: comp.sys.acorn
Subject: Re: C versus ARM take 2
Message-ID: <1786@svin02.info.win.tue.nl>
Date: 23 Feb 91 13:01:00 GMT
References: <807@utrcu1.UUCP>
Sender: news@svin02.info.win.tue.nl
Reply-To: rcpieter@info.win.tue.nl
Lines: 37

kortink@utrcu1.UUCP (Kortink John) writes:

>The point I was trying to make was that it is NOT OPTIONAL junk : you're
>stuck with the other bulk if you want a few bits out of a package. If the
>compiler or linker can filter it : fine ! Acorn's doesn't do it (yet), and
>that's the one we have to work with.

Including a library because you use printf causes the grief.  The
printf function is part of and uses stdio, and stdio simply is a lot of
code.  Even a `smart' linker (I never knew the Acorn one wasn't) could
not solve this problem.  But then again, of a non trivial program, most
code will be object code, not library code.

>My graduation project is all about this actually (well, sideways). The idea
>is to produce 'dumb' code from something called an abstract program tree,
>called register transfer code, and optimize this using a peephole optimizer.

Why bother?  GNU CC already does this and a lot of other optimisations
(GCC uses the register transfer language as the intermediate `code').

>Point d) is where things get interesting, because it is there that you
>realize that it is practically impossible to optimize triples or quadruples
>or, generally, n-tuples of instructions, because it requires too much of
>that something called 'insight'.

That depends on how the RTL code was generated.  If it was generated by
a compiler front-end, certain language constructs will always produce
the same RTL code, which is easy to match and optimise by simple peepholing.

>True, that is one of the true virtues of *any* high level programming
>language. But that is beside the point. We were discussing speed/size issues.

The speed of program development is of much higher economical value
than the speed of the resulting code (I didn't say thats! It must have
been my oppressed alter ego!).

Tiggr