another wp34s bug

[Andrew Nikitin]

LINEQS with out of range arguments in trace mode shuts down the calculator.

To reproduce, etner program:

1

1

3

.

0

3

0

3

ENTER

1

2

2

.

0

3

0

1

ENTER

1

2

5

STOP

LINEQS

Run it from the beginning. When it stops at STOP, press down arrow for step trace. Calculator will shut down.
3.2T3382

BTW, is it a bug that registers A-D (104-107) are prohibited as a target of matrix operations? Or is it intentional?

Edited: 11 June 2013, 5:47 p.m.

[Paul Dale]

I'm seeing an Out of Range Error here. Do you have local registers allocated? The matrices you are specifying are in the local register range.

Yes, it is intentional to not allow A - D to be used as part of a matrix. Likewise, I, J, K and L are banned.

- Pauli

[Andrew Nikitin]

It does give Out of range on emulator, but shuts down calculator. I just tried on another calculator, 3.2 3405, same result -- shuts down the calculator.

Bug happens when registers are not allocated. When they are allocated, everything works.

I was debugging a program and at some point lost local register allocation. Maybe hit shortcut or something. When I continued to step through, LINEQS shut down the calc.

What is rationale for not allowing A-L?

[Paul Dale]

Quote:

---

What is rationale for not allowing A-L?

---

Think about it. The reasons are not that hard to figure out :-)

Start with X, Y, Z and T. Why not allow them to be part of a matrix?

L and I are also volatile. L is changed by some matrix operations which would be somewhat inconvenient. Thus, they can't be used.

A-D can be part of the stack and thus should also considered volatile. Even if they were allowed and the stack size were checked at runtime for their validity, they lie between registers T and L so wouldn't be useful for anything larger than a 4x1 vector or a 2x2 matrix. If you're dealing with matrices this small, you're unlikely to be pressed for register space.

For J & K, the best they could be used for is a two element vector. Allowing a matrix to cross from global registers to local ones is somewhat insane -- what happens when a new set of locals are allocated e.g.? However, there is also a technical reason for not allowing this unnatural merger: the matrix routines assume that each matrix is stored contiguously in memory and these aren't.

It can all be boiled down to the simple guideline: the lettered registers are all special. They shouldn't be considered part of the local or global registers. That you can indirectly address them in a contiguous manner is nice.

- Pauli

[Andrew Nikitin]

Quote:

---

However, there is also a technical reason for not allowing this unnatural merger: the matrix routines assume that each matrix is stored contiguously in memory and these aren't.

---

So, matrix routine just does not access its memory them by register number and uses physical memory locations?
Also, page 24 of the pdf document suggests that registers K-X are between global and local registers. But maybe I just interpreted it wrong and it just illlustrates their position in "logical numbering".

[Paul Dale]

Yes, the matrix code goes to memory directly. Smaller and faster this way. You could have looked in matrix.c to see this :-)

Yes, you should consider register numbering as logical only. Finding this in the code would be more difficult, but consider what happens when a new local register frame is allocated? It couldn't possibly be adjacent to the globals since there are older locals in the way.

- Pauli

Edited: 13 June 2013, 2:23 a.m.

[Walter B]

The landscape memory page in the manual shows the address space of your WP 34S. The physical memory may be non-contiguous - please check Appendix B.

d:-)

[Paul Dale]

I've reproduced this on real hardware. It requires not XEQing a label to start the code. Add a LBL at the beginning and XEQ that and the bug doesn't appear.

I've some suspicions as to the root cause...

- Pauli

[Paul Dale]

This should be fixed in the latest build.

- Pauli