A challenge for PASM enthusiasts!
Wossname
Posts: 174
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!
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
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.
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...
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
You're right. Forgive me. I'm used to doing things in different ways perhaps.
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.
http://forums.parallax.com/discussion/154461/is-there-a-testbench-for-opcodes-instruction-set-exersizer/p1
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.
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.
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.