WP34S Program Labels

[M. Joury]

I have tried to search the web to see if this was ever discussed and have found nothing. So I ask: Why was the decision made to limit program labels to 3 characters?

While FAR superior to what is available on the 32/33/35 and obviously better than the Voyager series it would have been nice to have the capability of the 41/42 calculators in this area. Was there some specific implementation limitation that did not allow for longer labels or made such an implementation more difficult?

[Paul Dale]

It was discussed, just not here.

Implementing longer names is more difficult as you guessed.

Three characters fit nicely into two op-codes in program memory and I implemented double length op-codes just for this. Going longer would require some design work to allow longer op-codes in program memory. This would have the advantage that strings and numbers could possibly be merge into single steps. But I'm under no delusions as to the difficulty involved.

As usual feel free to submit a patch :-)

- Pauli

[Marcus von Cube, Germany]

Having longer labels or packing strings and numbers in variable length op-codes would be really nice but I have no illusions that it will be easy. The main problem is navigating backwards in the code either manually or via BACK.

A relatively simple implementation would involve a single "add another three characters to the previous instruction" instruction which is automatically appended if a label gets longer. The instruction is otherwise treated as a NOP. But it will affect label search, the label browser and most probably more pieces of the code.

I can imagine the feature will appear some time but there is no free lunch: Adding features will definitely cost us another library region. I've recently made a suggestion to Pauli and Walter for kind of a user keyboard (using -> as a prefix as suggested here). Both features together will probably fit in another K of flash sacrificing a library region for the purpose.

[M. Joury]

It sounds like you have given this some thought. Implementation details would be interesting and I don't know enough about how it is currently implemented to make any suggestions. My simplistic approach would be an opcode to denote "label-characters follow" followed by a length. For going backwards you would need something similar on the end as well but probably with the order reversed (length.TerminatingOpcode). Unfortunately this uses 4 bytes just to manage the strings even if you have a single character label and this gets expensive. A hybrid approach could retain the current 1/2/3 character labels you have now and implement the above idea for labels longer than 3 characters. And then of course there is the approach you suggest which, given your familiarity with the code, is probably a better approach.

As the source code is primarily C I'd like to take a look, time permitting, and see if any ideas jump out at me. Unfortunately at the moment I am pretty much swamped with my real job so it may be a while before I get to it.

Thanks for the info that you and Pauli provided!

[Paul Dale]

I won't go into top many details but a rough outline is possible.

Op-codes are two byte integers. For alpha labels two of these are paired into four byte integers. Stepping forwards is easy, we know the length of the op-code by partially decoding it. Stepping backwards is more difficult, we have to look at every possible length to see if there is an op-code of that length ending just before where we are. Currently, there are only two op-code lengths and thus two places to look so this isn't too bad. Going to op-codes of 1 - 17 bytes like the 41 series would make this more difficult. I think the 41 solves the problem by rescanning from the start to find the previous instruction -- we could do this too and certainly have the speed to do it instantly but it isn't how it is coded currently.

Then we come to label searches. Since we've only two op-code sizes (2 and 4 bytes), I take a big short cut here and build the label op-code in an integer variable. Then I can quickly search for this label using a tight loop that pretty much just does an integer compare and a pointer increment. Again, this could be coded around but it will be more involved matching longer opcodes.

These decisions were made a long time ago before the possibility of using internal flash for program storage was realised. Would I do things different if we started again? Definitely.

- Pauli

[Marcus von Cube, Germany]

Pauli, my fault. :-(

;-)

[Paul Dale]

Not at all. It is good to elucidate about what turned out to be sub-optimal decisions.

At the time the decision was made I was sure it was a good way to do things. If the ground rules hadn't changed in the meantime, it would still be a good way.

Of course back then the device had about 500 program steps and no possibility for more step or backups. It has grown considerably.

We learn from our mistakes after all :-)

- Pauli

[M. Joury]

Thank you both for your outline of how the code currently works. If I may ask two questions: What module would you start with if trying to decipher the opcode parsing and IP increment code? And what compiler are you currently using?

I would like to take a look to see if any ideas strike me for a way to implement variable length opcodes to handle labels. As far as that goes, are there any other areas that would benefit from multi-byte opcodes? I believe that string handling was mentioned earlier?

Thanks,

Marwan

[Paul Dale]

You will want to look in xeq.c for the instruction decode and execute xeq() is the function that handles all command execution. Both user commands from the keyboard and programs go through here -- keyboard commands are converted to op-codes (in keys.c). If we're in program mode, they are stored and if not, they are executed. This is another thing I'd do differently, I'd have the command tables have a flag to decide if something is stored or executed in program mode -- there are specially coded exceptions for CLP, CLALL and DELp.

As for increment and decrement of the PC, inc() and dec() again in xeq.c Be very very careful with these, they are fragile beyond belief but don't appear to be.

I don't know the compiler, Marcus handles that aspect now.

Strings and numbers could benefit from longer op-codes. I've a disabled command that appends three characters to alpha but no keyboard interface for it. I have a good idea how to do the same for numbers but again no real idea how to present this to the user.

Better than packing keystrokes would be to store the compiled number and strings directly -- this is greatly complicated by integer and real modes however.

The next iteration (with a different model number) will likely address all this and more. Don't hold your breath waiting :-)

- Pauli

[M. Joury]

Thanks Pauli,

I'll take a quick look. However, any in-depth work may have to wait a while. As you noted elsewhere we all do this as a hobby and unfortunately my day job is demanding my attention these days <g>.

Cheers,

Marwan

[Marcus von Cube, Germany]

Marwan, we are using a GCC 4.2 cross compiler (yagarto.de) for the real build and Visual Studio 10 (or VC++ Express) for the emulator.

[M. Joury]

Thanks Marcus,

I'll stick with VS for now since I am very familiar with it.