grahamf@hparc0.HP.COM (Graham Fraser) (11/29/90)
There has been a lot of talk/notes/messages etc... regarding assemblers /
disassemblers and mnemonics for the HP48's Saturn CPU.
"Dumb question" / "Foot-in-mouth" time:
Why are people re-inventing the wheel, and developing their own sets of
Saturn mnemonics ??? There seems to be at least two sets being circulated
at the moment, and neither follows the HP mnemonics.
Way back in the early HP41 days - remember them ? there were the Jacobs
mnemonics, and the HP mnemonics, and it caused all sorts of problems and
difficulties. So why do the same again with the HP48 ???
When HP released the HP71, they made the system "open", and made the
complete Internal Design Specifications (IDS) available in three volumes.
Volume 1 provided all of the details that you needed, and listed all the
mnemonics, how the CPU registers are used, how the internal stack is
handled etc ............ Some of this information was also available in
the HP71 Forth Assembler ROM Manual. So why do it all again from scratch ??
In addition to restoring commonality amongst users, there is one other
important benefit to using HP's mnemonics:
In his talk at the Chicago CHIP Conference in June, Bill Wickes
screened a slide which showed Dennis York (HP) sitting behind a
partition in the lab. On the partition were pinned many notices,
messages etc... from HP calculator users taken from a variety of
sources - including these Notes. The HP Calc Lab members read
those notes which occasionally provides the lab with ideas,
inspiration, ...... while they work on new projects. There have
been many messages here asking "HP, ARE YOU LISTENING ???" Well,
it seems that HP do listen, but it will do us no good if we speak
a different language. We may notconsider HP's mnemonics to be the
best, but at least it's a standard, it's the language they speak
in the lab, and surely if it's good enough for HP to use to develop
the HP71, HP28, HP48 and othe Saturn based calculators, it's
good enough for us to use.
One final thought. If we start using the HP mnemonics, that just may
give them a little more encouragement towards making more development
tools available, or releasing more information.
Graham Fraser
HP Calculator User & Enthusiast
HP41 =>> HP71 =>> HP28 =>> HP48 =>> HP??
________________________________________________________________________
I am not employed by Hewlett-Packard, I just get to use their equipment.
My comments are my own, and do not necessarily reflect those of HP.
_________________________________________________________________________howard@lysator.liu.se (MindWalker) (11/29/90)
grahamf@hparc0.HP.COM (Graham Fraser) writes: >Why are people re-inventing the wheel, and developing their own sets of >Saturn mnemonics ??? There seems to be at least two sets being circulated >at the moment, and neither follows the HP mnemonics. As far as I know, there two sets are: The MC68000 inspired set and HP's own. The reson for adopting the MC68000 inspired set (as detailed by Alonzo in his HP28S PROCESSOR NOTES) is that HP's own set is so God-awful ugly. It's like Basic with bit manipulation thrown in. I don't mean to be insulting to HP, but I can't get used to the idea that those mnemonics represent machine code. Apart from it's lack of estetics, I for one am used to the 8080/Z80, MC68000 style instructions were you have an op-code followed by one or more operands. It makes for easy reading and spacious listings. With HP's style (as can be seen in Mier-J's book CUSTOMIZE YOUR HP28) there is less uniformity. You also tend to get rather odd listings, and it just doesn't _look_ like assembler code. Again, another reason is that, to my knowledge, there is no free HP-mnemonic assembler available, whereas at least one (ASAP) exists for Alonzo-style mnemonics, and I know that several more are being written. I certainly feel more at home with Alonzo's set of instructions and apparently so do most of the other mc programmers on this newsgroup too, since all code that I have seen has been written using this instruction set. Who says that just because HP use one (rather odd) set of mnemonics, that that set _has_ to be the best ?? OK, they may have invented it first, and it may be the one used internally (within HP that is), but that doesn't necessitate that we must conform to that standard. Besides, HP have as much access to the free Alonzo-mnemonic assemblers as the rest of us ;-) ;-) (Though most come with the restriction that they must _not_ be used for commercial software). /MHd -- Programming isn't a science, | Foo: howard@lysator.liu.se it's an art. | Bar: d89marho@odalix.ida.liu.se Why is it called common sense, | Fubar: Martin_Howard:d89:lith@xns.liu.se when so few possess it ? | Voice: Int +46 (0)13 261 283 (GMT + 1h)
bson@rice-chex.ai.mit.edu (Jan Brittenson) (11/30/90)
In article <421@lysator.liu.se> howard@lysator.liu.se (MindWalker) writes: > The reson for adopting the MC68000 inspired set (as detailed by Alonzo > in his HP28S PROCESSOR NOTES) is that HP's own set is so God-awful > ugly. It's like Basic with bit manipulation thrown in. I don't mean to > be insulting to HP, but I can't get used to the idea that those > mnemonics represent machine code. This is a funny statement. I think the first orthogonal source-destination assembler I used was Macro-11, which dates from 1972 or so. The only element genuinely 68k in Alonzo's set is the dot, which I find to be an abomination. A move byte should be called "moveb" or "movb", without the dot. But it's still zillions of lightyears ahead of HP's. If the alternative set wasn't invented, someone would invent it. I would. > Again, another reason is that, to my knowledge, there is no free > HP-mnemonic assembler available, whereas at least one (ASAP) exists > for Alonzo-style mnemonics, and I know that several more are being > written. Anyone interested in beta-testing STAR 1.01, which is a macro assembler, can get it with anon FTP from @ai.mit.edu: ~/pub/star-1.01.tar.Z. It should compile fairly effortlessly on most systems. It does general C-style arithmetic, and comes with an HP-48SX Standard Macro Library, which implements macros for some common HP-48 objects. For HP compatibility, a macro libary to handle HP mnemonics is planned. As is one for non-dot syntax. The HP compatibility requires certain features - e.g. definable syntax - that currently do not exist.
n233dk@tamuts.tamu.edu (Rick Grevelle) (11/30/90)
>grahamf@hparc0.HP.COM (Graham Fraser) writes: >>Why are people re-inventing the wheel, and developing their own sets of >>Saturn mnemonics ??? There seems to be at least two sets being circulated >>at the moment, and neither follows the HP mnemonics. >I certainly feel more at home with Alonzo's set of instructions and apparently >so do most of the other mc programmers on this newsgroup too, since all code >that I have seen has been written using this instruction set. >Who says that just because HP use one (rather odd) set of mnemonics, that that >set _has_ to be the best ?? OK, they may have invented it first, and it may >be the one used internally (within HP that is), but that doesn't necessitate >that we must conform to that standard. Besides, HP have as much access to >the free Alonzo-mnemonic assemblers as the rest of us ;-) ;-) I agree. Even an idiot could see that Alonzo's instruction set is superior to the one used by HP. Only now am I able to use the IDS mnemonics. Because I'd no previous experience with machine language programing, the Mier book did very little to help me; the primary reason being the IDS mnemonics it utilized. It was Alonzo's Processor Notes that gave me the necessary understanding to begin programing the 28 in machine language. An individual who would complain about having another set of mnemonics which serves to facillate the use of the Saturn language to more people, should reexamine their position on the issue. Rick Grevelle
Jake-S@cup.portal.com (Jake G Schwartz) (11/30/90)
I wholeheartedly agree with Graham Fraser's comments regarding HP's Saturn mnemonics for one reason, which simply is - if the HP folks who wrote the calculator and who read these postings can readily understand (without having to learn another set of mnemonics) what people are talking about, they probably will participate more actively. Yes, the new set of mnemonics are easier to learn and easier to manipulate, etc, but these new ones were written by people who did it for fun, hobby, etc. These guys at Corvallis had to live with the original mnemonics because it's their jobs. I'm sure they don't all take their jobs home with them and think about this stuff 24 hours a day. The last thing they'd probably want to do is to learn something simply to be able to understand what the extreme hard core hobbyists are doing. However, I'm sure that if they read a posting that contained both a listing in new mnemonics AND HP mnemonics, then these guys could pick it up right a way, and perhaps would be more apt to jump in and help out. This is precisely what Bill Wickes suggested on the evening of November 11th when he visited us at the Philadelphia Area HP user group meeting. I don't think anyone is suggesting abandoning the great work that Alonzo and others have done to make the CPU instructions more readily understood; I'm just suggesting we give the Corvallis people a chance to understand what's going on without forcing them to jump through some unnecessary hoops. We'll all benefit from their participation in this arena, no matter how much people feel it's more macho to go off and discover the "goodies" on their own. I personally would rather have this material handed to me rather than to go out and get it myself. Jake Schwartz
bob@teda.UUCP (Bob Armstrong) (12/01/90)
One comment for all those who think the HP mnemonics are "awful" (and I would have to agree): the original HP41 MCODE mnemonics are not unlike a lot of _microcode_ mnemonics, especially for machines with relatively vertical architectures. If you believe that the original HP41 programmers felt that they were microcoding a target instruction set (FOCAL in this case) rather than writing a FOCAL interpreter in "assembly" language, things look a lot better. It's all in the point of view... Bob Armstrong