A challenge for PASM enthusiasts!

WossnameWossname Posts: 169
edited 2017-05-30 - 18:36:56 in Propeller 1
Synopsis: Write a pure PASM program for Propeller 1 (for a single Cog) that uses every opcode, every "condition" (IF_C, IF_NC...) and every "effect" (WR, WC, WZ, NR) at least once.

Details:
There has been some interest in the last few days about various methods to make a purely software emulator to run PASM code on a PC.

If we were to make such an emulator/simulator (call it what you will) then it would make sense to have a piece of PASM test code that could be used in the debugging stages.

Such a PASM program would exercise a prospective emulator in such a way as to ensure that all opcodes are called at least once and that all conditionals are used at least once and that all combinations of WR, WC, WZ, NR are used at least once.

The program need not do anything useful -- that is an important point. We're testing the emulator, not the PASM! However, if you can do all these things AND make a program that does something useful or entertaining (while being of minimal length) then you'll win a lot of nerd points, even more points if the program can be run successfully on a Propeller 1 chip.

I will suggest the following as a starting point. Simply remove the three "nop" instructions and insert your ingeniously crafted PASM program to give an emulator a good work-out!
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
PUB Main 
   cognew(@ENTRY_POINT, 0)
DAT                          
                        org     0
                        
ENTRY_POINT                      
'##################################################################################
                        nop                              
                        nop                              
                        nop                              
'##################################################################################
                        fit                         

