home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp48 / 6679 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  3.5 KB

  1. Path: sparky!uunet!gatech!destroyer!cs.ubc.ca!unixg.ubc.ca!ochealth
  2. From: ochealth@unixg.ubc.ca (ochealth)
  3. Newsgroups: comp.sys.hp48
  4. Subject: Re: Tricorder simulator
  5. Date: 5 Jan 1993 07:17:50 GMT
  6. Organization: University of British Columbia, Vancouver, B.C., Canada
  7. Lines: 63
  8. Message-ID: <1ibcmuINNr58@iskut.ucs.ubc.ca>
  9. References: <STEVEV.93Jan4104203@miser.uoregon.edu> <1iajt3INNp3f@iskut.ucs.ubc.ca> <STEVEV.93Jan4192708@miser.uoregon.edu>
  10. NNTP-Posting-Host: unixg.ubc.ca
  11.  
  12. In article <STEVEV.93Jan4192708@miser.uoregon.edu> stevev@miser.uoregon.edu (Steve VanDevender) writes:
  13. >In article <1iajt3INNp3f@iskut.ucs.ubc.ca> ochealth@unixg.ubc.ca
  14. >(ochealth) writes:
  15. >
  16. >   One can speculate on Alonzo's mnemonics, but BSET, BCLR, JSR
  17. >   etc. are all familiar Motorola mnemonics, same with $ for
  18. >   hex.and same with the move.a (d1),a
  19. >
  20. >   So it look s like CLASS is much closer to a standard than
  21. >   the AG mnemonics (which is disappointing to learn)
  22. >
  23. >So perhaps we should just program the Saturn in 68000 assembler?
  24. >The Saturn is not a 68000.  I don't think you get the point,
  25. >which is indeed disappointing to learn.
  26.  
  27. Who said 68000? Every goddam 68xx series microcontroller, 65xx series
  28. uses the opcodes the way Lutz does them, while Alonzo is the one that adds
  29. the quirk. The Saturn is a Saturn, so following your conservatism, maybe 
  30. we should use HP's mnemonics. Sounds like hypocrisy to me: if you want
  31. to bitch about Lutz's mnemonics being different than Alonzo's, maybe
  32. you should be bitching about Alonzo's being different than HP's.
  33.  
  34. I'm not the one who started second guessing the design motives of
  35. of each instruction set (Alonzo's vs. Lutz's), you were.
  36. >
  37. >What I object to is changing a few parts of a well-established
  38. >assembly language format while leaving others alone, introducing
  39. >unnecessary confusion and incompatibility.  The changed mnemonics
  40. >are no better in terms of comprehensibility or notational
  41. >convenience than the originals.  One should think very carefully
  42. >before introducing those kinds of changes, and be able to justify
  43. >them.  Alonzo Gariepy did a lot better in inventing a new,
  44. >consistent set of Saturn mnemonics to use in place of HP's than
  45. >Lutz Vieweg did in gratuitously changing a few of Alonzo's
  46. >around for his assembler.
  47.  
  48. Following your reasoning, we could say that Alonzo was wrong to
  49. have changed HP's mnemonics, after all, Alonzo's 'changed mnemonics
  50. are no better in terms of comprehensibility or notational
  51. convenience than the originals [HP's]', at least using any measurable,
  52. objective set of criteria.
  53.  
  54. I happen to like Alonzo's mnemonic set, but that is a subjective opinion.
  55. I don't think I'll switch to Lutz's, but it sort of mildly annoys me to
  56. find out that Alonzo's mnemonics are the bastardized Motorola style,
  57. and then you are griping about Lutz's being real Motorola style.
  58.  
  59. You accuse Lutz of 'gratuitously changing a few of Alonzo's around'.
  60. For all we know, Lutz has been confined to the Fidonet wasteland
  61. with a 300 bps modem, living in a shack in the Black Forest 
  62. for the past 5 years, and has never seen Alonzo's. Just because
  63. they look similar, doesn't mean Alonzo is the one who invented
  64. that style, and Lutz is the one who 'gratuitously' changed Alonzo's.
  65. We all know Motorola, Rockwell had been using that style for years,
  66. with all kinds of CPUs, controllers etc. Sheesh! Give the guy a break.
  67.  
  68.  
  69.  
  70. -- 
  71. ______________________________________________________________________________
  72. ochealth@unixg.ubc.ca         
  73.                             
  74.                                                       
  75.