P2 "Unit Tests"
Seairth
Posts: 2,474
It occurred to me that the P1 documentation already has concise truth tables for many of the instructions, and similar truth tables are going to be needed for the new instructions as well. As a result, I wrote a generic "unit test" template that I then apply to each instruction:
* set the instruction to test
* specify the number of tests to perform
* provide the data for each test, matching the truth tables in P1 (note: C and Z are swapped)
Each test that passes lights up the associated GRN led. There is currently no indication of why a test fails.
So far, I have only done the "A" instructions that already existed in P1, so ANYB is not included in the attachment. And it appears I have already found one instruction that fails: ABS. Particularly:
Test 1 : Pass
Test 2 : Pass
Test 3 : Fail
Test 4 : Pass
Test 5 : Pass
Test 6 : Fail
More to come later. I am thinking these might need to go in a github repository. That way, they can be added piecemeal and contributed to a bit easier than in this post/forum.
Edit: The aforementioned repository is located at https://github.com/Seairth/P2UnitTests. I have removed the attachment.
* set the instruction to test
* specify the number of tests to perform
* provide the data for each test, matching the truth tables in P1 (note: C and Z are swapped)
Each test that passes lights up the associated GRN led. There is currently no indication of why a test fails.
So far, I have only done the "A" instructions that already existed in P1, so ANYB is not included in the attachment. And it appears I have already found one instruction that fails: ABS. Particularly:
Test 1 : Pass
Test 2 : Pass
Test 3 : Fail
Test 4 : Pass
Test 5 : Pass
Test 6 : Fail
More to come later. I am thinking these might need to go in a github repository. That way, they can be added piecemeal and contributed to a bit easier than in this post/forum.
Edit: The aforementioned repository is located at https://github.com/Seairth/P2UnitTests. I have removed the attachment.
Comments
edit: it appears that C is not being set. Maybe C is being set to result[31] instead of S[31]?
https://github.com/Seairth/P2UnitTests
I will continue to add tests there. Please feel free to contribute!
And I am thinking down the road to a Programmers Reference and Model type document in the future, not necessarily now.
This means I should do the same for the use examples, to permit said linking and use in other online, not published or pre-formatted documents, like PDF.
I'll get to that very soon.
GitBook is an interesting idea!
Edit: CMPX is good. My unit test was bad.
I now have 50 unit tests written.
All but one of the ones that "fail" are due to the difference between the P1 implementation (where I got the truth tables from) and the P2 implementation. As soon as Chip confirms those differences (or someone can point me to a post where he already said as much), I'll correct all those. This would leave only one unit test that's failing for a legitimate bug (MAX/MAXS "D<S" vs "S<D").
I think I will start a thread tomorrow for fixes in progress, so that we can be sure that nothing gets forgotten. There are half a dozen or so things that need attention.
Can you confirm that the general behavior for shift operators is now to capture the last bit shifted out into C?
More generally, take a look at the current unit test results: https://github.com/Seairth/P2UnitTests/wiki/Unit-Test-Results
Other than MAX/MAXS, are all of the other ones actually correct (but just differ from P1)?
I'll look at that document, but, "yes", some P2 instructions differ in function from P1.
Those tests you made a really helpful.
About MAX/MAXS (and MIN/MINS): I wanted to C to be set whenever a correction was made (S was used for the result because of an out-of-bounds condition between D and S). It looks to me like it is doing that. Would you agree, or is there something else going on?
That's sounds right. I'll double check.
ABS is returning the MSB of the result, which is always going to be 0, except in the case of $8000_0000. The C flag would be more useful, I think, reflecting the MSB of the S input, as that data is (almost) always lost. What do you think would be better, considering that similar instructions return the the MSB of the result, not S? I think this could go either way.
My intent was that all NEGxx instructions return the MSB of the result, not the MSB of S.
I say leave it as it is. If the "before" bit value is important, it can be easily captured/tested for. Leaving it for $8000_0000 makes this similar to TOPONE/BOTONE, where it indicates an invalid result.
Sounds good. I'll update the tests appropriately.
I just tested the MIN/MAX/MINS/MAXS instructions and they all work as intended. C reflects whether the hammer had to be used to knock the value into range.
I'll update the tests to reflect this.
C = Value hammer applied
Hammer time.
Sometimes you just gotta laugh!
TOPONE and BOTONE seem to be working fine. These instructions evaluate S and put the result in D.
TOPONE returns the highest "1" bit position (0..31) while BOTONE returns the lowest "1" bit position (0..31).
C=1 if there were no "1" bits in S and Z=1 if the result is 0 (the case for inputs $00000000 and $00000001).
Those are bags of walnut meal, which are the tailings of a local shelling operation. They are perfectly good walnut meat, but have some shell pieces in them, which are shockingly hard. You need to sift that meal before you try to eat it.
My girls got that doll at the local Salvation Army store and I had him in my office for a while, but his perpetual party persona was too incongruous with Prop2 work, so I moved him to the freezer where he's been chilling, for like a year now.
That's great, Seairth.
I've got SETQ2+WRLONG transferring lut to hub and I've added two CNT-match events. I hope to have new FPGA images out soon.