[WP34s] undefined OP-code

[fhub]

Just a minor problem:

There's an entry '???' in the catalog [cpx][h][MODE] which gives an "undefined OPcode" error when entered.

[Marcus von Cube, Germany]

I'll check it. Thanks!

Edit: A simple recompile did the trick. The command in question exists only in debug builds and somehow the catalogue did not get rebuilt properly the last time.

Edited: 27 Apr 2012, 9:18 a.m.

[fhub]

Quote:

---

Edit: A simple recompile did the trick. The command in question exists only in debug builds and somehow the catalogue did not get rebuilt properly the last time.

---

Ok, thanks.

Does this new build now also have this A..D-> command in the special menu? Pauli seems to have made this available in SVN 2898 if I understood his comment correctly.

[Marcus von Cube, Germany]

It cannot be used on the device outside XROM because it makes a copy of the registers in volatile memory which gets lost when the calculator is idle. The command is exclusively used in the new solver.

[fhub]

Ok, zu früh gefreut. :-(

[Walter B]

Nur gugge! Mit mansche Gommandohs derfe halt eggsglusief nur die Eggsberdte spiele ... :-)

[fhub]

Quote:

---

Nur gugge! Mit mansche Gommandohs derfe halt eggsglusief nur die Eggsberdte spiele ... :-)

---

Und I bin vielleicht ka Eggsberdte? ;-)

[Walter B]

Obviously you aren't - else you could access and use it :-)

[fhub]

Quote:

---

Obviously you aren't - else you could access and use it :-)

---

And you are?

Ok, at least for the manual - and for this ugly symbol like the new printer, instead of using the much more common commands PRTxxx (which are easier to find in the menu and to enter when writing a program on the PC). ;-)

I'm really wondering why you don't even use such icons for STOPW, or diskette icons for STO and RCL. It seems you want to turn the WP34s into an iPhone or Android.

Edited: 27 Apr 2012, 11:29 a.m.

[Marcus von Cube, Germany]

Franz, the symbol has the benefit of occupying just one character position which allows for longer distinguishing name parts, especially for the argument taking commands which should not be longer than 4 to 5 characters to avoid a switch to the small font upon entry of the command.

[fhub]

Ok, that may be one/your reason for using it, but I always thought that the WP34s should be as compatible as possible to his predecessors (41C etc.), and I can't remember having ever seen any such strange symbols in their functions.

And as I said: its place in the menu is not obvious, and it's really a nightmare having to enter all those [print]... in programs
(there are already enough such annoyances like [->] and [<->] and [^] and ....).

Edited: 27 Apr 2012, 11:39 a.m.

[Marcus von Cube, Germany]

This is much easier for our English speaking friends where [ and ] are readily available as an unshifted keyboard function...

I'm on your side with this and I'm thinking for a while about an 'alias' scheme which allows alternate names for many commands, at least in the assembler. This has a few implications:

1. We need to define the alias names
   
2. The assembler needs a major update
   

The discussion is moot if you work on the device where you have to pick the commands from a list. You can easily navigate within a catalogue if you know the keyboard positions of the special characters. The Greek letters are behind the g shift (nice to know for alpha commands) and the printer icon is on f EXIT (the arrow). Walter has collected all this info in the documentation.

[fhub]

Quote:

---

I'm on your side with this and I'm thinking for a while about an 'alias' scheme which allows alternate names for many commands, at least in the assembler. This has a few implications:

1. We need to define the alias names
   
2. The assembler needs a major update
   

---

Yes, this is indeed something that I've wished since I'm using the WP34s!

I never understood why you were using these strange brackets [] at all - if the parser (no matter whether the WP34s itself or the assembler) can recognize e.g. x[<->]y, he could certainly also recognize the much simpler x<->y (or even x<>y), and this is BTW also the way older HP calculators display this operation.

Even if you've introduced special characters for this <-> I don't see any reason why the _user_ should be forced to enter it in this complicated way [<->] and not just simply type <-> or <> (and the same for all comparisions like [<=] etc.).

The same for ENTER[^]: why this [^] at all, a simple ENTER would be enough!

The same for y[^x] or x[^2]: why not just allow entering y^x and x^2?

And I could continue this list almost infinitely ...

Edited: 27 Apr 2012, 12:13 p.m.

[Marcus von Cube, Germany]

The mechanism is the following:

