programming the P2

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
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.

Comments

  • 24 Comments sorted by Date Added Votes
  • The instruction set has been settling down for several years. There have been numerous pronouncements that it was frozen but it tends to thaw again. We'll see if it stays frozen this time. :-)
  • I do hope prop-gcc gets some love and attention. And or Clang/LLVM. And of course SimpleIDE.

    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.
  • David BetzDavid Betz Posts: 11,683
    edited January 1 Vote Up0Vote Down
    Heater. wrote: »
    I do hope prop-gcc gets some love and attention. And or Clang/LLVM. And of course SimpleIDE.

    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 don't think there is any budget for propgcc development. Also, some work was done many years ago beyond what is currently in production and there has never been resources to integrate it.
  • Spinsim supports most of the P2 instruction set, but I haven't worked on it since July. Spinsim has some simple debugging functions, so it does provide the basic features of a simulator and debugger. I may update Spinsim in a month or so if there are no more changes to the architecture for a few weeks.

    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.
  • I think C/C++ is vital for the P2. Far more so than the P1 now that we have a decent memory space available.

    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.

  • Heater. wrote: »
    I think C/C++ is vital for the P2. Far more so than the P1 now that we have a decent memory space available.

    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.
    Yup, we should have C/C++ at launch if possible. At least we already have Dave Hein's P1->P2 translator as a start. I still think it would be good to find a LLVM expert who is interested in building a code generator for the P2.
  • Heater. wrote: »
    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.

    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.
  • Heater. wrote: »
    I think C/C++ is vital for the P2. Far more so than the P1 now that we have a decent memory space available.

    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.
  • Heater. wrote: »
    I think C/C++ is vital for the P2. Far more so than the P1 now that we have a decent memory space available.

    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.
  • Brian,
    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.
    Don't you have that backwards?

    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...










  • But before RISC, designers tried to create "compiler-friendly" CISC processors. For those the reality was that most of the fancy instructions weren't used. I implemented two emulators for such processors, and what I did was to use real applications, including compilers compiled by compilers, and implement instructions one by one as my test run found a new missing instruction. Until it all worked. And the fancy instructions weren't used. I remember using them in my hand-crafted assembly back when I used real hardware, but as my emulation work made me realize, compilers didn't. One of the architectures kept adding new instructions over the years, specifically for encoding operations that compilers used (e.g. allocating stack frames). But the new versions of the compilers, written by the same company, didn't use them.
    After that, RISC finally came along, reflecting what compilers really used, not what hardware people thought they would need.
  • I think the problem, back in the day, was that computers were designed by the electronics guys. Meanwhile the programmers used assembler. So of course the programmers asked for ever more complex instructions to make their life easier.

    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)








  • Speaking of the "Ridiculous Instruction Set Computer", did you know that there is a C compiler that generates only x86 MOV instructions? Yep, every instruction in the executable is a move.

    https://github.com/xoreaxeaxeax/movfuscator




  • Ah, yeah, the MOV-only compiler.. I ran into that one a while back. It's like one of those single-instruction CPUs, just without having to make one..
  • Makes me want to write an x86 emulator for the Prop that only implements the MOV instruction :)



  • OK, back to OT.

    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. :smile:

    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





    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.
  • Ha! The ZiCog Z80 emulator and CP/M for the Propeller project got put on hold. Waiting for a P2 with sufficient memory space and grunt to put the whole thing on one chip. Including video terminal (VT100 on VGA) and other peripherals.

    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...

  • It is time that the big ZOG awakes again and comes out of the ice. Maybe even @pullmoll will show up again, when ZOG calls him..

    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. :smile:

    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 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.
  • Excellent. C for me. COBOL for you. Everyone is happy :)

    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....

  • David BetzDavid Betz Posts: 11,683
    edited January 2 Vote Up0Vote Down
    msrobots wrote: »
    OK, back to OT.

    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.
    Actually, it's Dave Hein who did this work.

  • Heater. wrote: »
    Ha! The ZiCog Z80 emulator and CP/M for the Propeller project got put on hold. Waiting for a P2 with sufficient memory space and grunt to put the whole thing on one chip. Including video terminal (VT100 on VGA) and other peripherals.

    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...
    I hope to port the Taz C compiler to the P2, so this would be a step toward compiling C code on the P2. The linker that I use with p2gcc is based on the one that Taz C uses, so it should be fairly easy to port this back to Taz C. This would allow Taz C objects to be linked with p2gcc objects that were compiled on a computer.

    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.

  • I wonder if RossH might return and port Catalina to P2?
  • David Betz wrote: »
    msrobots wrote: »
    OK, back to OT.

    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.
    Actually, it's Dave Hein who did this work.

    ups. So Please Dave, keep up with this nice work!

    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.
  • cgracey wrote: »
    Heater. wrote: »
    I think C/C++ is vital for the P2. Far more so than the P1 now that we have a decent memory space available.

    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.


    Oh, that's a bit of a show stopper.
Sign In or Register to comment.