Equip your Genius
Welcome to the Parallax Discussion Forums, sign-up to participate.
Learn with BlocklyProp
Repo of Example P2 Code?
2018-10-26 - 22:24:27
Do we have anywhere where known good P2 code is stashed or is it just a case of trawling the forums and trying to pull it together?
I want to exercise my tools and my P2 simulator so looking for things to feed it.
2018-10-26 - 23:35:58
Here is the latest set of FPGA files. Lots of example code here:
2018-10-26 - 23:58:31
Here are some emulators that I ported to P2:
ZOG ZPU emulator:
. The P2 version uses XBYTE so it's a good test of that feature.
The Risc-V emulator actually has two P2 versions, a straightforward interpreter and a JIT compiler that compiles RISC-V to P2 instructions on the fly and uses LUT memory as an instruction cache.
Both of them probably need fastspin to compile -- I think they use (at least) #define and #ifdef that PNut doesn't have.
And of course for making more tests fastspin supports compiling Spin and BASIC to hubexec P2 code, as well as being able to compile P2ASM.
spin2gui (a simple GUI for fastspin):
2018-10-27 - 01:22:02
Wow, that's a good bunch of test code - thanks guys.
So far, of the 260,000 or so distinct instructions, my disassembler fails to match about 8000 of them character by character. So - well on the way to 100% coverage.
My main problem right now is decoding call / jmp / calld etc... sometimes my pointer math just doesn't work - especially when it comes to relative (when I have to cast to a signed integer) calls.
With some commands I have to cast on a 20 bit integer, on others, a 9 bit integer. Some I just don't seem to be able to get right at all.
Once I've got some of the other figured out I'll probably just dig directly into the p2dump source and "cheat" ;-)
That helps me a ton - thanks!
2018-10-27 - 01:26:41
All the instruction bits are in a spreadsheet. Do you not have that?
2018-10-27 - 02:02:43
I do, and I'm working from it.
I'm trying to do a clean implementation to make sure I *understand* everything in a fair amount of detail. I'm confirming my work by having my output be byte-identical to p2dump and then doing diff --side-by-side to validate.
I've since found that some of the opcodes that I've failed to decode are... umm, parts of .bpp images so it's probably not that surprising that when p2dump and I try to decode syntactically "problematic" "opcodes" we get very differing results.
The other thing that occurred to me is that since all of my examples thus far have been very simple, single-cog, copies-from-hub0-to-cog0 type affairs, how does one distinguish between code that's in the hub above 0x400 but destined to be copied into cogram before execution.
In other words, just looking at the bytecode, I guess there's no way of knowing for sure *where* code will actually execute from (I guess in much the same way as you can't determine whether something's actually executable code or an embedded image / data).
More shower^UMore thoughts to ponder.
I may be overthinking it all, it's a life skill.