kortink@utrcu1.UUCP (Kortink John) (02/26/91)
To: hp4nl!svin02!wsinfo11!rcpieter Subject: Re: C versus ARM take 2 Newsgroups: comp.sys.acorn In-Reply-To: <1786@svin02.info.win.tue.nl> References: <807@utrcu1.UUCP> Organization: Utwente, Enschede Cc: Bcc: In article <1786@svin02.info.win.tue.nl> Tiggr writes: >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. I'm sorry, but why can't you just say 'you're right' instead of repeating the reason why the problem occurs ? > >>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'). > Then I should tell you that we're talking about no specific language. We're talking about a parser-generator, which, in a later stadium, should be used to generate whole compilers. I am not implementing the peephole optimizer, that's done by another person. I have to generate RTLs from the APTs, which in turn are defined by a context-free grammar. >>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. That will be 1 out of a 1000, and it will be compiler-specific, hence useless. > >>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 I know that. Machinecode is also harder to maintain, and, as we all know, 80% of software cost = maintenance. We could go on forever, but it's all beside the speed(C)/speed(ARM)=x/1 issue. John Kortink ----------------------------------------------------------------------------- Student of Informatics at the University of Twente, The Netherlands MAIL : kortink@utrcu1.uucp DISCLAIMER : you know .... "If language were liquid it would be rushing in Instead here we are Suzanne Vega (Solitude standing) in a silence more eloquent than any word could ever be" ------------------------------------------------------------------------------