another wp34s bug



#2

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.


#3

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


#4

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?


#5

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


#6

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".


#7

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.

#8

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:-)

#9

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

#10

This should be fixed in the latest build.

- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  wp34s binomial bug Andrew Nikitin 4 580 09-22-2013, 05:20 PM
Last Post: Paul Dale
  Expon bug in wp34s Andrew Nikitin 7 848 07-14-2013, 03:23 AM
Last Post: Marcus von Cube, Germany
  weird statistics bug in wp34s Andrew Nikitin 5 801 06-20-2013, 01:54 PM
Last Post: Namir
  [WP34S] A funny bug in Pi (prod) Eduardo Duenez 3 593 01-28-2013, 03:41 AM
Last Post: Walter B
  [WP34s] Bug or feature? Dieter 25 2,004 01-03-2013, 06:20 PM
Last Post: Paul Dale
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 425 10-04-2012, 04:59 PM
Last Post: Paul Dale
  Bug in WP34S? Namir 5 653 08-05-2012, 06:32 PM
Last Post: Namir
  [WP34S] Curious Bug in Inverse Normal Function Les Wright 61 3,296 05-01-2012, 02:44 AM
Last Post: Paul Dale
  WP34s: Complex AGM (Bug...) Eduardo Duenez 33 2,485 04-23-2012, 05:59 PM
Last Post: Paul Dale
  WP34S: Fractions (Bug?) Eduardo Duenez 1 307 04-22-2012, 08:42 PM
Last Post: Paul Dale

Forum Jump: