It sounds like people really want to use PNut syntax for the inline assembly, so I'll try to support that. Despite what I said in my first message, I'm actually leaning towards supporting both PNut syntax (inside a block marked with __pasm) and C syntax (inside __asm). So you could write either:
__asm {
mov a, #VAL % 0x100 // set a to low byte of VAL
}
or
__pasm {
mov a, #VAL // $100 ' set a to low byte of VAL
}
The code for __asm is basically there now. The only thing I had to add was the ability to put them outside of functions, and that's done in github. __pasm is a whole new kettle of fish, since it requires bolting a part of the Spin parser onto the C parser and also the C preprocessor, so it's going to take a while.
There will probably be some restrictions on what can go inside __pasm blocks, e.g. "{" comments will have to be consistently nested (doc comments that start with "{{" have some funny rules which I probably won't fully follow in the C inline pasm, opting for the simpler "you have to match { and } characters). I also doubt that CON will be supported inside __pasm, it's just the equivalent of a DAT block.
Maybe this whole thing is more trouble than it's worth... it might be simpler to just say "put the assembly code in an external .spin2 file", which is what other C compilers do. On the other hand mixing the assembly and high level code has always been a very useful feature of Spin, and it would be nice to be able to do it in C too.
I don't care exactly how this gets resolved, but it needs to be resolved, along with a number of other issues. Like, NOW.
P2 is coming. When the original Propeller came there was a common development language for it. If you went to the OBEX looking for code you knew what language it would be in and you knew it would work in the development system you were using.
I don't care what development system that ends up being for P2. I really don't. (except I really, really hate C++ but that's just me.) But even if it's C++ we need to be clear on this. If the driver I need for a video mode, a temperature sensor, or serial port is there, it needs to either be in the language I'm using, or in the one I know I need to know to translate from. This is the way it was for P1 until $recently.
Parallax, you need to fix this before it becomes a deal-killing problem. You need to tell us what the lingua spin is for P2, and make sure we all have access to the development tools for it, and if any other languages are being seriously supported you need to make sure we have access to good paths between those and the One True Prop Language. And please, please, please don't try to pretend there is more than one True Prop Language. Decide. Tell us. And enforce it. You have to.
@localroger, I usually agree a lot with you, but in this case I do have to disagree.
@ersmith solved that problem perfectly, this is the best thing of fastspin/flexgui and I still think it should be named ECC as for Eric's Compiler Collection. It is just wonderful how one can integrate Spin and C objects, even Basic.
On the other end is Blockly, producing C for GCC4. And Chip want his own SPIN2 (and Eric will hopefully adapt to it), and Ross has ported Catalina, so we already have a lot of development tools, all of them able to run on Linux, Mac and Windows.
Parallax does not do that, Proptool and Chips Spin2 will be - as usual - x86 assembler and Delphi, Windows only. Maybe they could at least switch to Lazarus or something like that, to make it more portable, but I doubt that will happen.
There is some work on GCC9(?) but if the changes do not go upstream, it will get stale also, like the current GCC for P1.
Writing Software is obviously not the strongest part of Parallax. My best tip for them would be to hire eric away from wherever he works and buy him a house near Rocklin.
But asking Parallax to declare a True Prop Language is, sorry, foolish. I neither like C++ nor C very much, but C seems to be the most common standard right now, Blockly uses it and we have sort of 2 and a half C compiler currently creating code for the P2. And luckily there is some co-working going on to use common header files and macros between Catalina and fastspin, not sure about the current gcc port in development.
The only True Prop Language is simply PASM. Since we have HUBEXEC and no SPIN Interpreter in ROM it is the only common thing we have, besides TAQOZ.
So I can see the dilemma Parallax is in but do not see any easy way out. Except Eric's multy language approach.
The current github of fastspin now supports both the __asm keyword (for C style expressions and comments) and __pasm (for Spin style expressions and comments). I've attached a zip file to show how these may be used. Basically this lets you write C drivers that are very similar to Spin drivers, with "__pasm" taking the place of "DAT".
You'll need fastspin 4.04-beta to compile these examples (e.g. one compiled from the current github sources). A binary is available in the FlexGUI 4.04 preview on my Patreon page (https://patreon.com/totalspectrum), and probably on David Zemon's page as well.
I hope to make a public release of 4.04 this weekend.
Comments
__asm { mov a, #VAL % 0x100 // set a to low byte of VAL }or__pasm { mov a, #VAL // $100 ' set a to low byte of VAL }The code for __asm is basically there now. The only thing I had to add was the ability to put them outside of functions, and that's done in github. __pasm is a whole new kettle of fish, since it requires bolting a part of the Spin parser onto the C parser and also the C preprocessor, so it's going to take a while.There will probably be some restrictions on what can go inside __pasm blocks, e.g. "{" comments will have to be consistently nested (doc comments that start with "{{" have some funny rules which I probably won't fully follow in the C inline pasm, opting for the simpler "you have to match { and } characters). I also doubt that CON will be supported inside __pasm, it's just the equivalent of a DAT block.
Maybe this whole thing is more trouble than it's worth... it might be simpler to just say "put the assembly code in an external .spin2 file", which is what other C compilers do. On the other hand mixing the assembly and high level code has always been a very useful feature of Spin, and it would be nice to be able to do it in C too.
@localroger, I usually agree a lot with you, but in this case I do have to disagree.
@ersmith solved that problem perfectly, this is the best thing of fastspin/flexgui and I still think it should be named ECC as for Eric's Compiler Collection. It is just wonderful how one can integrate Spin and C objects, even Basic.
On the other end is Blockly, producing C for GCC4. And Chip want his own SPIN2 (and Eric will hopefully adapt to it), and Ross has ported Catalina, so we already have a lot of development tools, all of them able to run on Linux, Mac and Windows.
Parallax does not do that, Proptool and Chips Spin2 will be - as usual - x86 assembler and Delphi, Windows only. Maybe they could at least switch to Lazarus or something like that, to make it more portable, but I doubt that will happen.
There is some work on GCC9(?) but if the changes do not go upstream, it will get stale also, like the current GCC for P1.
Writing Software is obviously not the strongest part of Parallax. My best tip for them would be to hire eric away from wherever he works and buy him a house near Rocklin.
But asking Parallax to declare a True Prop Language is, sorry, foolish. I neither like C++ nor C very much, but C seems to be the most common standard right now, Blockly uses it and we have sort of 2 and a half C compiler currently creating code for the P2. And luckily there is some co-working going on to use common header files and macros between Catalina and fastspin, not sure about the current gcc port in development.
The only True Prop Language is simply PASM. Since we have HUBEXEC and no SPIN Interpreter in ROM it is the only common thing we have, besides TAQOZ.
So I can see the dilemma Parallax is in but do not see any easy way out. Except Eric's multy language approach.
Mike
There is nothing else out there like it.
A nice thing about all this is anyone who gets it will keep coming back. Not everyone will. Oh well.
I bet enough will to make a nice, sustainable business. If so, Ken is happy for another decade or two.
You'll need fastspin 4.04-beta to compile these examples (e.g. one compiled from the current github sources). A binary is available in the FlexGUI 4.04 preview on my Patreon page (https://patreon.com/totalspectrum), and probably on David Zemon's page as well.
I hope to make a public release of 4.04 this weekend.