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: <1991Mar31.003933.1483@mintaka.lcs.mit.edu> Date: Mon, 1 Apr 91 02:07:48 GMT Lines: 150 In article 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| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|