Comments

  • Furthermore...

    Imagine running your program in an emulator/simulator and stepping one-line-at-a-time through the code executing as you go. Each instruction executed must have a well-known outcome on the state of the Propeller. This is so that the emulator can be judged to be a true representation of the chip's behaviour.

    Bear in mind that the emulator software may be a work in progress! It is OK if the HUB operations don't work yet, or if the counters are not implemented yet.

    The aim is to create a gold-standard PASM test program that can be used to verify an emulation/simulation program or at least be a great aid to those ends.
  • Dave HeinDave Hein Posts: 5,921
    edited 2017-05-30 - 19:30:58
    Wossname, you seem to be pretending that Gear and spinsim do not exist. Have you looked at either one? As far as a test program, I had one that would fetch an instruction from a table, execute it, and then print out the result and the state of the C and Z flags. I would run this program on real hardware and spinsim to verify that they both produced the same output. The PASM test code was generated by a C program that I wrote. I think I posted it to the forum several years ago. I'll see if I can find it.
  • Wossname wrote: »
    Such a PASM program would exercise a prospective emulator in such a way as to ensure that all opcodes are called at least once and that all conditionals are used at least once and that all combinations of WR, WC, WZ, NR are used at least once.

    The program need not do anything useful -- that is an important point. We're testing the emulator, not the PASM!

    And how do you know that the emulator is doing the right thing and returns the correct results ?

    Sorry, but that's not how a software should be tested. Never heard of test driven programming and such things ?

    You have several pieces to test, first the conditionals, you need to test that the code portion of the PASM interpreter is treating the conditional flags correctly, how do you test that with your PASM blob that does everything ? Then the instructions, how do you know that, for example, the AND instruction is calculating C and Z correctly ? How do you test if the immediate value is readed correctly ? And so on...
    VT-100 Terminal and Graphics Card for the RC2014 Z80 Computer
  • WossnameWossname Posts: 169
    edited 2017-05-30 - 19:44:11
    Dave Hein wrote: »
    Wossname, you seem to be pretending that Gear and spinsim do not exist. Have you looked at either one? As far as a test program, I had one that would fetch an instruction from a table, execute it, and then print out the result and the state of the C and Z flags. I would run this program on real hardware and spinsim to verify that they both produced the same output. The PASM test code was generated by a C program that I wrote. I think I posted it to the forum several years ago. I'll see if I can find it.

    Sorry, I didn't mean to annoy anyone. I meant this as a bit of fun. Yes I do know about gear and spinsim. I will try them out as soon as I can (overtime permitting :)).

  • WossnameWossname Posts: 169
    edited 2017-05-30 - 19:50:17
    macca wrote: »
    Wossname wrote: »
    Such a PASM program would exercise a prospective emulator in such a way as to ensure that all opcodes are called at least once and that all conditionals are used at least once and that all combinations of WR, WC, WZ, NR are used at least once.

    The program need not do anything useful -- that is an important point. We're testing the emulator, not the PASM!

    And how do you know that the emulator is doing the right thing and returns the correct results ?

    Sorry, but that's not how a software should be tested. Never heard of test driven programming and such things ?

    You have several pieces to test, first the conditionals, you need to test that the code portion of the PASM interpreter is treating the conditional flags correctly, how do you test that with your PASM blob that does everything ? Then the instructions, how do you know that, for example, the AND instruction is calculating C and Z correctly ? How do you test if the immediate value is readed correctly ? And so on...

    You're right. Forgive me. I'm used to doing things in different ways perhaps.
  • Is the Propeller 1 tested functionally in production or with BIST logic? If it's tested functionally, then Parallax should have some test code with known coverage already developed.
  • macca wrote: »
    Wossname wrote: »
    Such a PASM program would exercise a prospective emulator in such a way as to ensure that all opcodes are called at least once and that all conditionals are used at least once and that all combinations of WR, WC, WZ, NR are used at least once.

    The program need not do anything useful -- that is an important point. We're testing the emulator, not the PASM!

    And how do you know that the emulator is doing the right thing and returns the correct results ?

    Sorry, but that's not how a software should be tested. Never heard of test driven programming and such things ?

    You have several pieces to test, first the conditionals, you need to test that the code portion of the PASM interpreter is treating the conditional flags correctly, how do you test that with your PASM blob that does everything ? Then the instructions, how do you know that, for example, the AND instruction is calculating C and Z correctly ? How do you test if the immediate value is readed correctly ? And so on...

    I'm certainly a big fan of TDD, but tests can be written incorrectly or miss something. It might make a lot of sense to have extensive unit tests and then also this one big PASM program that can be invoked by-hand to give yet another layer of assurance that the system is running correctly.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • DavidZemon wrote: »
    I'm certainly a big fan of TDD, but tests can be written incorrectly or miss something. It might make a lot of sense to have extensive unit tests and then also this one big PASM program that can be invoked by-hand to give yet another layer of assurance that the system is running correctly.

    Yes, of course unit tests should be integrated with functional tests that not only demostrates the working of a single piece of the software but also the interaction between the pieces, but using small test programs with known and replicable results, not certainly with a program that does everything.
    VT-100 Terminal and Graphics Card for the RC2014 Z80 Computer
  • When I wrote my Z80 emulator, in PASM, for the Propeller I found a Z80 instruction set test program included with the SIMH Z80 emulator package http://schorn.ch/altair.html.

    Basically that program tested Z80 instructions by dynamically building a Z80 instruction, writing it into some fixed memory location, setting up some register and memory values, then running the instruction.

    After executing the instruction a checksum was taken over the memory locations used and the processor registers, flags, etc.

    That check sum is then compared to the checksum generated when running this same procedure on a real Z80.

    A similar approach could be used for testing an emulation of PASM instructions.

    In this case though one could check execution results between ones new emulator and the Verilog version of the Propeller. No actual Propeller required to test against.

    The advantage of this approach is that you don't have to write specific tests for specific instruction features which is long winded, tedious and error prone. You are just comparing your emulator results with whatever a real Propeller does.
  • KeithE wrote: »
    KeithE, thanks for finding that thread. That's what I was looking for.

  • Heater. wrote: »
    In this case though one could check execution results between ones new emulator and the Verilog version of the Propeller. No actual Propeller required to test against.

    The advantage of this approach is that you don't have to write specific tests for specific instruction features which is long winded, tedious and error prone. You are just comparing your emulator results with whatever a real Propeller does.

    Hmm - for the Propeller 1 didn't the Verilog come later from a manual translation of AHDL? I seem to remember some bugs being found in the Verilog. If you diff the Parallax repository against some of the others there are some differences that aren't just enhancements.
  • Yes the Verilog came later. It is not what was used to build the P1.

    As such, yes you are right, it may have divergences from the real P1 silicon.

    Still, whilst we are all busy fuzzing the P1 instruction set on various simulators, the verilog and the real chip we can ensure they are all bug free. Or at least agree with the real silicon.


Sign In or Register to comment.