Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!PAVEPAWS.BERKELEY.EDU!dillon
From: dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: C Philosophy
Message-ID: <8606210754.AA01488@pavepaws>
Date: Sat, 21-Jun-86 03:54:31 EDT
Article-I.D.: pavepaws.8606210754.AA01488
Posted: Sat Jun 21 03:54:31 1986
Date-Received: Sun, 22-Jun-86 07:07:17 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 81

(I absolutely refuse to include huge amounts of old messages.  this is flame
in a way, but I think it's better classified as 'opinion wars')


this is in responce to Jeff Gortatowsky 's message:

>Jeff Gortatowsky       {allegra,seismo}!rochester!kodak!elmgate!jdg
>
>Wrong.  Sorry but this is not the case.  The 68000 inside your Amiga is
>a 16 bit processor that just happens to have 32 bit registers and a 32
>bit register-to-register data path.  I call your attention to Tables
>starting on page 187 of the MC68000 Programmer's Reference Manual, 4th edition
>(C) 1984 Motorola Inc.  These tables clearly show that almost all
>instuctions pay a penalty for using a long.  ....

Not Wrong, Sorry.  My opinion.  Refering to the same page on the manual,
I would like to point out that register addressing modes take no longer
using 32 bits than 16 bits.  If you take into account that most speed-daemon
hacker-programmers use register declarations for variables in tight loops,
your only looking at an extra fetch every once in a while rather than every
other instruction.  most of the standard optimization techniques outway
any trivial amount of time saved by that extra fetch, all we really need is
a good compiler.  Of course the 16-bit compiler is going to be generally
faster, but if you look closely, it really isn't *all* that much faster.
Try doing timing runs on some of your sources (e.g. programs you have
written which were NOT explicity created for the purpose of speed testing).
Manx 32 against Manx 16 is probably as good as you'll get, though Manx
was really written to be a 16 bit compiler.

I've seen the code generated by the lattice compiler too... it's all Lattice's
fault.  Though they do seem to do some sub-expression elimination, but they 
definately do not have a peephole optimizer on the tail end.

>Then use longs in the first place and be done with it!  Again choose the
>right data type for the job at hand.  You saved a couple of micro seconds
>by not having to cast these 16 bit ints to longs and loss SECONDS (or much
>much more) thoughout the rest of the program by forcing the poor CPU to
>deal with an extra bus cycles on every data fetch.  Penny wise, pound
>foolish.

	tut tut, don't exaggerate.  Using longs in the first place 
requires you to extern your functions (16 bit compiler) in the first place 
also, so you can still wind up with a lot of junk.  I'm not saying declaring
everything 'long in the first place' is bad on a 16 bit compiler, just that
what you've said doesn't really reduce the amount of extra crap you have 
to declare at the beginning.  You still have to specify 'L' after all 
your integer constants.

>Of course there IS no better way to speed code along than to use the right
>algorithm in the first place.  That's where the REAL time will be gained or
>lost.   But to ignore the target machines CPU limitations will still cost
>you in the final result.  It depends on your feelings of 'when is fast,
>fast enough?' .  Me, I'm never satisfied.  Not till I know that given my
>own 'brain' limitations, and the compiler's code generating limitations
>(after all, I don't want to code it all in assembler), I've done the best I
>can.  And that to *ME* means using 16 bit shorts were 16 bit shorts are all
>that's needed.  At least until someone comes up with a reasonably priced
>68020 board/machine with 32 bit memory.

Agreed, to a point.  You are suggesting that the 68000 has limitations when
using 32 bit int's... that is completely incorrect in my view.  You should
consider the fact that all addresses must be handled as 32 bits and not
16 (no crap about .W addressing modes, please.)  Indrection through 32 bit
addresses, indexing through 32 bit registers... all these things point
to the fact that the 68000 handles 32-bit integers just as easily as
16-bit integers.

Assembly is fine.... for the 68000.  However, I personally find assembly
rather difficult to debug (almost as bad as basic), and drawn out.  It's
definately the way to go on a small computer for immensley
important routines, but I try to stay away from it.  Also, for you
speed daemons out there, I would like to point at that shaving 10 uS
from a tight loop with a library call in the middle is generally useless.

On algorithms, I agree wholeheartedly.  The program which writes to the
screen a character at a time is going to be an order of magnitude slower
than the program which writes to the screen in large(er) chunks, no matter
what.


					-Matt