Is there interest in a Spin to P2 PASM compiler?
ersmith
Posts: 5,914
in Propeller 2
I have a Spin to PASM compiler that's working for the Propeller. Is there interest in having this working on Propeller 2? And by "interest" I don't mean "yes, that sounds like something cool", I mean more like "yes, I would actually use that" or even better "yes, I would contribute to that". The P2 world already has TAZ C, but that doesn't seem to have taken off. What are the requirements for a compiler to actually be used on P2? Or is PASM more than sufficient for the current P2 work?
Comments
Why bother with Spin byte codes when you can have go faster native instructions? Which I understand COGs can now execute without an LMM loop. So yeah "...that sounds like something cool".
On the other hand 32 bit wide instructions take up more space than byte codes. But hey, the P2 has 16 times more space.
What is TAZ C? Never heard of it.
A Spin compiler for the P2 would be nice. However, I would really prefer to see the Gnu C compiler for the P2.
PASM is ok for early & lowest level pin-driver testing, but very soon Ken & Chip are going to want some serious Test Code Coverage, and Spin-P2 seems a very good way to get a wide range of upper level ('known good'?) code running on P2, to exercise things.
I'm guessing Spin-P2 is less work than Gnu C P2 ? - but both will exist eventually.
For sure though, spin will be a sizeable part of P2 just as in P1. It is so much easier if speed and specific timing is not required.
Having said that, a Spin to P2 PASM that does a half reasonable job would be quite useful, both for newbies to learn PASM, and for others to translate a working spin program into PASM for speed gains. Could have used a P1 version years ago. I will be looking at the P1 version later to convert Kyes SDFAT and his ASCII string converters.
It is also likely to be of more use in P2 since we have 2x cog program space as well as hubexec.
If so, yes I would use it.
I am very impressed by your current work with spin to c or PASM.
And as @Heater. pointed out the code space in the P2 and the hubexec makes it a perfect target for SPIN(P1) to PASM(P2).
As far as I followed your progress, you said to me that you are even able to break the 32K barrier for SPIN on the P1 by converting to C and then compiling with PropGCC to use the external memory.
So you created BIGSPIN and nobody even react on this.
Without external memory your SPIN to PASM(P1) conversion is a bit of a riddle to me. I guess you use LMM for that so execution speed is better than SPIN, but the code size quadruples.
But like PropBasic this is a very nice tool to produce fast running PASM(P1) code.
On the P2 this is even more interesting. Just imagine having all (or most) of the OBEX available on a P2 converted to PASM(P2) just by recompiling. IMHO this would be really great. Even if it would just use digital I/O and not analog, thus just using stuff available on the P1.
Sure it does not really make sense to use FullDuplexSerial.spin bitbanging on a P2 having serial on the smart pins now, but for converting existing projects or just using existing objects until 'native P2' replacements are written a brilliant way to migrate things from P1 to P2.
On the other hand Dave has a point too. If a future PropGCC(P2) is able to compile your created C source, your PASM generator may be obsolete later on.
But me, myself and I have never liked C/C++, programming COBOL formed some of my mindset and, well...
So my options to program a P2 (If I would get a FPGA) are by now PASM(P2). Because sadly I do also have problems with FORTH. I love the idea and implementation of it, but - hmm - can't program in it.
tl;dr;
YES, I would absolutely love the idea to be able to produce PASM(P2) out of SPIN(P1).
Enjoy!
Mike
Dave: Working on PropGCC is, well, work. I'm sure at some point someone (perhaps Parallax) will sponsor a port of PropGCC to the new P2, but it's probably too early for that. We all remember what happened to the last P2 PropGCC port
jmg: Good point about the code coverage work. It would make sense to have high level languages available for testing, although between Taz and Tachyon Forth we already have some coverage.
All: thanks for the encouragement.
Thanks,
Eric
I even managed to build it here for 64 bit Debian when you announced it back in December. It promptly slipped from my mind.
Now if only I had a P2 ...
FPGA is too expensive.
I wonder... how many P1s do I need to emulate a P2?
Too expensive for playing with no end goal in mind.
Agreed. My only use is playing with PropWare. Which, in turn, means the P2 is simply an exciting curiosity until PropGCC is available. Which is probably a good thing because I have a lot of work remaining on the P1 version of PropWare.
As far as I know this is the latest :
http://forums.parallax.com/discussion/144199/propeller-ii-emulation-of-the-p2-on-fpga-boards-prop123-a7-a9-de0-nano-de2-115-etc/p1
v7 is the latest available for the nano. There are 2 JIC files in it, i think one is for the bare DE0 and the other for the DE0 with parallax breakout. However I'm not 100% sure on it
http://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-8-feb-2016-smart-pins-v7
From the first post in that thread you get 1 cog, 8 smart pins, and 32kB hub
there are 2 subsequent "intermediate releases", 7X and 7Y, but I don't think they include nano compiles
The latest version of spinsim is compatible with the November 25th FPGA. It doesn't support any of the smart pin instructions. I think that the instructions that are supported haven't changed with the latest FPGA images, so it should probably work with binaries generated by the latest version of PNut.
I've thought about the P2 spin2pasm question some more, and I agree that it would be useful to have a Spin compiler that generates P2 assembly. I'm slowly losing interest in the P2 chip development, and I think one of the reasons is the lack of a high level compiler for the P2. My experiment with Taz C was an attempt to create a high level language tool for the P2. I think a P2 spin2pasm utility would be a very useful tool to have, and may get more people involved in working with the P2 FPGA.