Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!morten
From: morten@cs.qmw.ac.uk (Morten Ronseth)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C Suggestions
Keywords: THINK C, assembler
Message-ID: <2901@sequent.cs.qmw.ac.uk>
Date: 3 Oct 90 09:37:07 GMT
References: <61078@iuvax.cs.indiana.edu> <39560@shemp.CS.UCLA.EDU> <505@skye.cs.ed.ac.uk>
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 47

In article <505@skye.cs.ed.ac.uk> nick@lfcs.ed.ac.uk writes:
>|>>4)	Add a command for assembler output, like the command-K
>|>>	function for compile.  That way we can see what kind of code
>|>>	Think C is generating, so that we can decide if we need to
>|>>	optimize it, and so that we have something to begin optimizing
>|>>	with.
>|>
>|>Yes! Yes! Yes! Yes!
>|>This would be fantastic!
>
>I've never seen the need for assembler output from a compiler. What's
>so wonderful about it? I've been programming in C for years, off and on,
>and have never felt the need to see the compiler's excretions. This business
>of seeing the output and hand-optimising it seems to be a singularly
>pointless way of spending one's time, unless (i) speed is *absolutely*
>critical in some tight loop or other, and (ii) you can't get equivalent
>or better speed-ups by spending less time just working on the C code.

Here at QMW, we have our own version of the Smalltalk virtual
machine, called BrouHaHa. Now, some of the optimizations we use in
the making of it, depend on the availability of assembler output.
Sometimes, a compiler can be really stupid, have bugs or whatever,
and produce wrong/unsuitable code. In several places of our virtual
machine, we have to produce the *.s file and run a sed-script on it to
obtain the desired result. I assure you, these optimizations
*cannot* be made by just working on the C code, in-line assembley
or not (the way it is now, BrouHaHa is "impossible" to port to MacOS.
Not even MPW C will do the job, being what it is. No, we're waiting
for GCC to come along so we can start doing a port to MacOS...).
Also, I sometimes find it useful to have a look at the assembler
output to see just what the compiler is up to. Believe it or not, 
this can be a useful debugging tool.

>Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
>		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcsun!ukc!lfcs!nick
>~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
> "Now remember - and this is most important - you must think in Russian."

		Morten.
-- 
====================================================================
Morten Lerskau Ronseth             UUCP:   morten@qmw-cs.uucp
Dept. of Computer Science          JANET:  morten@uk.ac.qmw.cs 
Queen Mary and Westfield College   ARPA:   morten%qmw.cs@ucl-cs.arpa 
Mile End Road                      Easylink:  19019285 
London E1 4NS                      Tlf:       071 975 5220/31/47 
England.                           Dept. fax: 081 980 6533