Does anyone know how the 41 nut cpu behaves when it comes to instruction sequences that should be avoided?

The David assembler manual basically says that AND and OR should not follow an arithmetic instruction that can have a carry out of the highest bit of the register.

The HP internal doc states that various instructions, most flag instructions (plus AND and OR) should not follow an arithmetic class 2 instruction.
What is an arithmetic class 2 instruction here? Is it any class 2 instruction, even such as C=0 which does not even affect carry? Are relational compare instructions such as A<C affected as well (it probably does an internal subtraction)? What about C#0?

The HP description does not feel right, I have done things that should be avoided in the past without getting any ill effects I could see. I feel a little bit puzzled by this.

In short, what should I look out for? Should I trust David, HP or are there other interpretations on what should be avoided?

Hi, Håkan;

I am sorry not having an answer to your question, but I am surely following the thread.

Cheers.

Luiz

Note that HP had three generations of Nut CPU chips, 1LA5, 1LE3, and 1LF5 (and more if you count some of the later Voyager variants), so it is remotely possible that bugs might have been fixed in the later ones. On the other hand, they probably didn't have any significant justification for investing the engineering effort to fix the bugs, so it is more likely that they kept the logic design of the core the same.

Hi, Håkan;

A recent addition to T.O.S. (Doug Wilder´s QuinTable.pdf) brings the following relevant notes:

Quote:

---

3. NOT (C=-C-1) always sets carry.

4. AND and OR misbehave if carry is set.

5. POP misbehave in DEC mode: increments msd if in the range A-F.

6. G register misbehave if PT=13

Copyright 1987, 2005 STC, W.D.Wilder

---

Cheers.

Luiz (Brazil)

Edited: 30 Dec 2009, 9:49 p.m.

Guess what, you get to test! get your head out of your ass and test your surmise, don't be stupid, test your premise:
Sorry,

It ain't that hard to test your code, don't be afraid, just try it,
it can only crash your calc and you can revive via MEMORY LOST.

don't be afraid, i love 41c. Don't be afraid.

Doug

PS: JUST TRY IT

Edited: 31 Dec 2009, 10:56 a.m.

I hoped there were some deeper insights available in this issue. In that case I will need to fire up my MLDL and HP41 and try some stuff out myself.

I am not afraid, I had far fewer MEMORY LOST messages doing MCODEing than I did with synthetics... :)

It is just that I do not have my MLDL anywhere close to me at the moment, so it will have to wait. Anyway, I have some good starting points what to look at when I get around to it.

I know nothing beats the real thing but V41 does an excelent job as surrogate of a HW MLDL. It supports the Hepax module quite flawlessly (others maybe too but I haven't tried them).

Bad news if you're not using Windoze, though - but maybe you've got another system available fot these purposes.

Best wishes,
AM

My paper "Inside the NUT CPU" over on the unmentionable site may
provide some insights.


I was never able to figure out the "not after class 2" restriction.
If I had to guess, I would say that it has something to do

with a carry affecting the instruction similar to how it is

used for the conditional jumps... but that is just a guess.


I do not consider the G=13 case to be a bug. As I explain

in the aforementioned paper, the results are exaclty what falls

out of a straigtforward bit-serial implementation of the normal

case.


In all cases, it is important to remember that this design

is from an era when every single transistor counted, so a

designer would spend time minimizing the number of transistors.

Add to this the bit-serial operation, and most of the "bugs"

that have been documented can be easily explained.


Because emulators typically do not atempt to mimic this

bit-serial operation, it is unlikely that they will duplicate

out-of-the-norm cases. Even with my NEWT design, which retains

the bit-serial operation, I didn't ever try to verify all of

the abnormal cases. For example, arithmetic operations, in

decimal mode, when the register contents are not valid decimal

numbers. Odds are that the results will be the same, because

the arithmetic functions are the same, but I never bothered

simulating these cases.

Monte

I have so far studied old HP documentation, Doug Wilder´s QuinTable.pdf, David's assembler manual, the Monte Dalrymple's "Inside the NUT CPU" and "NEWT Microprocessor Technical Manual".

The G register and pt=13 thing I have stumbled over myself by accident way back before I even saw it documented. It is well explained in the Newt paper as well as David's assembler manual.

David also explains the C=C|A and C=C&A bugs, but the description is
not the same as I saw in QuinTable.pdf. I will need to experiment with it myself a bit on real hardware.

Non-BCD numbers in decimal mode arithmetics behavior is tested by the service module. I found this out when I tried the service module
on my emulator. (I did it wrong initially).

Anyway, I feel there is a reasonable complete understanding of many of the things going on. The darkest corner seems related to the class 2 (arithmetic) instructions being followed by certain other instructions mystery.

Many thanks, I will keep the information I have collected so far in mind when I can power up my MLDL later for some experiments.

On the Saturn CPU, decimal arithmetic with non-BCD digits is non-commutative. I haven't tested this with the Nut or earlier CPUs, but it's on my todo list.