[wp34s] The Matrix Reloaded patches

[emece67]

Hi all,

When I was an EE student, I heavily used the matrix capabilities of my 28C. Now I'm using a pair of wp34s for, almost, everything, but I miss, in some way, the ability to work with matrices. Of course the wp34s can do that, and the library offers many utilities to do that, but I prefer the convenience of selecting commands from "native" menus.

Thus, I ported some matrix operations from the library to XROM. I have also added some other matrix operations to XROM not in the library and also added ported versions of Thomas Klemm's utilities to cope with complex matrices (the CPX -> P -> Z transformations).

The end result is not as convenient as the 28C was, but it resembles the matrix capabilities of a 15C with an, I think, much more easy interface.

Now, with the addition of the complex lock mode, Bit's patches for integer operations and these matrix operations in XROM, I think of my wp34s as the perfect weapon for EE students. Unfortunately my students are not aware at all of the existence of this marvelous machine.

Hope it is useful for anybody.

Edited: I've made an upgrade from the previous version. In this upgrade the I register remains intact (its roll as a temporary flag container was subsumed by a dedicated 64 bit storage in volatile memory), so all new matrix commands work indistinguishably from built-in commands. I've also fixed a bug in the behavior of the column and row norms that prevented them to work as expected in some circumstances, touched-up the error management in order for it to be consistent with that of the built-in matrix commands and added 4 more commands to: invert all elements in a matrix (also in a complex matrix), conjugate a complex matrix and transpose a complex matrix.

Al these changes can be find here:

• The patch file (patched over SVN version 3796)
• The binary files to flash your wp34s
• The (Qt) emulator
• The user documentation for the new matrix operations
• The .op file (to use the assembler)
  

All this will cost you about 875 program steps.

Regards.

[fhub]

(07-01-2015 06:20 PM)emece67 Wrote:  Hope it is useful for anybody.

Well, the Qt-emulator version would really be interesting for me, but unfortunately it doesn't run, there are a few DLL files missing, at least the following (maybe even more):
libstdc++-6.dll
libwinpthread-1.dll
qextserialport1.dll
libgcj-12.dll

Franz

[emece67]

(07-01-2015 07:54 PM)fhub Wrote:  Well, the Qt-emulator version would really be interesting for me, but unfortunately it doesn't run, there are a few DLL files missing, at least the following (maybe even more):
libstdc++-6.dll
libwinpthread-1.dll
qextserialport1.dll
libgcj-12.dll

Franz

I have updated the uploaded files including the libstdc++-6.dll & qextserialport1.dll libraries. Now the emulator does work on a WinXP virtual machine w/o previous trace of any development environment. Perhaps you can take a new try.

But I do not have a trace of libwinpthread-1.dll or libgcj-12.dll in my hard disc. I do not have a clue why your system asks for them or where to download them from.

[fhub]

(07-01-2015 09:21 PM)emece67 Wrote:  I have updated the uploaded files including the libstdc++-6.dll & qextserialport1.dll libraries. Now the emulator does work on a WinXP virtual machine w/o previous trace of any development environment. Perhaps you can take a new try.

Yep, now it's working, many thanks!

Quote:But I do not have a trace of libwinpthread-1.dll or libgcj-12.dll in my hard disc. I do not have a clue why your system asks for them or where to download them from.

Well, I've used a libstdc++-6.dll that I found in any other software package, and this file required the above mentioned DLLs.

BTW, could you please also upload the wp34s.op for your matrix version, because then we could use your new functions also in own programs (for the assembler)?

Franz

[Paul Dale]

Nice work! Great work in fact. You've figured out a pile of the 34S internal code!


A question, why introduce IINIT and the I regsiter bit operations? Why not use xIN and the local flags (which it allocates)? This also preserves the stack, does the LastX handling for you and handles errors nicely. The downside is the volatile RAM xIN uses but I don't think that's going to be a problem since you don't seem to be using the memory heavy matrix operations from XROM.

Still, an impressive effort.


- Pauli

[Paul Dale]

(07-01-2015 10:21 PM)fhub Wrote:  BTW, could you please also upload the wp34s.op for your matrix version, because then we could use your new functions also in own programs (for the assembler)?

It looks like these changes break binary compatibility so the assembler will be required.


- Pauli

[emece67]

(07-01-2015 11:26 PM)Paul Dale Wrote:  Nice work! Great work in fact. You've figured out a pile of the 34S internal code!


A question, why introduce IINIT and the I regsiter bit operations? Why not use xIN and the local flags (which it allocates)? This also preserves the stack, does the LastX handling for you and handles errors nicely. The downside is the volatile RAM xIN uses but I don't think that's going to be a problem since you don't seem to be using the memory heavy matrix operations from XROM.

Still, an impressive effort.


- Pauli

