Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cbmvax!cbmehq!cbmdeo!jsmami!jsmoller From: jsmoller@jsmami.UUCP (Jesper Steen Moller) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: <18ee3f47.ARN125e@jsmami.UUCP> Date: 4 Apr 91 01:14:51 GMT References: <1991Mar31.003933.1483@mintaka.lcs.mit.edu> <1991Apr1.020748.26863@mintaka.lcs.mit.edu> Reply-To: cbmehq!cbmdeo!jsmami!jsmoller (Jesper S. Moller) Followup-To: comp.sys.amiga.programmer Organization: Danish SofTech Lines: 148 In article , Mike Schwartz writes: > 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Depends on the human. I'm not sure who, but someone said that any compiled C program could be coded better by any assembler programmer. This is wrong. Take for instance the switch construction in C. Most of "Any assembler programmer" would do a CMP/BEQ structure to implement this, without taking furhter notice. But see how a good C compiler does this. It takes the values and builds a jump table or does the CMP/BEQ (mabye does some kind of "bisection" first), or possibly a compination of these. All depending of how many "case"-values there is, and how big the difference between the single cases are. Now mix this with some contitional compiling and a lot of #defines. Now the "Any assembler programmer" is in deep trouble, while the C compiler handles all the trivial stuff and the programmer writes another module and drinks a cup of coffee. "The real good assembler programmers" (like you seem to be) would do the work and write programs that gain 15% over the C-compiled version. But "Any assembler programmer" would waste some orders of magnitude if unlucky. The C programmers would have time for their coffee and version 2.0, though. This is another example of Matt's general message (the right algorithm...). > 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. Some are LINK/UNLK are waste. Some are there because of a source that is modulized and easy to maintain so that you will receive a new version some day. > 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? Well, the #asm/#endasm wasn't in my Kernighan/Richie text, but I might have missed it... no, actually it's good practise to seperate C and assembler. I help in the situations described above. > Maybe someone can answer these questions for me: > > Why is the best compiler on the Amiga run the bejeezes slow? It's good at optimizing, and that takes time. And, it wasn't written by Matt (unless you do mean DICE of course...) so it might have some inefficient algorithms in it... > In my experience, your development cycle (edit/compile/link/run/debug > and repeat all the above) is critical to your productivity. Yeah, but C-coders just do a version 1.1 or 2.0 that pays off, enough to buy a faster Amiga ;-) ... No, point taken. > 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)? Yeah, you picked the problem - one c.library is too big, and splitting up gives too much overhead. Unless the complete c.library goes into ROM! It's on it's way, just take a look at 2.0 DOS Library. Buffered I/O, FPrintF, etc. etc. Randell has been a good boy. Anyway, if I have to use a sprintf in a tiny program, I'd use RawDoFmt(), which (although not documented under 1.3) does most of the standard C stuff. > Why don't 'C' compilers support linkerless usage? Because of scanned libraries. The good one will link for you, though (DICE, SAS/C). > 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? I recently got the include files for 2.0, and - boy - if my compiler still would load hard-coded 1.3 values - I'd be reeeal angry. The key word is flexibility. > 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? That was a good one - I hack up catch.a to just that, one day. BTW, it's not c.lib, it should be the startup code (c.o or catch.o or whatever). > 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, if you were to code e.g. a file requester, and you had VISIBLE_FSEL_LINES EQU 17 ; or whatever and you'd do a MULU.L #VISIBLE_FSEL_LINES,d0 one day, you'd forget this. Using a define here is good, and any day now it might be changed to 37, when recompiling for interlace (or whatever). That is (my humble guess) why we ask. > Come on people, no flames for this, these are serious questions. You got no flames, and serious answers. > **************************************************** > * I want games that look like Shadow of the Beast * > * but play like Leisure Suit Larry. * > **************************************************** Sure, Leisure Suit Larry could use a re-implementation while Shadow of the Beast would need a re-design. Greets, Jesper (Can we conclude that assembler is suitable for "once and for all" coding, while a C core is easier to maintain if you know your program will have to be expanded, and that assembler in the right places is a good thing?) -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/