Seems lately, many in these threads don't like seeing the sausage being made. To those I say, Quade, open your mind!
Ah, yes... Cuato.
It's just not as elegant and clean as we've come to expect of the Propeller.
It's certainly not something that anyone is going to have a compiler take advantage of, but for those who code in PASM, it has value.
I've been dreaming about something like this for a long time. Many times, I'd look at similar code snippets when memory was tight and think that if there was just some way I could mix them together and select which instructions would execute in different cases, I could save lots of memory. The problem was that I kept picturing something like a list of nibbles that would direct the PC, which was not very efficient of an approach. Realizing that a string of bits, that lays right onto the instruction sequence, would do everything needed was kind of a revelation for me. Now I can not only write very compressed code, but it runs as fast as it ever could.
It certainly is clever. In fact, a compiler might be able to make some use of it. We should try to find someone who will work on creating an LLVM backend for P2. I seem to recall that you were looking into LLVM at one point. Are you likely to work on it for P2?
Personally, I think what I've already got on my plate could eat my whole life up, but I hope/suppose/expect that other people are going to be working on C.
Understood. I just asked because I think you expressed some interest a while back when someone pointed to a PDF book describing LLVM. Yes, I imagine it would be good to create a C compiler for P2 if Parallax education is going to continue using C. I'm not sure it's a good idea to dive back into GCC again though when LLVM seems to be taking over. Unfortunately, I don't know enough about LLVM to make much progress. We need to find a new compiler guy. Maybe Roy?
Whoever is interested will probably be the one who does it. Roy could, possibly, and/or Eric Smith. There are others here that could do it, too.
Well this is all way over my head! so I keep quiet.
However if Bean is able to work his magic and provide a P2Propbasic, I will be able to tap into this power as I have done with the Prop1.
Whether he will make use of all this new sophistication I don't know- but high level access to the new smartpins etc etc will be very helpful.
And I for one would be willing to pay for it!
I'd love to see a P2 llvm backend, but I doubt I can be the guy to do it. At least not alone.
I am already committed to getting OpenSpin for P2 done. Perhaps after that is "done" I can look into helping any LLVM effort that may or may not exist.
As for the skip stuff, I love it. Since most of my Prop coding is in PASM, I think of it as a very handy tool for code compression.
I'm not sure it's a good idea to dive back into GCC again though when LLVM seems to be taking over.
Is that a technical judgement or just observation than Clang/LLVM is the new kid on the block?
As far as I can tell GCC has been keeping up with whatever LLVM can do. And currently GCC supports more target architectures.
At the end of the day, I guess it depends on who steps forward with expertise and want's to take on the task.
It just seems like people are moving in the LLVM direction. It isn't a technical judgement since I don't really know much about the details of LLVM. It seems like a good idea to me but with a steep learning curve. I'd love to learn enough about it to target the P2 but it seems doubtful I'd have the time. There must be someone out there who already knows LLVM for whom a new target would be relatively easy.
Once the design is frozen on the P2 I don't see why Parallax can't move full speed ahead on PropGCC for the P2. To be honest, I've always felt that PropGCC should have been implemented for the P2 way before the design is frozen so that any potential problems could be found before the P2 goes into silicon. I understand this would have created a moving target, but the incremental changes wouldn't have been that large in going from one design change to the next. I think this is just as important as the work that Chip is doing on the Spin interpreter, and for the same reasons. Hopefully, Parallax will fund a PropGCC project for the P2 like they did for the P1.
Once the design is frozen on the P2 I don't see why Parallax can't move full speed ahead on PropGCC for the P2. To be honest, I've always felt that PropGCC should have been implemented for the P2 way before the design is frozen so that any potential problems could be found before the P2 goes into silicon. I understand this would have created a moving target, but the incremental changes wouldn't have been that large in going from one design change to the next. I think this is just as important as the work that Chip is doing on the Spin interpreter, and for the same reasons. Hopefully, Parallax will fund a PropGCC project for the P2 like they did for the P1.
GCC would seem to be the path most able to leverage work already done, and one that would soonest see something to test.
There are other P2 compiler paths pretty much waiting on P2-Opcode-Stable flagfall, which is very close to being real now.
I did find this blog, comparing GCC and LLVM on M3's circa 2015 builds.
Once the design is frozen on the P2 I don't see why Parallax can't move full speed ahead on PropGCC for the P2. To be honest, I've always felt that PropGCC should have been implemented for the P2 way before the design is frozen so that any potential problems could be found before the P2 goes into silicon. I understand this would have created a moving target, but the incremental changes wouldn't have been that large in going from one design change to the next. I think this is just as important as the work that Chip is doing on the Spin interpreter, and for the same reasons. Hopefully, Parallax will fund a PropGCC project for the P2 like they did for the P1.
Eric and I did create a port of PropGCC to P2-hot. Then the instruction set started gyrating rapidly and now all of that work is pretty much useless.
For what it's worth, the chance of that happening now is low. A core set, in fact I would argue, 90 percent of instructions, if not more, are a lock.
Wasn't there a call, with register vector instruction needed by GCC and friends? LINK?
Right now would be the time to at least test that with a core set of instructions. Chip will allow the same tweak there as he has to optimize Spin. Is that LINK discussion, had way back then, relevant today? I would question that hard.
Just saying...
Of course, I am just saying, because I'm not capable of the GCC work myself, but I would absolutely test the compiler, or a compiler in the case of FastSpin.
Right now, I'm bringing up some old code from late last year. Had a few things done in PASM. Am doing a redo in anticipation of some high level fun.
Thought the same thing you guys did. It started to shake up, and knowing Chip, knew one more solid pass was gonna happen. Life got in the way there for a bit, so now here I am.
I don't see another major shake up at this point. Maybe an addition or two. And that again can go for C and friends as much as it has SPIN. Why not?
This is one of those, "make it worth it" times, put simply.
Eric and I did create a port of PropGCC to P2-hot. Then the instruction set started gyrating rapidly and now all of that work is pretty much useless.
I'm not sure all the work is pretty much useless.
Work setting up Assembler for example, needs new opcode mappings, but that is more editing that new code work.
Code generators need mnemonic editing, and maybe some replacements, for any no-longer-exists cases.
I think CALLD disappeared briefly during the project reboot period but was reinstated quite early on.
Spud, Oi! 90%! Talk about round numbers! Chip's a lot further on that that, even if only considering the instructions. Now would be a great time to resurrect PropGCC, imho.
I'd mark the hardware stack for removal except it's so small already it hardly matters.
I think CALLD disappeared briefly during the project reboot period but was reinstated quite early on.
Spud, Oi! 90%! Talk about round numbers! Chip's a lot further on that that, even if only considering the instructions. Now would be a great time to resurrect PropGCC, imho.
I'd mark the hardware stack for removal except it's so small already it hardly matters.
It's more like 99%. Even that would allow for almost four instruction changes. There may be zero.
And that hardware stack is perfect for cog-sized programs.
Eric and I did create a port of PropGCC to P2-hot. Then the instruction set started gyrating rapidly and now all of that work is pretty much useless.
I'm not sure all the work is pretty much useless.
Work setting up Assembler for example, needs new opcode mappings, but that is more editing that new code work.
Code generators need mnemonic editing, and maybe some replacements, for any no-longer-exists cases.
If you recall, P2-hot did not have hub exec so lots of stuff will be different. There is no LMM anymore for example and less of a difference between COG mode and HUB mode execution. There are also relative branches. I don't think P2-hot had those. My guess is that GCC will not use the small hardware stack except maybe in some of it's low-level library code.
It was. I was working on some stuff with baggers. Big changes happened, our C code got invalidated, we started on PASM, and then we found out it was 5 watts!
It was. I was working on some stuff with baggers. Big changes happened, our C code got invalidated, we started on PASM, and then we found out it was 5 watts!
Well, the initial P2 GCC work was done before there was hub exec. It contains both an LMM and a CMM kernel to allow programs larger than would fit in COG memory. We didn't even have LUT exec at that time. PropGCC for P2 hasn't worked for a very long time because of changes in the design. That is okay of course. We want a better design and hub exec was a big step forward for high-level language implementation. It's just that PropGCC work pretty much stopped when things started changing rapidly and hasn't ever been restarted. Now Parallax's emphasis is on Chip's Spin interpreter and Roy's translation of it into C++. I guess C will come after that on their priority list. That isn't to say someone couldn't start working earlier on a volunteer basis but I don't think Parallax will get behind a C effort until after Spin is solidly in place.
Well, the initial P2 GCC work was done before there was hub exec. It contains both an LMM and a CMM kernel to allow programs larger than would fit in COG memory. We didn't even have LUT exec at that time....
but it could produce native cog-sized code ?
Seems even that would be useful, and some soft control of the limit of the ceiling on that, could open HUBEXEC ?
Well, the initial P2 GCC work was done before there was hub exec. It contains both an LMM and a CMM kernel to allow programs larger than would fit in COG memory. We didn't even have LUT exec at that time....
but it could produce native cog-sized code ?
Seems even that would be useful, and some soft control of the limit of the ceiling on that, could open HUBEXEC ?
Yes, it can as long as we update gas with the new instruction set. I started working on that but kind of lost interest after the SKIP discussion. It seems like I'm not very well in tune with the current P2 philosophy.
Yes, it can as long as we update gas with the new instruction set. I started working on that but kind of lost interest after the SKIP discussion. It seems like I'm not very well in tune with the current P2 philosophy.
I can sort of understand that, but SKIP is now looking stable, and had minimal ripple effect, and is not something a first pass GCC would look to use anyway ?
What is the current state of play around in-line-ASM in GCC, for P1 ?
That seemed to be something missing in LLVM pathways.
Yes, it can as long as we update gas with the new instruction set. I started working on that but kind of lost interest after the SKIP discussion. It seems like I'm not very well in tune with the current P2 philosophy.
I can sort of understand that, but SKIP is now looking stable, and had minimal ripple effect, and is not something a first pass GCC would look to use anyway ?
What is the current state of play around in-line-ASM in GCC, for P1 ?
That seemed to be something missing in LLVM pathways.
I think it might be better for those who understand how to make the most out of the unique P2 abilities to do the C backend. Just a simple mapping from how the P1 compiler works is likely to not be acceptable.
PropGCC for P1 supports the standard GCC way of doing inline assembly.
Comments
Whoever is interested will probably be the one who does it. Roy could, possibly, and/or Eric Smith. There are others here that could do it, too.
Well this is all way over my head! so I keep quiet.
However if Bean is able to work his magic and provide a P2Propbasic, I will be able to tap into this power as I have done with the Prop1.
Whether he will make use of all this new sophistication I don't know- but high level access to the new smartpins etc etc will be very helpful.
And I for one would be willing to pay for it!
Dave
I am already committed to getting OpenSpin for P2 done. Perhaps after that is "done" I can look into helping any LLVM effort that may or may not exist.
As for the skip stuff, I love it. Since most of my Prop coding is in PASM, I think of it as a very handy tool for code compression.
As far as I can tell GCC has been keeping up with whatever LLVM can do. And currently GCC supports more target architectures.
At the end of the day, I guess it depends on who steps forward with expertise and want's to take on the task.
I suspect a move to both Arm and somewhat more closely unify Mac OS and iOS.
a) Some kind soul creates a GCC based C/C++ compiler for the P2.
b) Some kind soul creates an LLVM based C/C++ compiler for the P2.
c) Parallax pays for someone to create a C/C++ compiler for the P2.
In case c) Does Parallax dictate the technology to be used?
I can't help thinking that at the end of the day it depends on who is available and willing and what skills they have.
GCC would seem to be the path most able to leverage work already done, and one that would soonest see something to test.
There are other P2 compiler paths pretty much waiting on P2-Opcode-Stable flagfall, which is very close to being real now.
I did find this blog, comparing GCC and LLVM on M3's circa 2015 builds.
http://labapart.com/blogs/3-the-importance-of-the-toolchain-version-in-embedded-space
and I also find this, talking about clang-interleaved-source-and-assembly
http://stackoverflow.com/questions/24603910/clang-interleaved-source-and-assembly
That's a fairly serious drawback, with klunky/partial sounding workarounds as of Aug 2016 ?
Wasn't there a call, with register vector instruction needed by GCC and friends? LINK?
Right now would be the time to at least test that with a core set of instructions. Chip will allow the same tweak there as he has to optimize Spin. Is that LINK discussion, had way back then, relevant today? I would question that hard.
Just saying...
Of course, I am just saying, because I'm not capable of the GCC work myself, but I would absolutely test the compiler, or a compiler in the case of FastSpin.
Right now, I'm bringing up some old code from late last year. Had a few things done in PASM. Am doing a redo in anticipation of some high level fun.
Thought the same thing you guys did. It started to shake up, and knowing Chip, knew one more solid pass was gonna happen. Life got in the way there for a bit, so now here I am.
I don't see another major shake up at this point. Maybe an addition or two. And that again can go for C and friends as much as it has SPIN. Why not?
This is one of those, "make it worth it" times, put simply.
How does the comparatively small HW Stack in P2 affect C Compilers ?
Certainly wins the prize for the smallest stack on a 32b MCU, with 512k Code
I'm not sure all the work is pretty much useless.
Work setting up Assembler for example, needs new opcode mappings, but that is more editing that new code work.
Code generators need mnemonic editing, and maybe some replacements, for any no-longer-exists cases.
Surely SPIN would benefit from that too.
I had to look because I couldn't remember, but there is such an instruction:
CALLD PA/PB/PTRA/PTRB,#A
EEEE 11100WW RAA AAAAAAAAA AAAAAAAAA
Spud, Oi! 90%! Talk about round numbers! Chip's a lot further on that that, even if only considering the instructions. Now would be a great time to resurrect PropGCC, imho.
I'd mark the hardware stack for removal except it's so small already it hardly matters.
It's more like 99%. Even that would allow for almost four instruction changes. There may be zero.
And that hardware stack is perfect for cog-sized programs.
...
Nice problem to have. Just didn't want to speak to it that closely.
Seems even that would be useful, and some soft control of the limit of the ceiling on that, could open HUBEXEC ?
What is the current state of play around in-line-ASM in GCC, for P1 ?
That seemed to be something missing in LLVM pathways.
PropGCC for P1 supports the standard GCC way of doing inline assembly.