Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!think!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Assembly for graphics
Message-ID: <8803271926.AA21066@cory.Berkeley.EDU>
Date: 27 Mar 88 19:26:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 59

:In article <2734@crash.cts.com> steelie@pro-charlotte.cts.com (Jim Howard) writes:
:>
:>In most cases assembly will produce MUCH smaller executables, and if the
:>programmer is good enough, MUCH faster executables too. 
:> 

	With assembly you do get smaller executables, but I can guarentee
you that writing large projects in assembly takes a hellofalot longer 
than writing large projects in C, and I for one do not have the time.
There is a saying that 99% of processing time is spent in 1% of the
program.  If I *need* to go fast, I'll write that 1% in assembly and do
the rest in C.  

	In the case of most graphics routines, it really doesn't matter
when you are using the blitter because it works asynchronously!  For
instance, I can call BltClear() for a 320x200x4 bitmap 70 times a second. 
If I now put a delay loop of 98800 clocks after each BltClear() call, how
many times a second can I go through the loop?  The answer is: 70...
because the BltClear() is done by the blitter asynchronously, I have time
to do 98800 blocks worth of processing after each call.  
	
	A really good programmer will make use of this effect and
properly intermix calculations and non-blitter operations with blitter
operations.  So for the good programmer, it doesn't usually matter whether
it is done in C or assembly.

:
:Ok, now LISTEN this time.
:
:"If the programmer knows their compiler, knows their machine, and knows what
:they are doing, the speed penalty for using C is very small".
:
:Ask Leo about plotting pixels.

	Exactly.  And not only between assembly and C.  Many people claim
that using 16-bit integers makes for smaller and faster code.  This isn't
true at all.  I use 32-bit integers, but I hardly use 'int's... in fact,
I declare most of my variables 'short', and my code is just as fast and
just as compact as if I had used 16-bit integers.  Why do I use 32-bit
integers if I hardly ever use 'int'????  Simple:  When I have complex
expressions I don't want to have to think about intermediate results
overflowing a poor short.  If, on the otherhand, I *want* to cut it off,
I simply cast the elements to short and let the compiler optimize it to 
a single muls or mulu or whatever.  That is, I only need to worry about
exceptional situations.  Prototyping does not fix the problem.

	The only major problem prototyping fixes is to automatically cast
arguments to functions to the proper size and provide better error
checking.  Needless to say, I've been avoiding that problem for years by
using 32 bit ints.  My code is more *readable* without all those L suffixes
and (long)casts.  I don't give a damn about it being inherently portable.
(And as far as portability goes, you get into other problems whether you
are using 16 bit ints, 32 bit ints, 36 bit ints, or whatever .... ).

	If the programmer is good enough, he can produce C executables
that are comparable in size and speed to equivalent assembly executables,
and produce them in a quarter of the time.

						-Matt