Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!uunet!sdrc!cinnet!kilian From: kilian@cinnet.com (Kilian Jacob) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Short Hello World Message-ID: <1991May6.020315.17620@cinnet.com> Date: 6 May 91 02:03:15 GMT Article-I.D.: cinnet.1991May6.020315.17620 References: <1991May5.011748.11595@zorch.SF-Bay.ORG> Organization: Cincinnati Network, Cinti. OH Lines: 66 From article <1991May5.011748.11595@zorch.SF-Bay.ORG>, by xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan): > dvljrt@cs.umu.se (Joakim Rosqvist) writes: > >> [some boring C-code deleted] :-) > >> Ok, assembler strikes back with this: (56 codesize, 92 executable) > >> OpenLib=-408 >> Output=-60 >> Write=-48 > >> move.l 4.w,a6 >> lea dos(pc),a1 >> jsr OpenLib(a6) >> move.l d0,a6 >> jsr Output(a6) >> move.l d0,d1 >> lea hello(pc),a0 >> move.l a0,d2 >> moveq #12,d3 >> jmp write(a6) > >> dos: dc 'dos.library',0 >> hello: dc 'Hello World',10 > >> /$DR.HEX$ > > And a better example of how _not_ to program would be hard to find. > > You've managed, in a 15 line program, to include 3 "magic numbers" > that are dependent on the release of dos.library, so that your code > need not merely be reassembled for an operating system upgrade, but > rewritten. Sprinkle an equivalent 20% fraction of bogosities into > 100,000 lines of code, and you might as well throw it away and start > fresh as try to port it to the next release. Where are the "three magic" numbers in the program above? > Doing the linker's job for it is _not_ a smart move, as the first > three lines clearly demonstrate. I guess you're talking about the function offsets for the three Library functions used. Those numbers are not "magic." Well, theoratically they could change from one to another os version. But then *NO* compiled program -no matter what language it was written in- would work (assuming that it uses the function whose library offset is changed). Practically, there is no difference whether your linker or one self defines those constants. Any C compiler -in essence- does exactly the same thing. And trust me, there is no reason to change these offsets; they don't have *ANYTHING* to do with the location of a library function in ROM. * > If you are going to evade higher level languages to worship at the altar > of code size and speed, you have to work _much_ harder than this to > equal the high level language's relatively automatic maintainability > advantage. It always depends on the size of the program you're developping. For short programs like the above it's worth using assembly language. For larger programs the consideration whether to choose C or ASM is developement time - NOT compatibilty. -- /