Found my first silicon bug
-
I've just found my first processor bug. No, not on one of the big guys like ARM or Intel but still a decent find on the Rabbit family of processors. The bug seems to have been there from the earliest days and to find it 20 years later is quite unexpected. I've always said that I like programs you debug with an oscilloscope and hardware bugs you find with a test program, but this is the first bug on silicon and not at board level. The feeling is quite ecstatic :) (what a big nerd am I!)
Mircea
-
I've just found my first processor bug. No, not on one of the big guys like ARM or Intel but still a decent find on the Rabbit family of processors. The bug seems to have been there from the earliest days and to find it 20 years later is quite unexpected. I've always said that I like programs you debug with an oscilloscope and hardware bugs you find with a test program, but this is the first bug on silicon and not at board level. The feeling is quite ecstatic :) (what a big nerd am I!)
Mircea
Never found a processor bug, but not all USART chips were the same: one brand that the purchase dept found cheap only worked async, and failed horribly with synchronous data. Yeuch, but that was a git to find - my dev hardware and half the production stuff had the "good chips". I remember finding my first compiler bug though: A Fortran problem on a GEC 4070 which generated the wrong machine code if the same variable was used in an IF and assigned in the next line of code. Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I've just found my first processor bug. No, not on one of the big guys like ARM or Intel but still a decent find on the Rabbit family of processors. The bug seems to have been there from the earliest days and to find it 20 years later is quite unexpected. I've always said that I like programs you debug with an oscilloscope and hardware bugs you find with a test program, but this is the first bug on silicon and not at board level. The feeling is quite ecstatic :) (what a big nerd am I!)
Mircea
As Griff was saying:
Quote:
Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
I worked it out what it is and here is my result. Z80 processor has/had an instruction
DJNZthat decrements register B and jumps if not zero. This is bread and butter of most small loops in Z80 assembly. It also has a set of "alternate" registers BC', DE' HL' but rather few instructions operate on those alternate registers. To compensate for this, Rabbit introduced anALTDprefix that can be added to most instructions to make them operate on the alternate registers. Now what happens with the instructionALTD DJNZ? Well, it takes the content of B register, decrements it and stores it in B' register making it a fairly useless instruction. Of course, this is not documented in the manual and you have to figure it out for yourself. Anyway, it left me feeling very flat :)Mircea
-
As Griff was saying:
Quote:
Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
I worked it out what it is and here is my result. Z80 processor has/had an instruction
DJNZthat decrements register B and jumps if not zero. This is bread and butter of most small loops in Z80 assembly. It also has a set of "alternate" registers BC', DE' HL' but rather few instructions operate on those alternate registers. To compensate for this, Rabbit introduced anALTDprefix that can be added to most instructions to make them operate on the alternate registers. Now what happens with the instructionALTD DJNZ? Well, it takes the content of B register, decrements it and stores it in B' register making it a fairly useless instruction. Of course, this is not documented in the manual and you have to figure it out for yourself. Anyway, it left me feeling very flat :)Mircea
The alt registers (or "shadow" registers) I always kept for interrupts (or NMI when we used that) so we could work faster - memory access to stack the registers is a load slower than EXX which was only 4 T states, compared to a minimum of 11 (plus any memory wait states) for a PUSH. With a 4MHz processor, you shaved T states where you could! :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
As Griff was saying:
Quote:
Joy when I worked out what it was and reported it to the ops manager. Who just said "yeah, we know about that one..." and left me feeling very flat.
I worked it out what it is and here is my result. Z80 processor has/had an instruction
DJNZthat decrements register B and jumps if not zero. This is bread and butter of most small loops in Z80 assembly. It also has a set of "alternate" registers BC', DE' HL' but rather few instructions operate on those alternate registers. To compensate for this, Rabbit introduced anALTDprefix that can be added to most instructions to make them operate on the alternate registers. Now what happens with the instructionALTD DJNZ? Well, it takes the content of B register, decrements it and stores it in B' register making it a fairly useless instruction. Of course, this is not documented in the manual and you have to figure it out for yourself. Anyway, it left me feeling very flat :)Mircea
Looks documented to me. The ALTD flag only changes the destination.
Mircea Neacsu wrote:
it takes the content of B register, decrements it and stores it in B register
I believe what is actually happening here is that the ALTD instruction is setting the destination of the DJNZ operation to one of the "alternate" registers which leaves the B register unchanged. Best Wishes, -David Delaune
-
Looks documented to me. The ALTD flag only changes the destination.
Mircea Neacsu wrote:
it takes the content of B register, decrements it and stores it in B register
I believe what is actually happening here is that the ALTD instruction is setting the destination of the DJNZ operation to one of the "alternate" registers which leaves the B register unchanged. Best Wishes, -David Delaune
You are right; I should have paid more attention. However, it seems to me that it drastically reduces the usefulness of the instruction.
Mircea
-
You are right; I should have paid more attention. However, it seems to me that it drastically reduces the usefulness of the instruction.
Mircea
Mircea Neacsu wrote:
You are right; I should have paid more attention.
Too bad you didn't find a cpu bug. :rose:
Mircea Neacsu wrote:
However, it seems to me that it drastically reduces the usefulness of the instruction.
Of course, more registers are almost always better! :-D Best Wishes, -David Delaune
-
Mircea Neacsu wrote:
You are right; I should have paid more attention.
Too bad you didn't find a cpu bug. :rose:
Mircea Neacsu wrote:
However, it seems to me that it drastically reduces the usefulness of the instruction.
Of course, more registers are almost always better! :-D Best Wishes, -David Delaune
Quote:
Too bad you didn't find a cpu bug.
Well the chase was exiting :laugh:
Mircea
-
Quote:
Too bad you didn't find a cpu bug.
Well the chase was exiting :laugh:
Mircea
-
Quote:
Most probably not. Test again and again ask yourself again and again is it really the processor and not your side.
I did and I'm fairly sure this is not the case. Filed a bug report and we'll see what happens. I don't have any qualms admitting my errors so I promise I'll post the "denouement" :D
Mircea
Mircea Neacsu wrote:
I don't have any qualms admitting my errors so I promise I'll post the "denouement"
And if it turns out you were right, will we have to call you Mircea cel Mare?
We won't sit down. We won't shut up. We won't go quietly away. YouTube, and My Mu[sic], Films and Windows Programs, etc. and FB
-
Mircea Neacsu wrote:
I don't have any qualms admitting my errors so I promise I'll post the "denouement"
And if it turns out you were right, will we have to call you Mircea cel Mare?
We won't sit down. We won't shut up. We won't go quietly away. YouTube, and My Mu[sic], Films and Windows Programs, etc. and FB
Quote:
And if it turns out you were right,
Unfortunately that's not the case. It was just my misreading of documentation as @Randor pointed out[^]. Anyway, as they say, the journey is more important than the destination and this one was a fun one :)
Mircea
-
Quote:
Too bad you didn't find a cpu bug.
Well the chase was exiting :laugh:
Mircea
@Mircea We have some of those boards integrated as part of industrial control systems, anything specific we need to worry about?
-
@Mircea We have some of those boards integrated as part of industrial control systems, anything specific we need to worry about?
No, I don't think so. The only possible damage is to my ego but I'm a big boy and I can take it :laugh: I was programming a particularly tight loop to read from an SPI device and thought I could use
ALTD DJNZinstruction to shave some cycles and use the alternate B register. It turns out theALTDprefix in this case is useless as I explained in a previous message. However, an instruction not doing what I expected can hardly be called a bug. No one has yet implemented the RPM (Read Programmer's Mind) instruction. :)Mircea
