Forum Update - Announcement about May 10th, 2018 update and your password.

P1 Spin for P2

I am thinking about how to make the P1 Spin Interpreter work on P2 with the least number of changes.

This means keeping the 64KB limit (16-bit addressing) and basically just using the compatible PASM instructions, at least for now.

There are a few gotchas...
The need for the lower 16 or so bytes/longs in Hub RAM

I know there will be others. Just cannot think of them atm.

Comments

  • 5 Comments sorted by Date Added Votes
  • Cluso99 wrote: »
    I am thinking about how to make the P1 Spin Interpreter work on P2 with the least number of changes.

    This means keeping the 64KB limit (16-bit addressing) and basically just using the compatible PASM instructions, at least for now.

    There are a few gotchas...
    The need for the lower 16 or so bytes/longs in Hub RAM

    I know there will be others. Just cannot think of them atm.
    Why bother when there is FastSpin available already?

  • Because I think it would be good to be able to run most spin1 programs on the P2. Fastspin, while excellent, doesn't do the same thing. It takes a lot more Hub space which will surely be exhausted soon enough. Some spin programs won't require the speed gain of fastspin. I don't know how long spin2 will be, and how source compatible it will be with P1.

    What would be really nice is PropTool or OpenSpin taking a P1 spin and PASM program and compiling to P2. Not sure how we can combine Fastspin and P2ASM to achieve this. Certainly the grass roots are there.
  • I wrote a P1 Spin bytecode interpreter for the P2 about 3 years ago. The most used bytecodes execute from cog memory, and the lesser used bytecodes run from the hub. I haven't touched the code for a few years, but I got it to assemble with the latest version of PNut and p2asm. The code is in the attached zipfile with a sample P1 Spin program that runs the Dhrystone benchmark. It uses the SimpleSerial object to print at 19200 baud.
  • Cluso99 wrote: »
    Because I think it would be good to be able to run most spin1 programs on the P2. Fastspin, while excellent, doesn't do the same thing. It takes a lot more Hub space which will surely be exhausted soon enough. Some spin programs won't require the speed gain of fastspin. I don't know how long spin2 will be, and how source compatible it will be with P1.
    fastspin compiled programs are only about twice as big as openspin compiled ones. The P2 has 16x the memory of P1, so realistically any P1 sized Spin program can easily be moved over to P2 with fastspin (assuming it compiles, of course... and I do plan to fix any bugs people discover).

    In the long run I agree that having some kind of bytecode interpreter would be a good option. I suspect Chip has something in mind for this.

    Eric
  • msrobotsmsrobots Posts: 1,939
    edited June 2 Vote Up0Vote Down
    @Heater. could write a P1 emulator like he did for the Z80, but it is impossible, because he stated to not write emulators never ever again, or something along that line. :depressed:

    But as @ersmith said, with much more HUB in the P2 any P1program should fit.

    And for the whole 'Blockly Universe' I am quite sure a transition to generating P2 code out of the created C will be done quite fast.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.