xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (05/05/91)
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. Doing the linker's job for it is _not_ a smart move, as the first three lines clearly demonstrate. 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. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/05/91)
See my posting in alt.sources.amiga. For some reason, DNews didn't cross post my reply to Kent's article. In article <1991May5.011748.11595@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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. > >Doing the linker's job for it is _not_ a smart move, as the first >three lines clearly demonstrate. If you take over the machine, there's nothing wrong with doing the linker's job. If you are using the OS, use the header files! > >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. > Not true. Again, see my posting in alt.sources.amiga. It shows how to do this program right without losing any automatic anything. >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> > -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
dvljrt@cs.umu.se (Joakim Rosqvist) (05/05/91)
In article <1991May5.011748.11595@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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. What!?! In my opinion I use only 1 "magic" number, The address 4, which is blessed by Commodore. The 3 values you are talking about are index:es in a jump-table, which remain the same with new releases. That's what jump-tables are for, otherwise you could jump directly to a ROM-address (which even I wouldn't do) /$DR.HEX$
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (05/05/91)
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > See my posting in alt.sources.amiga. For some reason, DNews didn't > cross post my reply to Kent's article. xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: [Talking about a short hello world with constant library offset "magic numbers" hard coded in:] >> 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. > Not true. Again, see my posting in alt.sources.amiga. It shows how to > do this program right without losing any automatic anything. But in fact you make my point for me, by writing code that _does_ pay attention to surviving upgrades. By "work harder" I did not mean "write longer code", though yours is, or "press the keys down harder", though if you typed what would have taken me, a fast typist, ten minutes to enter in one minute, your fingers weren't waiting for the upstroke of the keys, but "think a lot harder about maintainability issues", which your code demonstrates you did. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
kilian@cinnet.com (Kilian Jacob) (05/06/91)
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. -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian