P2 final release date ?
btxsistemas
Posts: 23
in Propeller 2
Hi all again !!
Any ideas when will be P2 available, chips and IDE ?
Any ideas when will be P2 available, chips and IDE ?
Comments
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.
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 :-)
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 ?
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.
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
Yes, progress is certainly quite impressive
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.
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).
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
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..
Cool, I thought such a via-C pathway should exist.
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 ?
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?
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...
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.
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.
Sure! That would be possible.
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.
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
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