Shop OBEX P1 Docs P2 Docs Learn Events
P2 final release date ? — Parallax Forums

P2 final release date ?

Hi all again !!
Any ideas when will be P2 available, chips and IDE ?
«1

Comments

  • Latest news is that the next version Engineering Sample (ES) will arrive end of July (https://forums.parallax.com/discussion/comment/1468519/#Comment_1468519).
  • evanhevanh Posts: 15,091
    Chipmas is pretty certain this year. :)

    To be honest, you're still a little early. There is second prototypes due out any day now. They'll need to be tested for flaws before any further decisions are made.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    To be honest, you're still a little early. There is second prototypes due out any day now. They'll need to be tested for flaws before any further decisions are made.
    Chip has gone a little quiet, the parts must be taped out about now ? & IIRC the fab delay pipeline was a little longer this time. (maybe that's including the proper packages)

  • Thank you for the info guys !!
  • cgraceycgracey Posts: 14,131
    edited 2019-05-14 21:31
    We will have 2,400 production chips in late August. Hopefully, there won't be any problems with them.

    I've been quietly working on the Spin2 compiler. It's been very challenging, as there are so many darn details to pick up, again. The main file is almost 12,000 lines of 80386 code. I'm really looking forward to rewriting the compiler in Spin2, itself. It's very hard to deal with everything in x86, with the need to make labels and conditional branches, where an IF statement would have been so much more succinct. Also keeping track of what registers hold what in recursive code is tedious.

    I've just about got the compiler and interpreter ready to test together. As I go through this process, every detail gets revisited and rehashed, which has been really good. We've got a really nice method pointer system worked out, of late. Spin2 will compile to be very small and the interpreter is just over 3KB.
  • cgracey wrote: »
    We will have 2,400 production chips in late August. Hopefully, there won't be any problems with them.

    I've been quietly working on the Spin2 compiler. It's been very challenging, as there are so many darn details to pick up, again. The main file is almost 12,000 lines of 80386 code. I'm really looking forward to rewriting the compiler in Spin2, itself. It's very hard to deal with everything in x86, with the need to make labels and conditional branches, where an IF statement would have been so much more succinct. Also keeping track of what registers hold what in recursive code is tedious.

    I've just about got the compiler and interpreter ready to test together. As I go through this process, every detail gets revisited and rehashed, which has been really good. We've got a really nice method pointer system worked out, of late. Spin2 will compile to be very small and the interpreter is just over 3KB.

    Great to hear. Thanks for the update Chip :-)
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    ... The main file is almost 12,000 lines of 80386 code. I'm really looking forward to rewriting the compiler in Spin2, itself. It's very hard to deal with everything in x86, with the need to make labels and conditional branches, where an IF statement would have been so much more succinct. Also keeping track of what registers hold what in recursive code is tedious....
    Surely you are not coding this in 80386 Assembler ? (in 2019..)

  • yes he does
  • Just wondering Chip, maybe just a small(?) SPIN2 interpreter/emulator could be written in x86 code etc, and the compiler could then be done in SPIN2 from the start? Could that be faster or easier to develop I wonder, and would any performance limitations of compiling SPIN2 inside the emulator running on a fast PC be significant enough to preclude this?

    This is somewhat of a chicken-egg problem I guess, if both things are being developed at the same time.
  • jmgjmg Posts: 15,140
    rogloh wrote: »
    Just wondering Chip, maybe just a small(?) SPIN2 interpreter/emulator could be written in x86 code etc, and the compiler could then be done in SPIN2 from the start? Could that be faster or easier to develop I wonder, and would any performance limitations of compiling SPIN2 inside the emulator running on a fast PC be significant enough to preclude this?

    This is somewhat of a chicken-egg problem I guess, if both things are being developed at the same time.

    Yes, chicken and egg, but plenty of better pathways than massive 80386 assembler project :)
    Another approach would be to craft just a P2-emulator in 80386 assembler, able to manage file IO, and use the already existing P2 Spin2 compiler by ersmith,
    I believe AVR Studio, uses a simulator engine built straight from their Verilog via verilog to C, and that has appeal, as you get a warts-and-all simulator.


    I think a PC emulated P2 would 1M code ceiling, and 32b Data pointers ?
  • cgraceycgracey Posts: 14,131
    edited 2019-05-14 23:48
    The only place where Spin2 has less than 32-bit addressing is in the method-pointer scheme, where pbase is 20 bits and the method index is 12 bits (vbase is 32 bits), in order to pack the pointer into two longs, as opposed to three. Three longs would just be odd.

    Yes, a very small x86 interpreter could be written with file I/O, so that work could proceed on the PC. However, there is this chicken-and-egg problem of where the initial compilation comes from. I'm almost there using this approach. I don't think Eric's Spin2 compiler would solve this problem because, at this point, there are a few degrees of difference between what we are working on and my aporoach is yet somewhat experimental. I need to develop it further and run it on the chip to see what needs tuning.
  • cgraceycgracey Posts: 14,131
    This 80386 code base began with the BASIC Stamp in 1992. It's 27 years old! It could be easily recreated in another language, but what I have works, I know where everything is, or can figure it out.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    The only place where Spin2 has less than 32-bit addressing is in the method-pointer scheme, where pbase is 20 bits and the method index is 12 bits (vbase is 32 bits), in order to pack the pointer into two longs, as opposed to three. Three longs would just be odd.

    Yes, a very small x86 interpreter could be written with file I/O, so that work could proceed on the PC. However, there is this chicken-and-egg problem of where the initial compilation comes from. I'm almost there using this approach. I don't think Eric's Spin2 compiler would solve this problem because, at this point, there are a few degrees of difference between what we are working on and my aporoach is yet somewhat experimental. I need to develop it further and run it on the chip to see what needs tuning.

    I can understand there would be experimental differences at code-generate level, and interpreter byte code levels, but (hopefully?) the Spin2 High Level Language needed to read and parse files, is now-stable level ?
    An alternate chicken-and-egg solution would be a Spin2 to Python translator, which needs to only work on a subset code-cross-set good enough to read and parse files.
    Or ersmith may even have a C back end to allows Spin2 to create code that on PCs ?
    I know his Basic is deliberately quite close to PC FreeBASIC to allow easy hop to/from PC development.
    Usually useful for algorithm tuning and testing, but no reason not to apply it to a whole compiler design.
  • I am a big fan of @ersmith , but asking him to also provide a bytecode output might even stretch his time too much.

    He got his P2 shortly after I got mine and while I was barely finishing a serial driver he did a whole compiler collection, a IDE, a RISKV emulator, ported MircoPhython and who knows what else he has coming for us.

    There are barely ~100 P2 out in the world and we have forth, basic, spin, pasm, 3 different C approaches a P1 emulator in work, a Z80 emulator in work and I am quite sure somebody will tackle the 6502.

    And all of this is done before the first production run, the gestation of the P2 took 10 years and the ecosystem around the chip is exploding faster then I can download it. Literally. Every time if find a weekend to grasp at straws and learn to program the beast, I download the newest version of spin2gui/fastspin because I am already outdated.

    Now @RossH comes back, full swinging. Catalina for the P2. Just wonderful.

    Yes 80386 sounds crazy, but chip just loves assembler, I guess. Nothing wrong with that, I do not need to tell that to @jmg, he knows more about FASM then I do.

    And @"Roy Eltham" ported chips asm once before, since chip is evolving his old codebase Roy will be able to do that again and said he is willing to do so. Just wonderful again.

    And there is @"Peter Jakacki" and his P2D2. A module like this, mass fabricated could bring the cost down and can be plugged into own creations without hassle.

    Enjoy!

    Mike
  • jmgjmg Posts: 15,140
    msrobots wrote: »
    And all of this is done before the first production run, the gestation of the P2 took 10 years and the ecosystem around the chip is exploding faster then I can download it. Literally. Every time if find a weekend to grasp at straws and learn to program the beast, I download the newest version of spin2gui/fastspin because I am already outdated.

    Yes, progress is certainly quite impressive :)

  • rogloh wrote: »
    Just wondering Chip, maybe just a small(?) SPIN2 interpreter/emulator could be written in x86 code etc, and the compiler could then be done in SPIN2 from the start? Could that be faster or easier to develop I wonder, and would any performance limitations of compiling SPIN2 inside the emulator running on a fast PC be significant enough to preclude this?

    This is somewhat of a chicken-egg problem I guess, if both things are being developed at the same time.

    There's already a Spin2 compiler for the P2, albeit one that produces native code rather than bytecode. fastspin handles most of Spin2, surely enough to write a compiler in.

    @cgracey , you could bootstrap your bytecode compiler in Spin2 in one of two ways:

    (1) Write it in the fastspin dialect of Spin2 (Spin1 with some Spin2 extensions) and compile it with fastspin to run on P2. Then you can run your source code through that to produce bytecodes.

    (2) Alternatively, you could use spin2cpp to convert your Spin2 source to C and compile that on a PC to produce bytecodes there.
  • jmg wrote: »
    Yes, chicken and egg, but plenty of better pathways than massive 80386 assembler project :)
    Another approach would be to craft just a P2-emulator in 80386 assembler, able to manage file IO, and use the already existing P2 Spin2 compiler by ersmith,
    You wouldn't even need to do that, you could use spin2cpp (which is a different interface to the fastspin engine) to convert the Spin2 code to C code and then compile it on the PC. You'd have to provide some file IO stubs in C, but that would be pretty simple.

    Or, you could just run on a P2 from the beginning and skip the PC step entirely (well, you'd be using fastspin on the PC to compile the initial Spin code, but then run that directly on the P2 rather than using a PC emulator).
  • cgracey wrote: »
    Yes, a very small x86 interpreter could be written with file I/O, so that work could proceed on the PC. However, there is this chicken-and-egg problem of where the initial compilation comes from. I'm almost there using this approach. I don't think Eric's Spin2 compiler would solve this problem because, at this point, there are a few degrees of difference between what we are working on and my aporoach is yet somewhat experimental. I need to develop it further and run it on the chip to see what needs tuning.

    Certainly our approaches are quite different, but as long as the language is the same (or similar enough; the Spin2 compiler doesn't have to use all Spin2 features :)) then surely you could compile your compiler with mine to bootstrap it? Once that's done you wouldn't need fastspin any more.

  • RaymanRayman Posts: 13,767
    Interesting topic...
    I think the dream has always been for a self-hoster editor and compiler.
    We can now compiler on p1 but not really edit, right?

    P2 puts us in pi category I think...

    SOC is one thing but one that can program itself is one step up..
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    jmg wrote: »
    Yes, chicken and egg, but plenty of better pathways than massive 80386 assembler project :)
    Another approach would be to craft just a P2-emulator in 80386 assembler, able to manage file IO, and use the already existing P2 Spin2 compiler by ersmith,
    You wouldn't even need to do that, you could use spin2cpp (which is a different interface to the fastspin engine) to convert the Spin2 code to C code and then compile it on the PC. You'd have to provide some file IO stubs in C, but that would be pretty simple.

    Cool, I thought such a via-C pathway should exist.
    ersmith wrote: »
    Or, you could just run on a P2 from the beginning and skip the PC step entirely (well, you'd be using fastspin on the PC to compile the initial Spin code, but then run that directly on the P2 rather than using a PC emulator).
    :) I had not thought of that, but at some stage, you will need PC-MPU binaries ?
    If that produced Spin2 interpreter bytecodes, then you avoid needing a P2-emulator, and can get by with a PC-Hosted Spin2 Bytecode engine, PC-Side.
    That'll be slower than a native compiler, but it might be good enough ?
  • Could you make a version of the the 80386 assembler that targets the x86 (x86 assembly in DAT blocks, interpreter written in x86) instead of the P2 so you can make the version of the Spin2 compiler that's written in Spin2 able to run natively on the x86?
  • RaymanRayman Posts: 13,767
    Could the Spin2 interpreter be made to run multiple Spin2 threads in one cog?
  • Rayman wrote: »
    Could the Spin2 interpreter be made to run multiple Spin2 threads in one cog?

    At what level of task-switching granularity? It couldn't be per opcode, because that would cause tons of FIFO reloads, defeating the purpose of the FIFO and XBYTE.

    Will coroutines be supported to allow threads that only manually yield?
  • RaymanRayman Posts: 13,767
    Way back when, the P2 had this task switching mechanism...
    I think the idea was that one P2 cog could execute about same speed as 4 P1 cogs.

    I don't know if this really makes sense or not, just wondering...
  • cgraceycgracey Posts: 14,131
    ersmith wrote: »
    rogloh wrote: »
    Just wondering Chip, maybe just a small(?) SPIN2 interpreter/emulator could be written in x86 code etc, and the compiler could then be done in SPIN2 from the start? Could that be faster or easier to develop I wonder, and would any performance limitations of compiling SPIN2 inside the emulator running on a fast PC be significant enough to preclude this?

    This is somewhat of a chicken-egg problem I guess, if both things are being developed at the same time.

    There's already a Spin2 compiler for the P2, albeit one that produces native code rather than bytecode. fastspin handles most of Spin2, surely enough to write a compiler in.

    @cgracey , you could bootstrap your bytecode compiler in Spin2 in one of two ways:

    (1) Write it in the fastspin dialect of Spin2 (Spin1 with some Spin2 extensions) and compile it with fastspin to run on P2. Then you can run your source code through that to produce bytecodes.

    (2) Alternatively, you could use spin2cpp to convert your Spin2 source to C and compile that on a PC to produce bytecodes there.

    Eric, I don't know where I'm going, exactly. As I get things working, new ideas come up that I implement. The bytecode arrangement will be undergoing some metamorphosis along the way, I'm sure. I don't see any other way to get there than the path that I'm already on. There will be lots of tweaking. In the end, I think the whole development system could run on the P2, including an editor, compiler, and debugger, in under 32KB, maybe even half that.
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Interesting topic...
    I think the dream has always been for a self-hoster editor and compiler.
    We can now compiler on p1 but not really edit, right?

    P2 puts us in pi category I think...

    SOC is one thing but one that can program itself is one step up..

    Not only self-hosting, but storing the source code, as well. You could hook into it twenty years from now and make source-level adjustments without needing any development tools on a host system. This would be important for machinery.
  • cgraceycgracey Posts: 14,131
    Could you make a version of the the 80386 assembler that targets the x86 (x86 assembly in DAT blocks, interpreter written in x86) instead of the P2 so you can make the version of the Spin2 compiler that's written in Spin2 able to run natively on the x86?

    Sure! That would be possible.
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Could the Spin2 interpreter be made to run multiple Spin2 threads in one cog?

    I never thought much about this. I suppose you could use a timer interrupt as a task switcher, where you switch among contexts on each interrupt, never minding about bytecode function boundaries.
  • cgracey wrote: »
    Eric, I don't know where I'm going, exactly. As I get things working, new ideas come up that I implement. The bytecode arrangement will be undergoing some metamorphosis along the way, I'm sure. I don't see any other way to get there than the path that I'm already on. There will be lots of tweaking. In the end, I think the whole development system could run on the P2, including an editor, compiler, and debugger, in under 32KB, maybe even half that.

    I guess I haven't explained my proposal very well, then. What I'm saying is that you could write a simple version of the Spin2 to bytecode compiler in a subset of Spin2. Call that PNut_1.spin2. You'd then compile PNut_1.spin2 with fastspin to get a P2 binary, PNut_1.binary. Now you'd run PNut_1.binary on the P2 and feed it the PNut_1.spin2 source file to get a PNut_1.bytecode file. This could then be interpreted with version 1 of the Spin2 interpreter, again on the P2.

    At this point you're done with fastspin (you could throw it away) and you have a self-hosted system. Now you continue to improve Spin2 with that system, e.g. you may think of some feature you'd like to add to create PNut_2.spin2, which you'd compile with PNut_1.bytecode to create PNut_2.bytecode. Iterate as necessary.

    The big advantages are (1) you're "eating your own dogfood" early in the process, and (2) you don't need to write 80386 assembly code.

    If you're planning on re-writing the compiler in Spin anyway, why not start with Spin from the beginning?

    You don't need to have all the features working and finalized to get your first PNut_1 compiler running on P2, just enough so that it can compile itself. From that point on everything is independent.

    Does this make sense?

    Eric
  • Now I have to tease you @ersmith, but theoretically you could go the same way and compiling fastspin with fastspin to get a P2 binary, right?

    Or even more worse, using gcc for riscv! Maybe Catalina?

    I am a bit 'more than happy' because I got a mail today from the DHS that finally my new green card will be produced and send to me, I can stay state side and do not need to sell my house and move back to Germany.

    Life is good again.

    That self hosting thing was what finally draw me to the Propeller, I could blame @mpark for my addiction, but fact is that the Propeller brought back fun into my boring life as a code monkey.

    Anyways,

    Enjoy!

    Mike
Sign In or Register to comment.