Each character is either plain ASCII or it is a special character that is unique to our device character set. These special characters need to be encoded somehow and the original authors decided to use the bracket notation for this. This is fine for reading a listing but gets annoying quickly when you have to type the characters in.

I see two options:

1. Create an alternate (optional) set of replacement characters such as 'a' instead of [alpha] or 'p' instead of [print],
   
2. Treat each command individually and define an alias for it.
   

In messages for the alpha register, the bracket notation will be kept for unambiguousness.

[fhub]

For me the biggest problems are not things like [alpha] or [print], because these commands aren't used that often. But of course also these could be simplified by just omitting the brackets - a simple alpha or print (evt. prt) would do it, because I don't see that these names appear anywhere else (without []) in the opcode-list. The same would be true for [cmplx] which could just be replaced by cpx (or CPX as it is on the keyboard).

What me annoys most are things I've already mentioned above (at least a few examples), and the ugliest thing for me is [times]!!!

I really don't understand why we can't just use a simple * (as in every other computer language and even in other HP calculators). For division we use / and there's also an [alpha]/, so we could just as well have a simple * for multiplication and [alpha]* for the character * - just as well you could have introduced a [divide] symbol instead of /. And this [times] isn't only annoying to write down, but also to read in a listing!

And here a few more:

Why R[v] and not just RDN (the same for R[^] and RUP)

Why ENTER[^] and not just ENTER

Why y[^x] and not just y^x

Why [cmplx} and not just CPX (or cpx)

Why x[>=]0? and not just x>=0?

Why [->]POL and not just ->POL

Why STO[->] and not just STO->

Why [alpha][->]x and not just alpha->x (or even ATOX)

Why x[<->] and not just x<>

Why LOG[sub-1][sub-0] and not just LOG10

etc.........

I could give you dozens of other examples, but I'm sure you know what I mean.

The problem is that now it's very (if not too) late to make so many changes - it would have been better to think about this (i.e. how complicated these names are when you write a program in an editor) before using such names in the WP34s, now it would be much work to change it again.

Franz

[Marcus von Cube, Germany]

There is absolutely no reason to change anything in the firmware or manual, it's just the op-code table for the assembler.

[fhub]

Quote:

---

There is absolutely no reason to change anything in the firmware or manual, it's just the op-code table for the assembler.

---

JUST for the assembler?
I guess Neil would lynch me ... ;-)

Edited: 27 Apr 2012, 3:16 p.m.

[Neil Hamilton (Ottawa)]

Further on Marcus' comment, if it is done correctly, the old code would be read and processed just as well as any new code created using aliases. Source code even be written intermixing the styles(and we could even have multiple aliases if the Calculo-Trinity decides upon it...).

The biggest problem I see is what to do about the listing. The tool will not know that your binary was created from a source containing old, new, or a combination of mnemonics. So we will have to come up with a strategy for how to deal with that. Mind you, this is simply a cosmetic issue since the tool won't care which ones are fed back in -- only the author will. :-)

[Something tells me the preprocessor is going to make me eat my words about it being pretty simple...]

[fhub]

Quote:

---

The biggest problem I see is what to do about the listing. The tool will not know that your binary was created from a source containing old, new, or a combination of mnemonics. So we will have to come up with a strategy for how to deal with that.

---

Well, I would say that 2 versions would be enough: the old one and a new which should consistently use 'user-friendly' mnemonics, i.e. avoiding brackets whenever possible, using common names instead of special characters (like RDN instead of R[v] or Rv) etc.

If it won't be a problem to also implement more than 2 aliases (or even mixtures), then this would of course be ok for INPUT, but for OUTPUT the tool should only use the 'official' 2 versions, which could be selected by the user with a commandline-switch.

[Neil Hamilton (Ottawa)]

I doubt it is that major an update [famous last words?] but we do need to define the aliases. :-)

[Paul Dale]

Quote:

---

It cannot be used on the device outside XROM because it makes a copy of the registers in volatile memory which gets lost when the calculator is idle. The command is exclusively used in the new solver.

---

I was contemplating relaxing the xrom only distinction.
The question is are these commands too confusing to be useful.
The main problem being the volatile memory part, the other being the solver smashes the temporary store.

- Pauli

[Marcus von Cube, Germany]

We can probably add PUSH/POP and use the return stack for this but I have to make sure it does not conflict with local variables. You can, of course, allocate local registers and use R-COPY for this.