page@ulowell.cs.ulowell.edu (Bob Page) (04/16/87)
tim@amdcad.UUCP (Tim Olson) wrote in article <16093@amdcad.AMD.COM>: >QUESTION FOR AMIGA CODE DEVELOPERS: What is the ratio of high-level >language programming to assembly-level programming that you are using >on your projects (i.e. how much do you actually see the CPU structure)? Hmmm. While I certainly don't speak for all coders, I know that many of the C programmers that are doing "commercial" type software (whether or not the program is for "sale") are using C with the knowledge of what the compiler is going to compile down to. Thus, sadly I guess, I code C differently when I'm using Lattice vs Manx, or when I'm using a 68000 vs a VAX. To squeeze performance, you have to really know the compiler and the host machine architecture. I've seen (not written!) this one line of C that was so hairy you'd feel bald. Fact is, it turned out to be one instruction on the 68K and VAX (although pcc wasn't smart enough to optimize it down to one instruction on the VAX, the Sun C compiler was). It was not intuitive at all, but it was FAST. For MOST applications and programmers, I doubt that the underlying machine and compiler matter at all. And C might well be the only language where people even think about it. Still, I'd love to see the new AMD chip in an Amiga. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
pes@ux63.bath.ac.uk (Paul Smee) (04/23/87)
I think the main problem with writing super-fast code is that a lot of programmers have lost their sense of perspective. Sure, for time-critical stuff (high-speed terminal emulators, flight simulators, ...) you gotta be efficient. And, for things which will be used a **lot** (either by you, or by lots of people) it can pay off. On the other hand, it's frequently nothing more than a waste of time. For example, I recently re-wrote a data packing algorithm on our mainframe, for one of our users. Took 2 or 3 days of my time to make it absolutely minimal. He likes it, because it saves him about 20 seconds of CPU time per run. He's the only one who uses the program, and he uses it about twice a week. So, in only another 60 years (more or less) it will have saved the time it took to produce it. Of course, we're replacing our mainframe (certainly incompatibly at the object level) in 12 months. So, totally counter-productive -- except for the entertainment value, cause I had lots of fun doing it. Purely from an efficiency standpoint, though, an awful lot of programs (I'd guess most) are best written in a quick-and-dirty style, and then you can use your time to get on with something else useful.
gary@eddie.MIT.EDU (Gary Samad) (04/27/87)
The question was: what percentage of code is C and what percentage is assembly language in commercial products? My product, which will be released in a few weeks, consists of about 40,000 lines of code, of which only two routines (ammounting to about 500 lines) are written in assembly language. As far as thinking about the underlying machine structure when writing code goes, about the only thing I worry about is how many register variables are actually used by the compiler. I've found that besides register vars and writing reasonable code to start with, not much is to be gained by looking at the compiler output... Gary