Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 3 Apr 91 16:58:44 GMT References: <1991Mar31.003933.1483@mintaka.lcs.mit.edu> <1991Apr1.020748.26863@mintaka.lcs.mit.edu> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 106 In-Reply-To: mykes@amiga0.SF-Bay.ORG's message of 3 Apr 91 02:43:26 PST In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: 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'. Yeah - but assembler takes even longer. I have more things I want to do than time to do them already. Coding in ASM from scratch means even fewer of them are going to get done. So I code in HLLs, and more of them get done. I also know that they'll require minimal work to move to another machine. 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? It doesn't take any more work to rewrite the assembler routines than it does to add prototypes to the C routines. If you use #asm and #endasm in your C, you get what you deserve. 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. It depends on what you mean by the "best compiler". In any case, I find that accurate type-checking is far more critical than the development cycle time. That means you get to skip a fair part of the compile step, and all of the link/run/debug steps for that cycle, and probably several other trips through the cycle while you try and track down the bug. Ideally, of course, you blow off the compile/link phases until you're ready to generate production code. Getting either of these benefits in asm seems to be impossible. Why isn't something like LightSpeed 'C' available for the Amiga? It flies and generates awesome code. Because the IBM PC & MAC markets are much more competitive than the Amiga market. 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)? See above. Why don't 'C' compilers support linkerless usage? See above. 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? C compilers know as much about the routines in the OS & the structures as any assembler I've seen. Of course, I didn't evaluate every assembler on the market, and some of them may have been designed with symbol tables wired into them. Silly idea.... 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)? Because they're not well-educated? Personally, I'd ask the compiler writers why they didn't use shift/add technic for constants, as it's one of the oldest tricks in the book. Of course, you do have to watch out for things like that. The next rev of the CPU could make the obvious-but-slow sequence faster (i.e. - the obs instructions moves from microcode to hardware, or some such). BTW, if you want things that _really_ fly, you use a processor with an WCS (or better), and code at that level. It can be harder (if it's horizontal, much, much, much harder) than writing assembler, but you can do away with lots of slow activities, most notably touching off-CPU memory. Come to think of it, I once made the mulu example faster than the asm-level shift/add by optimizing the mulu code to do the shift/add in a single instruction instead of two. But that was long ago and far away....