Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 3 Apr 91 10:43:26 GMT References: <1991Mar31.003933.1483@mintaka.lcs.mit.edu> <1991Apr1.020748.26863@mintaka.lcs.mit.edu> Organization: Amiga makes it possible Lines: 125 In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991Apr1.020748.26863@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >>In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>>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 > > I agree, you haven't looked at the output from a good compiler... GCC > is one of the best, though on an Amiga it runs the bejeezes slow > compiling something. You will ALWAYS be able to write assembly that > goes faster, but compared to a good C programmer the result will not > go *that* much faster, only a little faster. > > Not that I am advocating you write the game in C, clearly you > simply do not want to accept any arguments in favor of C, but > I'll try once to convince you. > [ stuff deleted ] > -Matt > >-- Hey, Matt (and others): In a big way, we are both arguing different points. I USE C A LOT. I just don't use it for anything I'd sell to anyone. I also wouldn't use it to make a program that I am going to use a lot. Ray Cromwell sent me a code fragment he compiled (it was posted in this group) with GCC. I AM impressed, with GCC, but I (an average coder) put it to shame. To make things worse (about GCC) is that EVERY single subroutine compiled with it loses in terms of size and speed. And people wonder why some programs with LOTS of functionality (Trackdisk.device in 2.0 is 7K :) while your standard printf("Hello, world\n") program is huge. Sometimes this tradeoff is something you might live with, others it's not. Even if you intend to go back and recode the entire program in assembler language, it is rare that it ever works out that way. Some other neato project comes along and you get stuck with what you have. Complete and thorough and well polished programs do take months and even years, even in 'C'. Consider all the commercial programs you have on your hard disk that were written in 'C' and compiled before GCC was available for the Amiga! I don't have the luxury of taking DPaint (for example) sources and running them through a better compiler. Dan Silva doesn't work at EA anymore, so there IS some possibility that there won't be a DPaint IV that was compiled with a better one. How about the ROM Kernel that we both love so much? Wouldn't it be nice to have been able to run the sources to it through improved compilers as they came out? Instead we are *still* waiting for 2.0 to go to ROM, and it still won't be compiled with a compiler that does as good as a human. How many years are we going to have to settle for what today's compiler was able to do? How many LINK, UNLK instructions do I unnecessarily have on my hard disk? How much for all the hard disks in the Amiga community alone? Terabytes? I often write programs that need to fit in small machines, so I'd rather save tens of thousands of bytes in a (> 100K) program. Now when you code portions of your programs in assembler, I agree that those routines gain back most of the size and speed lost by using a compiler. However, if you have a few hundred of these routines scattered in a lot of programs, how much work is it to change them to take parameters in registers instead of from the stack when a new compiler comes along that you want to use? What if you use #asm ... #endasm and your new compiler doesn't support it? Maybe someone can answer these questions for me: Why is the best compiler on the Amiga run the bejeezes slow? In my experience, your development cycle (edit/compile/link/run/debug and repeat all the above) is critical to your productivity. fWhy isn't something like LightSpeed 'C' available for the Amiga? It flies and generates awesome code. Why hasn't someone made the entire c.lib into a loadable library so all programs can share it instead of duplicating these routines hundreds of times all over everyone's hard disks? Why not even just printf.library (this alone would save megabytes on my hard disk)? Why didn't Jez Sans write a 'C' compiler? Why don't 'C' compilers support linkerless usage? Why don't 'C' compilers know about the routines in the OS without #pragmas? While we're at it, why not all the structures and other things from the header files, too? Why don't 'C' compiler c.lib libraries automatically use the Exec Task structure's TC_TRAPCODE field to trap 99% of the gurus that happen and force programs to exit gracefully? Maybe the question is why don't 'C' programmers do it all the time? Why do 'C' programmers ask me whether I use: MULU #17,d0 instead of: move.l d0,d1 lsl.l #4,d0 add.l d1,d0 when it is basic programming normally done by assembler language programmers (one of the oldest tricks in the book)? Come on people, no flames for this, these are serious questions. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************