Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re:    Lemmings - a tutorial Part V (last)
Message-ID: <1991Apr1.020748.26863@mintaka.lcs.mit.edu>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Organization: The Internet
References: <mykes.0774@amiga0.SF-Bay.ORG> <1991Mar31.003933.1483@mintaka.lcs.mit.edu> <mykes.0926@amiga0.SF-Bay.ORG>
Date: Mon, 1 Apr 91 02:07:48 GMT
Lines: 150

In article <mykes.0926@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>In article <1991Mar31.003933.1483@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>If you want to design your own games, go ahead.  But don't tell me and
>everyone else how to do it.  If everyone designs games exactly the way
>you do, it would get real boring real fast.  The fact that individuals
>design games, instead of a design by community approach, gives us variety
>in game play, look and feel, and style.

  I'm not telling you how to design games, I'm merely giving you
an alternative viewpoint. You seem to think that flashy graphics are what
makes games good. Graphics and Sound are nice, but they aren't everything.
Psygnosis games are widely known to be the most UNPLAYABLE games on the
Amiga. If it weren't for the trainer modes, most people would have given
up playing them by now. 

>>  That's what compiled C code looks like. C is used for large projects
>>that an Assembly programmer could never accomplish in a resonable
>>amount of time. I programmed Assembly for 7 years, and I can do things
>>in C++/LISP that would take insurmountable time in assembly.
>>I do wish C= would optimize certain parts of the OS with AssemblY.
>>(Optimize Layers Library clipping code in assembly, and Exec's dispatcher,
>>and the vertical blank interupt handler. Intuition should stay in C, but
>>stuff like WritePixel should be in Asy)
>>
>
>A couple of points.  Exec is already in assembler language.  You might
>optimize just a few bytes/cycles out of it.  It is the foundation of the
>OS.  It was done RIGHT (assembler).  Layers is really not that slow when
>you consider what it has to do (and compare it with other OS performance).
>ReadPixel and WritePixel are still going to be slow because it has to
>do rastport clipping (so you don't plot pixels outside of a window).
>Finally, development time is also not as much of an issue as is quality.

  If development time isn't a problem, why don't you spend lots of time
making a game that runs under the OS. Don't say it can't be done, Heart
of the Dragon has action just was smooth as Budokan with more colors!

>When you call printf() you are relying on someone else's coding ability.
>When you call an OS routine, you are relying on someone else's coding ability,
>too.  You not only have your own bugs to deal with but those in the (link)
>library and those in the ROM.  When you run native under the OS, you are also
>relying on a wide variety of PD software hacks (like POPCLI, etc.) that people
>use to also not have bugs.  Remember, one wild store in any of this software
>crashes everything.

  Somewhere along the line your going to have to rely on other peoples' code.
When a physicist/chemist studies Science, he is relying on research and facts
collected by people before him. There isn't such a thing as an 'ultimate'
programmer. MOst of the optimizations you think up, have been thought by
up by many other people as well. Ibet there isn't a single assembler
trick you can do, that hasn't be though up before. Commodore did not hire
idiots. The Commodore crew is just as good at programming as you, they jyst
do a different kind of programming. If you insist on re-inventing the wheel
everytime you code because you don't believe other programmers' routines 
aren't as "perfect" as your specs require, you deserve to be overworked.

>As far as 'C' goes, I have stepped through enough disassembled 'C' code to
>see enough.  How much RAM is wasted on LINK, UNLK instructions?  How many
>cycles are wasted by pushing arguments on the stack to call a subroutine?
>How many cycles are wasted by calling a "glue" routine?  How many cycles
>and bytes are wasted by fixing up the stack after each and every subroutine
>returns?  How much stack do you need to allow for all the dynamic allocation
>of local variables?  512K is not a lot of RAM to go and waste memory all the
>time.  A 7.14 MHz 68000 isn't fast enough to waste all the extra cycles, if
>you are striving for performance.

  Obviously you have no idea of how advanced today's optimizing compilers
are.  The code you stepped through must have been produced by some
1970's MetaComco compiler or something. But FYI, most of todays compilers
can pass arguements in registers, allocate memory without stack, eliminate
the frame registers, and even do all the non-obvious tricks of sign extension,
etc. Check out the code I've included at the end compiled by GCC.


>In practice, assembler is quite good at both data structures and event
>driven programming.  If you haven't tried it, check it out and then
>comment again.

  I have tried it, without a great Macro assembler and some nice Macros,
it's still a pain. And assembler can't even come close to object oriented
programming such as data abtraction, inheritance, operator/function overloading
and streams. Assembler is just overkill for mostly everything. Assembler
has it's place, but if you program in assembler 100% of the time, your
a masochist. (Even on the C64 I routinely used compiled basic to implement
some tools like sin tables generators etc.)

>
>--
>********************************************************
>* Appendix A of the Amiga Hardware Manual tells you    *
>* everything you need to know to take full advantage   *
>* of the power of the Amiga.  And it is only 10 pages! *
>********************************************************

The following was compiled with GCC -O -fstrength-reduce -fomit-frame-register
I don't have SAS C on the Amiga, but I'm sure it produces simular results.

/* test.c */

char buf[20];
main()
{
  char *d=(char *)&buf;
  const char *s="This is a test\n";
  while(*s) { *d++=*s++; }
}

/* Test.s produced by gcc */

#NO_APP
gcc_compiled.:
.text
LC0:
	.ascii "This is a test\12\0"
	.even
.globl _main
_main:
	lea _buf,a1
	lea LC0,a0
	tstb a0@
	jeq L5
L4:
	moveb a0@+,a1@+
	tstb a0@
	jne L4
L5:
	rts
.comm _buf,20

 I can easily provide more real life examples of produced code, but the
fact of the matter is, just like Chess computers beating the majority of
humans, compilers are reaching a state where they can outperform the
 majority of humans in optimization. I have no doubt that is in the
next 5 years they are going to get even better. What's worse, is that
the new CPU's being produced today have instruction sets and architectures
that are almost impossible to code optimally without considering
timing of the instruction combined with other instructions.

  Also, it's not the language but the algorithm that is responsible for
how fast a routine runs. Compare a C coded Boyer-Moore string search
with an Assembly coded brute-force byte by byte search, the C code would
probably win without optimizations turned on.



--
/~\_______________________________________________________________________/~\
|n|   rjc@albert.ai.mit.edu   Amiga, the computer for the creative mind.  |n|
|~|                                .-. .-.                                |~|
|_|________________________________| |_| |________________________________|_|
