programming the P2
msrobots
Posts: 3,709
in Propeller 2
Finally the instruction set is settling down.
What is the current state of development tools and how current are they?
Is there some simulator/debugger usable for people like me not having a FPGA?
@chip stated that he wants to work on spin2 again, soon, but what is with propgcc?
Following other threads here gcc for p1 is somehow stale and is not as easy to even compile with current gcc versions, is there any plan yet to get gcc working for p2 and updated for p1?
It would be nice to have some links to available tools.
Mike
What is the current state of development tools and how current are they?
Is there some simulator/debugger usable for people like me not having a FPGA?
@chip stated that he wants to work on spin2 again, soon, but what is with propgcc?
Following other threads here gcc for p1 is somehow stale and is not as easy to even compile with current gcc versions, is there any plan yet to get gcc working for p2 and updated for p1?
It would be nice to have some links to available tools.
Mike
Comments
Things seem to have fallen into disrepair in that department for the P1 judging by the difficulty people report here in getting it to work.
I cobbled together some P2 C development tools, and posted that in the thread "Can't Wait for propgcc on the P2". The tools consists of a utility that converts P1 assembly to P2 assembly, along with a P2 assembler, linker and loader. This is all integrated together with a script file called p2gcc. You can compile and simulate a program by typing "p2gcc -s test.c". Just like with Spinsim, the last update was in July, and the next update won't happen until the P2 design is stable.
Why?
Because not many people are going to want to deal with hundreds of strange instructions the P2 has sprouted (What is the instruction set size now?). So they won't be able to get the best out of the device without C support for all it's features. Intrinsics, macros, function libraries, whatever.
Because not many people are going to be keen on using Spin. As simple as it is.
There is of course an ocean of people ready to try C on a new device.
What'll be interesting is just how few of those instructions a C compiler will use. In hand-crafted library code there will certainly be the opportunity but in compiler generated code? If you look at chips that were designed to be 'compiler friendly' it's quite interesting how many instructions never get used in 99% of the generated code.
Have Parallax indicated how committed they are to producing a decent supported C compiler for the P2? Something that'll stand up to industrial usage.
We would like that, of course, but don't have the resources to make it happen right now.
The whole idea of the RISC architecture was to only implement those few instructions that the compiler does generate. And to use the available transistors to optimize those rather than implement a load of junk a compiler never generates.
That spawned such things as MIPS, PowerPC, Alpha and the original ARM.
The epitome of this today is the RISC-V specification. The base specification of which really is cut down to those instructions compilers use a lot.
Of course there then comes a lot of instructions that we really hope you are not executing a lot but are required for other reasons. For example instructions to do atomic read/write operations or processor context switches, or fiddle with virtual memory, etc, etc.
I think you are right. A C compiler will not use 90% of P2 instructions. Except when you twist its arm with intrinsics, inline assembler, etc...
After that, RISC finally came along, reflecting what compilers really used, not what hardware people thought they would need.
Then came compiler technology, which could not, and still cannot, sensibly make use of those complex instructions.
Legend has it that the seeds of the RISC idea came from a guy at IBM who decided to build a compiler using only a simple subset of the available mainframes instructions. Lo, it was faster than others that tried to use everything. Sorry I don't have a link to that story.
This history repeated itself with the Intel 8080, then 8086, with the Z80 along the way. An ever growing "Ridiculous Instruction Set Computer"
Funny you should mention your emulator story. When I created my 8080 emulator for the Propeller I decided to enhance it to be a Z80. I did the same thing, add instructions one by one until all the Z80 software I have runs. The result is that to this day ZiCog does not implement a huge chunk of the Z80 instruction set. (At least not in the CP/M OS or it's software that I am interested in)
https://github.com/xoreaxeaxeax/movfuscator
So currently there is PNUT, working for FPGAs, doing assembler but no spin yet.
Then we have @David Betz effort - very nice - to run from command line, something PNUT is missing. It is not GCC but does compile PASM2 and C. SpinSim is cool by itself, because one does not need a actual P2. Cool is a understatement, this could evolve to something like GEARS.
Please, David keep working on it, we all will need this when P2 appears in silicon.
Then we have TAQOZ, a big step for a mainstream programmer but swallowed in small portions quite usable.
It is understandable that Parallax is running out of resources near the finishing line - every runner does -, production is a major investment. My guess is that @Ken wants to smile and cry at the same moment. Over the last years he did a marvelous job to reposition Parallax again in the education market, and Blockly will need a working C environment on the P2.
@Jmg did some testing with FASMG to make a top class macro-assembler usable, it seems to be possible but is not really portable since FASMG is written in pure assembler by itself.
@Ale is working on Project Oberon. Something fitting quite well in the educational market space.
@Heater will break his absence from writing emulators and will write another one again, because CP/M on a P2 is impossible.
And @Phil will show us wonders what to do with the smart pins, like he did with the P1, finding interesting use cases.
But all of us will need some common build environment. In opposite to the P1 we should make sure that the PropellerTool does use OpenSpin to compile and use the same loader like SimpleIDE and PropellerIDE (also another loader). All of what is not the case now.
Tachyon needs BST, OpenSpin has define, the proptool does not, its hilarious.
We should avoid that with the P2.
Build ONE Parallax 'owned' multistage(?) loader, usable on all supported platforms.
Define some Parallax 'owned' standard for linking and loading to be able to load cog images first and then the complete hub.
As far as I understand one is now able to start a cog without loading it again. First load for configuration, next run for action.
Since there is no SPIN in ROM (but TAQOZ) we will need to load the appropriate SPIN interpreter for each program, and I guess the number of different SPIN interpreters will grow fast.
I see a nightmare coming up here if we do not start from right now on to standardize some stuff before other tools get developed.
Because TAQOZ, a C program a SPIN program and some PASM cogs could coexist nicely on one Prop if they had a common linker/loader.
Another wormhole is the inter process communication.
Mike
That was a long time ago.... I'm not sure I have the enthusiasm to pick it up again. So many other interesting things have come along in the meantime.
Still, would probably be the only way we will get a C compiler actually compiling code on the P2 itself. As it was with the P1... could be tempted...
So how could I support this and tempt @Heater.? - Hmm - PASM2 language server for VS code?
CP/M (or MP/M) would fit nicely on a P2 and I even found a COBOL for CP/M on Z80.
Using some P1 as Terminals with VGA and Keyboard over serial and there is a complete propeller Network
No Windows Update, no Linux initd vs whatever. Stable and self containing.
Might be more doable as a 68000 emulator and LISA.
Enjoy!
Mike
I'll leave the 68000 emulator for someone more crazy than me.
Hmm...reminds me. I have a pair of 68000 chips stashed away.... They need something to provide RAM, video and other peripherals....
Of course, Taz C is not full C, but it is a subset of C. It was meant to be an intermediate language that adheres to the syntax rules of C. Some day I hope to create a full C compiler by modifying CSPIN to convert full C to Taz C. The eventual goal would be port all this to run directly on the P2.
ups. So Please Dave, keep up with this nice work!
Mike
Oh, that's a bit of a show stopper.
Chip is finalizing the silicone and his SPIN2 interpreter is work in progress, but delayed.
Dave - I hope I get this right this time - is compiling SPIN and his own SPIN2 to native code, not byte code.
I really like his syntax for returning multiple values from a function call and there was a long discussion about object and/or function pointers to allow a way to switch say formatted output from serial to tv for example.
Where is this right now and is there a way to test this out without having a P2 or a FPGA?
curious,
Mike
spin2gui is a Spin to native code compiler that works for both P1 and P2. It has many of the proposed Spin2 features, including multiple value return/assignment, method pointers, and ternary and other operators.
If you don't have a P2, you can still use it on P1 (you'll have to go to the "Configure Commands..." menu and select "P1 defaults"). Or, you can compile to P2 and use Dave Hein's spinsim to simulate it; that's probably possible with the right "Configure Commands..." settings and using spinsim in place of loadp2, but I haven't actually tried it.
Eric
I think you meant "silicon". Although cyberpunk genre silicon implants would be pretty cool.
I managed a company filled with people who had done and or have had things like that. They mold the parts to be implanted. That's how I got to know them. Did engineering work and some training many years ago now. All that is surprisingly technical and demanding.
Making truly biocompatable things is not easy.
One guy did little horns! He got those removed because it was just too much. The most popular seem to be symbold under the skin, and muscle augmentations, textures and similar.
They do those without any anesthetics. Having those required a medical license. So, they use basics available to anyone, suck it up, and get it done!
Super intense experiences. I can't even imagine.
From the stories and perspective they shared, they crave that painful expression. Like deep meaning and pain mean something, or solidify ideas, experiences in ways they fine worth it.
Yes, some of them are surprisingly cool. That kind of thing isn't for me, but I enjoyed those people and their frank, open nature. I expected something different. They asked me why. I didn't know. Laughs all around, because I an a total square.
End sidebar.