▼
Posts: 115
Threads: 10
Joined: Aug 2008
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?
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, Håkan;
I am sorry not having an answer to your question, but I am surely following the thread.
Cheers.
Luiz
Posts: 2,309
Threads: 116
Joined: Jun 2005
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.
Posts: 4,027
Threads: 172
Joined: Aug 2005
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
No specific explanation about the reasons or internal structure, but it gives some extra info.
Cheers.
Luiz (Brazil)
Edited: 30 Dec 2009, 9:49 p.m.
Posts: 126
Threads: 12
Joined: Jun 2007
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.
▼
Posts: 115
Threads: 10
Joined: Aug 2008
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.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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
Posts: 297
Threads: 25
Joined: Nov 2006
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
▼
Posts: 115
Threads: 10
Joined: Aug 2008
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.
▼
Posts: 2,309
Threads: 116
Joined: Jun 2005
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.
|
