steelie@pro-charlotte.cts.com (Jim Howard) (03/26/88)
>From: info-amiga shimoda@rmi.UUCP (Markus Schmidt) >Hi! >I hate assembler too & if you really do C right you don't need >assembler too often. >Dunno if someone has tried Leo Schwab's NEETO.ASM. It was pure >assembly and had 340 Bytes. I tried to do the same in C and did >it with 348 Bytes. >Or I have written a filebrowser that \is >*entirely* "C" and scrolls nearly as fast as BLITZ. If you say >Assemby is 100% (code and speed) good "C" can be 120% (20% >slower and bigger) and 50% delvelopmenttime. >|._,| Cu > - - Markus >==O== (shimoda@rmi.UUCP) > `-' Never trust a smiling cat! 'C' produced similar sized code only in NEETO.as because it was an extremly basic program- and had no reason to use any speedy routines. If you think C is just as good as assembly, try doing a few _ScrollRaster's in C, and then start up a few sprites. Then for fun just put a dual playfield in there. Pretty slow eh? In most cases assembly will produce MUCH smaller executables, and if the programmer is good enough, MUCH faster executables too. *BUT* I admit writing in assembler is enough to give anyone a headache, and for most applications, C will cut development time greatly. But if you are doing heavy graphics routines-or just IO routines that have to be blazing fast, assembly is the way to go. "The crash of the whole solar and stellar systems could only kill you once." UUCP: ....!crash!pro-charlotte!steelie INET: steelie@pro-charlotte.cts.com INET: crash!pro-charlotte!steelie@nosc.mil
richard@gryphon.CTS.COM (Richard Sexton) (03/27/88)
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. > 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. -- ..who come from long lines of soldiers, | richard@gryphon.CTS.COM whose duty was fulfilled, | ihnp4!scgvaxd!cadovax!gryphon!richard in the words of the warriors will, | rutgers!marque!gryphon!richard and protocol. | codas!ddsw1!gryphon!richard
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/28/88)
: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.
-Mattsdean1@uvicctr.UUCP (Steven A. Dean) (03/31/88)
In article <3013@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes: >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". >[...] ^^^^^^^^^^^^ ------------------------------------------------------||| Yes! BUT! Sometimes very small isn't good enough! Besides, if you write a lot in assembly, you can produce code that's smaller (almost always) and runs faster (always, unless you are awful at assembly). You also have to learn ALL of the idiocyncrasies (sp?) of your compiler before you can make your code jump through loops... with an assembler (even one that does you *favours* like converting move.l #0,d0 to moveq #0,d0) you just need to know your assembly. Period. -Steve >-- >..who come from long lines of soldiers, | richard@gryphon.CTS.COM >whose duty was fulfilled, | ihnp4!scgvaxd!cadovax!gryphon!richard >in the words of the warriors will, | rutgers!marque!gryphon!richard >and protocol. | codas!ddsw1!gryphon!richard -- Steven A. Dean sdean1@uvunix.BITNET sdean1@uvunix.UVic.CDN ...uw-beaver!uvicctr!sdean1 ...ubc-vision!uvicctr!sdean1
richard@gryphon.CTS.COM (Richard Sexton) (04/04/88)
In article <384@uvicctr.UUCP> sdean1@uvicctr.UUCP (Steven A. Dean) writes: >I wrote: >>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". >>[...] > ^^^^^^^^^^^^ >------------------------------------------------------||| >Yes! BUT! Sometimes very small isn't good enough! This is completely true. However the percentage of code for which "very small isn't good enough" in a given program is very small. From empirical observation i would guess 2%. >Besides, if you write a >lot in assembly, you can produce code that's smaller (almost always) and >runs faster (always, unless you are awful at assembly). You also have to >learn ALL of the idiocyncrasies (sp?) of your compiler before you can >make your code jump through loops... with an assembler (even one that >does you *favours* like converting move.l #0,d0 to moveq #0,d0) you just >need to know your assembly. Period. No one said it was easy. But it's a lot easier that doing everything in machine language. But you dont have to believe me, pick up your assembly manual and knock yourself out. -- "Ever since the world ended... I don't go out as much" richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
chas@gtss.UUCP (Charles Cleveland) (04/04/88)
Now personally I prefer either typing in the machine code directly in hex, or, for applications that call for a high level language, using COBOL. While I feel that the virtues of these techniques are being slighted in this discussion, I don't want to try convert anyone, as I might lose my competitive edge. -- -Life would be so much easier if we could just look at the source code.- Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332 UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edu
lel@wuphys.UUCP (Lyle E. Levine) (04/07/88)
In article <238@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: >Now personally I prefer either typing in the machine code directly in hex, or, >for applications that call for a high level language, using COBOL. While I >feel that the virtues of these techniques are being slighted in this >discussion, I don't want to try convert anyone, as I might lose my competitive >edge. > >Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332 I couldn't agree more! However, I don't like hex. I attached a few switches from the hardware store to the A2000 bus and enter the executable in directly in binary. This obviously will make faster code if the programmer REALLY knows what he is doing. As for COBAL, I was thinking of writing a COBAL compiler in "switch code" but decided against. COBAL is a nice language but is just too mathematics oriented. It's also too structured for a high level language. I think I'll just stick to "switch code". ========== IBM is a Division of Sirius Cybernetics Corporation "their fundamental design flaws are completely hidden by their superficial design flaws." - "So Long And Thanks For All The Fish" Lyle Levine: Paths -> ihnp4!wuphys!lel Best way: (314)889-6379 uunet!wucs!wuphys!lel