HP Forum Archive 21

[ Return to Index | Top of Index ]

another wp34s bug Message #1 Posted by Andrew Nikitin on 11 June 2013, 5:46 p.m. 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.

Re: another wp34s bug Message #2 Posted by Paul Dale on 11 June 2013, 8:50 p.m., in response to message #1 by Andrew Nikitin 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

Re: another wp34s bug Message #3 Posted by Andrew Nikitin on 11 June 2013, 10:05 p.m., in response to message #2 by Paul Dale 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?

Re: another wp34s bug Message #4 Posted by Paul Dale on 12 June 2013, 6:32 a.m., in response to message #3 by Andrew Nikitin 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

Re: another wp34s bug Message #5 Posted by Andrew Nikitin on 12 June 2013, 6:27 p.m., in response to message #4 by Paul Dale 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".

Re: another wp34s bug Message #6 Posted by Paul Dale on 12 June 2013, 7:06 p.m., in response to message #5 by Andrew Nikitin 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.

Re: another wp34s bug Message #7 Posted by Walter B on 13 June 2013, 1:42 a.m., in response to message #5 by Andrew Nikitin 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:-)

Re: another wp34s bug Message #8 Posted by Paul Dale on 12 June 2013, 6:16 a.m., in response to message #1 by Andrew Nikitin 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

Re: another wp34s bug Message #9 Posted by Paul Dale on 26 June 2013, 1:01 a.m., in response to message #1 by Andrew Nikitin This should be fixed in the latest build. - Pauli

[ Return to Index | Top of Index ]

Go back to the main exhibit hall