Shop OBEX P1 Docs P2 Docs Learn Events
P2 "Unit Tests" — Parallax Forums

P2 "Unit Tests"

SeairthSeairth Posts: 2,474
edited 2015-10-20 22:32 in Propeller 2
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.
«1

Comments

  • SeairthSeairth Posts: 2,474
    edited 2015-10-20 17:07
    note: the opcode for ABS is the correct.

    edit: it appears that C is not being set. Maybe C is being set to result[31] instead of S[31]?
  • Okay. I've put the above tests in a repository:

    https://github.com/Seairth/P2UnitTests

    I will continue to add tests there. Please feel free to contribute!
  • potatoheadpotatohead Posts: 10,255
    edited 2015-10-20 17:58
    Hmmm.. Maybe these can be combined at some point. Those same unit tests are the perfect, "what does this do when?" answers. Maybe link 'em at some point.

    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.

  • You know, we could also put those documentation blocks in the wiki in the same repository. However, it would be a bit cumbersome to discussion that documentation on the forums.
  • And then there's the GDocs file that Peter started. I wouldn't mind doing all of the documentation there, but that is soooooo slowww....
  • I kind of want to avoid the Google docs. If we use GitHub, we can link, take changes, and use Git Book to publish. I'm formatting with Git Book in mind.
  • potatohead wrote: »
    I kind of want to avoid the Google docs. If we use GitHub, we can link, take changes, and use Git Book to publish. I'm formatting with Git Book in mind.

    GitBook is an interesting idea!
  • I think so, and am happy to participate on the Google docs. But Git Book can result in a real book and that is worth a try.
  • Cluso99Cluso99 Posts: 18,069
    The difference in the ABS instruction, and some of the SHIFT/ROTATE instructions, in the P2 to properly set the C on the result rather than the source in the P1. IMHO it was incorrect in the P1.
  • SeairthSeairth Posts: 2,474
    edited 2015-10-20 22:42
    CMPX : Tests 9 and 10 fail

    Edit: CMPX is good. My unit test was bad.
  • Update:

    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").
  • cgraceycgracey Posts: 14,133
    I'll look into this MAX/MAXS issue in the morning.

    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.
  • cgracey wrote: »
    I'll look into this MAX/MAXS issue in the morning.

    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)?
  • cgraceycgracey Posts: 14,133
    edited 2015-10-22 15:06
    Seairth wrote: »
    cgracey wrote: »
    I'll look into this MAX/MAXS issue in the morning.

    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?
    This is correct.
    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.
  • cgraceycgracey Posts: 14,133
    Seairth,

    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?
  • cgracey wrote: »
    Seairth,

    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.
  • cgraceycgracey Posts: 14,133
    Searth,

    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.
  • cgraceycgracey Posts: 14,133
    Seairth,

    My intent was that all NEGxx instructions return the MSB of the result, not the MSB of S.
  • cgracey wrote: »
    Searth,

    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.

    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.
  • cgracey wrote: »
    Seairth,

    My intent was that all NEGxx instructions return the MSB of the result, not the MSB of S.

    Sounds good. I'll update the tests appropriately.
  • cgraceycgracey Posts: 14,133
    Seairth,

    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.
  • cgracey wrote: »
    Seairth,

    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.
  • That needs to go into the docs.

    C = Value hammer applied
  • cgraceycgracey Posts: 14,133
    potatohead wrote: »
    That needs to go into the docs.

    C = Value hammer applied

    Hammer time.

    HammerTime.jpg
    1328 x 747 - 324K
  • Hammered in due time...

    Sometimes you just gotta laugh!
  • RaymanRayman Posts: 14,056
    Is that walnuts?
  • cgraceycgracey Posts: 14,133
    Seairth,

    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).
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Is that walnuts?

    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.
  • Okay! Completed 90 tests, so far! And only one has failed (which is a PNUT bug, technically)! These were the easy tests... now for the less easy stuff. :P
  • cgraceycgracey Posts: 14,133
    Seairth wrote: »
    Okay! Completed 90 tests, so far! And only one has failed (which is a PNUT bug, technically)! These were the easy tests... now for the less easy stuff. :P

    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.
Sign In or Register to comment.