Because xIN/xOUT force DBLON mode and existing (and the new) matrix ops only work in DBLOFF mode. Evenmore, I want the matrix operations to be able to work with matrices stored in local registers, but I was unable to do that with xIN/xOUT (despite the ENABLE_COPYLOCALS option, perhaps I didn't understand the existing code here). These forced me to use the IINIT hack.

[emece67]

(07-01-2015 10:21 PM)fhub Wrote:  BTW, could you please also upload the wp34s.op for your matrix version, because then we could use your new functions also in own programs (for the assembler)?

Franz

I've just updated the links in the first post including such file.

[Paul Dale]

(07-02-2015 05:27 AM)emece67 Wrote:  Because xIN/xOUT force DBLON mode and existing (and the new) matrix ops only work in DBLOFF mode.

It would be easy enough to add an extra xIN flag to avoid the switch to double which could be useful elsewhere.

Quote:Evenmore, I want the matrix operations to be able to work with matrices stored in local registers, but I was unable to do that with xIN/xOUT (despite the ENABLE_COPYLOCALS option, perhaps I didn't understand the existing code here). These forced me to use the IINIT hack.

I thought matrices could be allocated in locals, the code looks like it tries to allow that. Maybe this isn't useful inside xIN/xOUT which creates a very limited stack in volatile RAM.

It looks like copy locals copies them in from outside the xIN/xOUT pair. I don't remember why this was included -- Marcus did most of this stuff he might remember.

The big issue I see with IINIT is it destroys the I register which isn't good for the user. You could allocate a local register frame with the LocR command and use those flags/registers if xIN/xOUT aren't working.


- Pauli

[emece67]

(07-02-2015 06:46 AM)Paul Dale Wrote:  It would be easy enough to add an extra xIN flag to avoid the switch to double which could be useful elsewhere.

I tried that and it worked indeed. But my big concern with the xIN/xOUT approach was my inability, despite my efforts, to be able to access matrices stored in local register from inside the xIN/xOUT environment.

(07-02-2015 06:46 AM)Paul Dale Wrote:  I thought matrices could be allocated in locals, the code looks like it tries to allow that. Maybe this isn't useful inside xIN/xOUT which creates a very limited stack in volatile RAM.

They can. The "built-in" matrix commands are written in C and they can reach such matrices without problems. The issue is reaching such matrices from inside xIN/xOUT, or from inside LocR, as the new frame these environments create hides the frame where the matrices are stored.

(07-02-2015 06:46 AM)Paul Dale Wrote:  The big issue I see with IINIT is it destroys the I register which isn't good for the user. You could allocate a local register frame with the LocR command and use those flags/registers if xIN/xOUT aren't working.

I agree with you, I tried my best to circumvent the problem of accessing matrices stored in locals from XROM code and ended up with this sub-optimal solution. As I said before, using LocR will also prevent access to such matrices.

Edited: perhaps adding a i[->], [->]i pair working as A..D[->] and [->]A..D would do the trick. Not elegant, but better for the user.

[Paul Dale]

(07-02-2015 11:52 AM)emece67 Wrote:  I tried that and it worked indeed. But my big concern with the xIN/xOUT approach was my inability, despite my efforts, to be able to access matrices stored in local register from inside the xIN/xOUT environment.

Ah, I misunderstood your problem. You are correct of course.


- Pauli

[emece67]

I've just edited the opening post including links to a new version of the patches that prevents the I register to be cleared. As stated there, I've also fixed some bugs, some inconsistencies with the built-in, existing, matrix commands and added four new commands.

Regards.

[fhub]

(07-07-2015 05:28 PM)emece67 Wrote:  I've just edited the opening post including links to a new version of the patches that prevents the I register to be cleared. As stated there, I've also fixed some bugs, some inconsistencies with the built-in, existing, matrix commands and added four new commands.

Thanks for the update!

But one WARNING (at least for the users of your Qt-emulator):
With this new version the opcodes (wp34s.op) have changed again, but the included library file wp34s-lib.dat has NOT been updated.
So if you want to use any programs from this library, you have to rebuild a new version of this file by yourself, because using this outdated file will definitely not work (giving at least wrong results or the programs my even crash)!

IMO it's a very bad idea to have different opcodes (i.e. files wp34s.op) for different WP34s versions (or updates) - there's so much room left in the opcode table, that new commands could easily be using these gaps instead of overwriting the old (official) opcodes.

Franz

[emece67]

(07-08-2015 12:08 PM)fhub Wrote:  But one WARNING (at least for the users of your Qt-emulator):
With this new version the opcodes (wp34s.op) have changed again, but the included library file wp34s-lib.dat has NOT been updated.
So if you want to use any programs from this library, you have to rebuild a new version of this file by yourself, because using this outdated file will definitely not work (giving at least wrong results or the programs my even crash)!

IMO it's a very bad idea to have different opcodes (i.e. files wp34s.op) for different WP34s versions (or updates) - there's so much room left in the opcode table, that new commands could easily be using these gaps instead of overwriting the old (official) opcodes.

I've just updated the wp34s-lib.dat file in the above links for it to work (with this Qt emulator).

How to generate an wp34s.op file not reusing old slots is, pitifully, out of my capabilities.

[Paul Dale]

(07-08-2015 03:30 PM)emece67 Wrote:  How to generate an wp34s.op file not reusing old slots is, pitifully, out of my capabilities.

It is actually pretty easy. Don't take any commands out of the enums in xeq.h. Don't rearrange these. Add new commands only at the ends of the enums.


- Pauli

[emece67]

Suppose I move all my changes in xeq. h to the end of the enums. If I select a different set of features tinkering in features.h, will the new wp34s.op file be "compatible".

I assumed it was not compatible.