FastSpin is cool and all, but it doesn't hardly use any of the new P2 features. Cordic, LUT(shared or not), streamer (for other than HUBexec if it even does that fully or at all), smart pins, and so on. These are the things Chip wants to prove out before making the big choice.
Fastspin certainly uses hubexec, and the cordic (for multiply, divide, sqrt). For other P2 features it's trivial to add Spin functions with inline assembly:
PUB log(x) : r
asm
qlog x
getqx r
endasm
Adding a library of builtin functions like this would certainly be easier than creating a whole new interpreter.
Similarly, PropGCC intrinsics also provide builtin (not via function calls) access to P1 instructions, and the same could be done for P2 for the rare cases where function calls cannot do something.
Let's face it: for testing P2 functionality PASM, Fastspin, or C would all suffice. We don't *need* Spin2 to use the P2, or to tape it out; the interpreter isn't in ROM so it can be done later. Dave Hein is absolutely correct about that.
Chip is really attached to Spin2 and wants to get it done. I can understand that (writing interpreters and languages can be fun!) but I hope he leaves any major language changes for later. Indeed, one of the great things about not having the interpreter in ROM is that Spin2 can continue to evolve and improve.
I mostly say this because FastSpin has been around for ages but I've never heard of anyone using it. However, I frequently hear people say we need Spin for P2 ASAP. That suggests to me that people don't view FastSpin as a *real* implementation of Spin.
Does that means that we already have a spin1-like implementation for P2 v19?
FastSpin? I cannot find any link to the interpreter. A search at the forum only gives a code for FGPA v16.
The latest version is at https://github.com/totalspectrum/spin2cpp/releases. It compiles a superset of Spin1 (there are some Spin2 features) to P1 or P2 v18. I can update it to v19 if there's interest, but so far nobody but me (and maybe David Betz) seems to be using it for P2.
I will try FastSpin v18 as I think maybe I will not miss any new feature between v18 and v19.
I think that an added big plus of fastspin is that I will be able to learn more faster how to program PASM by looking at the PASM code generated from Spin, than if I start directly with P2 PASM. Or maybe not, if Spin code is converted to some kind of hubexec LLM code then I will not understand anything.
We don't need it, but Chip does, and he's the one that has to commit a large amount of money from his company to make it.
I don't think Chip "needs" it. I think he "wants" it. Which is totally fair, it's his company and his project. I just hope he recognizes how much we all really want silicon ASAP, and how much time there will be after the silicon tapes out to polish and improve Spin2.
I think that an added big plus of fastspin is that I will be able to learn more faster how to program PASM by looking at the PASM code generated from Spin, than if I start directly with P2 PASM. Or maybe not, if Spin code is converted to some kind of hubexec LLM code then I will not understand anything.
In P2 code executing from hub looks just like code executing from COG -- there's no need for LMM or anything fancy like that. It's one of the nice features of P2 that we're all looking forward to!
I think that an added big plus of fastspin is that I will be able to learn more faster how to program PASM by looking at the PASM code generated from Spin, than if I start directly with P2 PASM.
IIRC Eric has added source code as comments to the ASM out ? - so yes, this should be a great way to learn PASM.
Of course, once you have such nice tight documents and an understanding of what code is produced, you tend to need ASM less
It is a good idea for Embedded developers to have both HLL and resulting code views.
Of course, once you have such nice tight documents and an understanding of what code is produced, you tend to need ASM less.
Less, maybe, but not never. I would contend that there are tightly-crafted assembly routines that could never have been the result of compilation from a HLL and, moreover, that a compiler could not produce more efficient coding, regardless of optimization. I would also contend that the unique architecture of the Prop makes this even more probable than on most other processors.
Of course, once you have such nice tight documents and an understanding of what code is produced, you tend to need ASM less.
Less, maybe, but not never. I would contend that there are tightly-crafted assembly routines that could never have been the result of compilation from a HLL and, moreover, that a compiler could not produce more efficient coding, regardless of optimization. I would also contend that the unique architecture of the Prop makes this even more probable than on most other processors.
Yup, which is why I did say less and not never... It is also why I advocate for in-line ASM support, that fastspin already has
From above...
PUB log(x) : r
asm
qlog x
getqx r
endasm
Very nice.
An outcome may be that such a HLL, is used as a High Level Assembler, and separate ASM files are used less and less.
Yup, which is why I did say less and not never... It is also why I advocate for in-line ASM support, that fastspin already has
Absolutely. But none of that quoted "[asm code]\n" Smile for each line that GCC requires. It has to be easy to type and look like real assembly code, complete with column alignment.
Yup, which is why I did say less and not never... It is also why I advocate for in-line ASM support, that fastspin already has
Absolutely. But none of that quoted "[asm code]\n" Smile for each line that GCC requires. It has to be easy to type and look like real assembly code, complete with column alignment.
-Phil
I certainly agree with that. I have no idea why the GCC inline code syntax is so ugly.
I certainly agree with that. I have no idea why the GCC inline code syntax is so ugly.
I think that is the combined product of 'Multiple targets', & 'easiest' pressures.
They just feed-straight-thru the ASM lines, to the following Assembler pass, with almost no IQ. That also impacts name-space handling too...
Better design is to include an Assembler parser, so between asm..endasm, can be much smarter.
Of course, that gets target specific, and so is avoided by GCC...
I think you are right Phil. I'm no compiler expert but it seems to me that modern compiler and optimizer technology does a brilliant job of producing small and speedy code. So much so that writing in assembler does not gain you much.
But that is for, shall we say, "normal" source code and normal everyday instructions. Historically compilers have fallen down when it comes to weird instruction sets and architectures. It just gets too complicated to deal with. At least that is my feeling based on examples like the Intel i860 and the Itanium. In such cases the problem of achieving optimum performance was shunted from the hardware to the compilers. The compilers did not deliver.
Given the thousands of instructions in the P2 I imagine that a typical compiler would only ever use a few percent of them. There will be a lot of scope for hand crafting PASM.
C is alive on the P2! I just posted an update to the Can't wait for PropGCC on the P2? . It is still far from complete, but I have several sample C programs that run on the P2 FPGA. I've even got some SD file I/O working. The SD SPI driver is written in C, so it is very slow. Eventually I want to create a P2 assembly version of the driver to get the highest speed. Or maybe the driver can stay in C, but use the SPI functionality in the Smart pins to speed it up. The nice thing about C is that one can link pure C and pure assembly object files together to get the best of both worlds. It would be nice if Spin2 could generate compatible object files so they could be linked together as well. Of course this can be done using spin2cpp. I'm not sure how it will work with Spin2 code that is compiled to bytecode. I suppose a separate Spin cog and a mailbox would be the easiest solution.
Eventually I want p2gcc C code to be integrated to PASM in the same way that Spin code integrates to PASM. I think the way to do this is to create a superset of C that allows for a DAT section. The DAT section would contain pure PASM code. This would be contained in a file with something like a .pc extension for PASM-C. A pre-processor would separate the .pc file into separate .c and .spin2 files. The pre-processor would provide hooks in the C code to access the data in the Spin2 file so C would have exactly the same connection that Spin has. At least that's the best approach I've come up with at this point. I can't see any technical reasons why a PC program can't be as tightly coupled to the P2 as a Spin2 program will be.
C is alive on the P2! I just posted an update to the Can't wait for PropGCC on the P2? . It is still far from complete, but I have several sample C programs that run on the P2 FPGA.
... The nice thing about C is that one can link pure C and pure assembly object files together to get the best of both worlds. It would be nice if Spin2 could generate compatible object files so they could be linked together as well. Of course this can be done using spin2cpp. I'm not sure how it will work with Spin2 code that is compiled to bytecode. I suppose a separate Spin cog and a mailbox would be the easiest solution.
The most basic interface would be array declared at an absolute address in both flows.
A bit more flexible is PUBLIC and EXTRN type declarations via the linker.
Even if Spin2 came short of 'generate compatible object files', maybe you could have your link read some Spin2 MAP file to extract a Varname:Address pair ?
Seems that should be minimal interim work for you/Chip ?
Eventually I want p2gcc C code to be integrated to PASM in the same way that Spin code integrates to PASM. I think the way to do this is to create a superset of C that allows for a DAT section. The DAT section would contain pure PASM code. This would be contained in a file with something like a .pc extension for PASM-C. A pre-processor would separate the .pc file into separate .c and .spin2 files. The pre-processor would provide hooks in the C code to access the data in the Spin2 file so C would have exactly the same connection that Spin has. At least that the best approach I come up with at this point. I can't see any technical reasons why a PC program can't be as tightly coupled to the P2 as a Spin2 program will be.
I'm not entirely following this.
I think you have C/PASM/Linking working, so this is less a need than a plan ?
DAT sections and pre-processors that spawn yet more files, and file extensions, sounds less than ideal.
What about in-line ASM, done the way Eric shows above ?
I would rather see C extended to accommodate the P2's functionality via native operators, rather than being shoehorned into awkward function calls. Otherwise, you're just looking at a kludge.
But if C is, by definition, non-extensible, why use it at all?
-Phil
Okay, that was a little over the top, perhaps, but you know what I mean ... right?
The C language syntax is non-extensible, but C can be extended through function calls. For very simple functions, the compiler will convert them to inline code, which in some cases can result in a single PASM instruction being issued. On the P1 PropGCC understands how to use the basic arithmetic and logic instructions of the Prop. For the non-ALU type of instructions a built-in function can be defined. Thus there are built in functions for clkset, cogid, cognew, coginit, locknew, lockset, lockclk, waitcnt, waitvid, etc. In many cases these built-in functions generate a single PASM instruction. The registers INA, OUTA, DIRA, CTRA, etc. are also defined, so a C program can access these registers directly. These are all native features of the Prop that C can access. So PropGCC may be more tightly coupled to the Prop than you might think.
The thing that is missing in PropGCC is the tight coupling to PASM that Spin has. There are ways to do it with the current implementation of PropGCC, but I've always had difficulty using it. And if I have trouble with it I can't imagine how a novice could deal with it. So that's why I'm proposing the PC extension to PropGCC. A test.pc program would include both C code and a DAT section containing PASM code, just like a Spin file contains both Spin and PASM. test.pc would be pre-processed into separate files containing the C and PASM parts, and these files would be compiled by the appropriate tools and then linked together. The programmer doesn't need to know the details of how this happens, all he needs to know is that he can write C and PASM code together in the same file, and it magically gets compiled into a binary.
The pre-processing of such a file is fairly straightforward, and some day when I have a chance I'll give it a try. If it works that would be great. If it doesn't, then I've only wasted a day or two. Either way, I think it's worth pursuing.
@jmg, inline assembly is effective if only a few lines are required. PropGCC supports it, and it's a good feature. However, it is a bit clumsy to use it when writing a hundred or more lines of assembly. It also doesn't look very good either. People are used to the Spin/PASM method for coding, and I find it to be an extremely powerful feature and easy to use. I think it would be interesting to see if this method could be use with C as well.
@jmg, inline assembly is effective if only a few lines are required. PropGCC supports it, and it's a good feature. However, it is a bit clumsy to use it when writing a hundred or more lines of assembly.
The example above is not clumsy, to me ?
Why is it limited to "only a few lines" ?
People are used to the Spin/PASM method for coding, and I find it to be an extremely powerful feature and easy to use.
I think it would be interesting to see if this method could be use with C as well.
So you propose instead of asm .. endasm which is clear in intent, you prefer to use DAT to mean Start_Assembler_Section ?
Not that clear to a new user, is it ?
If you split the source file with a pre-processor, how does the user resolve the error messages from the downstream Compiler and ASM ?
How does a Debugger source-step ?
All that line-information is lost. Sounds a very long way from "easy to use" to me.
Dave,
Your proposal to allow DAT PASM sections of code within C files, just like SPIN files sounds great to me. Seems this is the missing link to have C programs work with PASM. I do hope you are successful getting this working. It might even convince me to do more C programming
While you are trying this, maybe you could think about whether the file could have SPIN within it to ??? ie really a spin file with a C-Section. This way we could have the best of all worlds. Obviously the Spin compiler would need to be called to compile that spin (and maybe pasm) section.
@jmg, inline assembly is effective if only a few lines are required. PropGCC supports it, and it's a good feature. However, it is a bit clumsy to use it when writing a hundred or more lines of assembly.
The example above is not clumsy, to me ?
Why is it limited to "only a few lines" ?
People are used to the Spin/PASM method for coding, and I find it to be an extremely powerful feature and easy to use.
I think it would be interesting to see if this method could be use with C as well.
So you propose instead of asm .. endasm which is clear in intent, you prefer to use DAT to mean Start_Assembler_Section ?
Not that clear to a new user, is it ?
If you split the source file with a pre-processor, how does the user resolve the error messages from the downstream Compiler and ASM ?
How does a Debugger source-step ?
All that line-information is lost. Sounds a very long way from "easy to use" to me.
I agree, fastspin inline asm looks much better than PropGCC's. That could be incorporated into PC files, which would then be converted to PropGCC's format during the conversion step. Why is a DAT section needed then? I think it would be needed so that PASM code could be written that would be loaded into another cog. Maybe there are things that can be done in PASM that can't be done with inline ASM. I don't know, I haven't looked into it that thoroughly. Or maybe the difference is just in the syntax. If asm...endasm is used within a C function it is just inline code, but if it is used outside of a function it is PASM code. Maybe it would look something like this
int log(int x)
{
int r;
asm
qlog x
getqx r
endasm
return r;
}
asm
CON
ABC = 3
DEF = 4
DAT
enter mov addr1, ptra
mov addr2, ptrb
...
parm1 long 0
addr1 long 0
addr2 long 0
fit $1f0
endasm
static int stack[100];
int startup(int parm)
{
int cognum;
parm1 = parm;
cognum = cognew(&enter, stack);
return cognum;
}
Keeping track of line numbers after the file is split is tricky. GCC manages to know the original line numbers after a header file is included. I'm sure a similar method could be used. I thought about that issue when I was working on Taz C. My plan was to use a PRAGMA to indicate the original file name and line numbers to the later stages. Now a source level debugger -- that would be nice. The debugger used with GCC is GDB, which is really ugly. Maybe somebody can put a pretty GUI face on it so that it's usable by mere mortals like me.
I wonder if the debug interrupt in P2 has everything required to work with GDB. This is another reason why there should be a GCC effort going on now before the design is cast in silicon.
I may have missed it... will we able to use a pointer to a method as a parameter?
Yes. I'm working on that now.
It's taken me a week to fully re-understand and update the Spin calling convention. That sounds stupid, I know, but my problem is that there are so many slightly-better ways to code something in PASM that it can drive you crazy. I think I'm at the end of this part, but it's been dizzying.
I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
I'm with Bill: Spin is not worthless. I just finished a 6K line (Spin & PASM) app for a customer who is thrilled -- and after a month of testing, NO BUGS. I will eventually learn to write C as effortlessly as I write Spin; I like knowing I can be productive and having a language that is tied right to the architecture and no "workarounds" are required.
I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
I'm with Bill: Spin is not worthless. I just finished a 6K line (Spin & PASM) app for a customer who is thrilled -- and after a month of testing, NO BUGS. I will eventually learn to write C as effortlessly as I write Spin; I like knowing I can be productive and having a language that is tied right to the architecture and no "workarounds" are required.
+1
There is a place for PASM, SPIN2 and C (and Blockly).
I am more of an assembler programmer than high level. However, almost all of my P1 programs are a mix of SPIN & PASM. I do PASM where necessary, and SPIN otherwise.
With past micros, I haven't been able to use HLL because of what I have been doing. I have used multiple micros since the 80's to simplify the programming aspect. The P1 architecture has enabled me to use a HLL, and since SPIN is quite simple and easy, it's a no-brainer.
I suspect I will venture into C more on the P2 as well as SPIN & PASM. Might even try Bockly for may grandkids (8th on the way, 8 and under)
Worthless??? Hardly! Spin is easily the best RAD (rapid application development) language for the Propeller. It's simple and quick to write a Spin program to do almost anything, and it's the perfect glue for holding PASM modules together, when you need PASM for the heavy lifting. Once you've mastered Spin's very short learning curve, it's off to the races from a productivity standpoint.
Although Parallax might need C to sell the Propeller, serious users will always need Spin/PASM to get the most from it.
Worthless??? Hardly! Spin is easily the best RAD (rapid application development) language for the Propeller. It's simple and quick to write a Spin program to do almost anything, and it's the perfect glue for holding PASM modules together, when you need PASM for the heavy lifting. Once you've mastered Spin's very short learning curve, it's off to the races from a productivity standpoint.
Although Parallax might need C to sell the Propeller, serious users will always need Spin/PASM to get the most from it.
-Phil
When I bought my first prop, I actually had two spin programs running first... flash leds/pins and then sending serial using FullDuplexSerial. And that was in the first hour or two! Pasm followed later to flash leds/pins.
And with SPIN2 being so much faster, plus the additional P2 clock and instructions each being 2x faster, it will fit in even better!!!
Comments
Fastspin certainly uses hubexec, and the cordic (for multiply, divide, sqrt). For other P2 features it's trivial to add Spin functions with inline assembly:
PUB log(x) : r asm qlog x getqx r endasmAdding a library of builtin functions like this would certainly be easier than creating a whole new interpreter.
Similarly, PropGCC intrinsics also provide builtin (not via function calls) access to P1 instructions, and the same could be done for P2 for the rare cases where function calls cannot do something.
Let's face it: for testing P2 functionality PASM, Fastspin, or C would all suffice. We don't *need* Spin2 to use the P2, or to tape it out; the interpreter isn't in ROM so it can be done later. Dave Hein is absolutely correct about that.
Chip is really attached to Spin2 and wants to get it done. I can understand that (writing interpreters and languages can be fun!) but I hope he leaves any major language changes for later. Indeed, one of the great things about not having the interpreter in ROM is that Spin2 can continue to evolve and improve.
Eric
The latest version is at https://github.com/totalspectrum/spin2cpp/releases. It compiles a superset of Spin1 (there are some Spin2 features) to P1 or P2 v18. I can update it to v19 if there's interest, but so far nobody but me (and maybe David Betz) seems to be using it for P2.
Eric
We don't need it, but Chip does, and he's the one that has to commit a large amount of money from his company to make it.
I will try FastSpin v18 as I think maybe I will not miss any new feature between v18 and v19.
I think that an added big plus of fastspin is that I will be able to learn more faster how to program PASM by looking at the PASM code generated from Spin, than if I start directly with P2 PASM. Or maybe not, if Spin code is converted to some kind of hubexec LLM code then I will not understand anything.
I don't think Chip "needs" it. I think he "wants" it. Which is totally fair, it's his company and his project. I just hope he recognizes how much we all really want silicon ASAP, and how much time there will be after the silicon tapes out to polish and improve Spin2.
Eric
In P2 code executing from hub looks just like code executing from COG -- there's no need for LMM or anything fancy like that. It's one of the nice features of P2 that we're all looking forward to!
Eric
IIRC Eric has added source code as comments to the ASM out ? - so yes, this should be a great way to learn PASM.
Of course, once you have such nice tight documents and an understanding of what code is produced, you tend to need ASM less
It is a good idea for Embedded developers to have both HLL and resulting code views.
-Phil
From above...
PUB log(x) : r asm qlog x getqx r endasmVery nice.An outcome may be that such a HLL, is used as a High Level Assembler, and separate ASM files are used less and less.
-Phil
They just feed-straight-thru the ASM lines, to the following Assembler pass, with almost no IQ. That also impacts name-space handling too...
Better design is to include an Assembler parser, so between asm..endasm, can be much smarter.
Of course, that gets target specific, and so is avoided by GCC...
But that is for, shall we say, "normal" source code and normal everyday instructions. Historically compilers have fallen down when it comes to weird instruction sets and architectures. It just gets too complicated to deal with. At least that is my feeling based on examples like the Intel i860 and the Itanium. In such cases the problem of achieving optimum performance was shunted from the hardware to the compilers. The compilers did not deliver.
Given the thousands of instructions in the P2 I imagine that a typical compiler would only ever use a few percent of them. There will be a lot of scope for hand crafting PASM.
Eventually I want p2gcc C code to be integrated to PASM in the same way that Spin code integrates to PASM. I think the way to do this is to create a superset of C that allows for a DAT section. The DAT section would contain pure PASM code. This would be contained in a file with something like a .pc extension for PASM-C. A pre-processor would separate the .pc file into separate .c and .spin2 files. The pre-processor would provide hooks in the C code to access the data in the Spin2 file so C would have exactly the same connection that Spin has. At least that's the best approach I've come up with at this point. I can't see any technical reasons why a PC program can't be as tightly coupled to the P2 as a Spin2 program will be.
Sounds great. The most basic interface would be array declared at an absolute address in both flows.
A bit more flexible is PUBLIC and EXTRN type declarations via the linker.
Even if Spin2 came short of 'generate compatible object files', maybe you could have your link read some Spin2 MAP file to extract a Varname:Address pair ?
Seems that should be minimal interim work for you/Chip ?
I'm not entirely following this.
I think you have C/PASM/Linking working, so this is less a need than a plan ?
DAT sections and pre-processors that spawn yet more files, and file extensions, sounds less than ideal.
What about in-line ASM, done the way Eric shows above ?
But if C is, by definition, non-extensible, why use it at all?
-Phil
Okay, that was a little over the top, perhaps, but you know what I mean ... right?
The thing that is missing in PropGCC is the tight coupling to PASM that Spin has. There are ways to do it with the current implementation of PropGCC, but I've always had difficulty using it. And if I have trouble with it I can't imagine how a novice could deal with it. So that's why I'm proposing the PC extension to PropGCC. A test.pc program would include both C code and a DAT section containing PASM code, just like a Spin file contains both Spin and PASM. test.pc would be pre-processed into separate files containing the C and PASM parts, and these files would be compiled by the appropriate tools and then linked together. The programmer doesn't need to know the details of how this happens, all he needs to know is that he can write C and PASM code together in the same file, and it magically gets compiled into a binary.
The pre-processing of such a file is fairly straightforward, and some day when I have a chance I'll give it a try. If it works that would be great. If it doesn't, then I've only wasted a day or two. Either way, I think it's worth pursuing.
@jmg, inline assembly is effective if only a few lines are required. PropGCC supports it, and it's a good feature. However, it is a bit clumsy to use it when writing a hundred or more lines of assembly. It also doesn't look very good either. People are used to the Spin/PASM method for coding, and I find it to be an extremely powerful feature and easy to use. I think it would be interesting to see if this method could be use with C as well.
Why is it limited to "only a few lines" ?
- but it is simply ASM source code, so looks identical - or do you mean the terrible GCC in-line ASM, which is not the example I've given at all.
So you propose instead of asm .. endasm which is clear in intent, you prefer to use DAT to mean Start_Assembler_Section ?
Not that clear to a new user, is it ?
If you split the source file with a pre-processor, how does the user resolve the error messages from the downstream Compiler and ASM ?
How does a Debugger source-step ?
All that line-information is lost. Sounds a very long way from "easy to use" to me.
Your proposal to allow DAT PASM sections of code within C files, just like SPIN files sounds great to me. Seems this is the missing link to have C programs work with PASM. I do hope you are successful getting this working. It might even convince me to do more C programming
While you are trying this, maybe you could think about whether the file could have SPIN within it to ??? ie really a spin file with a C-Section. This way we could have the best of all worlds. Obviously the Spin compiler would need to be called to compile that spin (and maybe pasm) section.
Yes, this is one of the planned features of Spin2, after some discussions about the syntax it went sadly quiet.
I personally miss this feature since a long time, it would really complete Spin for me.
But I am, and will be just a un-significant minor dent in sales of Parallax products.
Enjoy!
Mike
int log(int x) { int r; asm qlog x getqx r endasm return r; } asm CON ABC = 3 DEF = 4 DAT enter mov addr1, ptra mov addr2, ptrb ... parm1 long 0 addr1 long 0 addr2 long 0 fit $1f0 endasm static int stack[100]; int startup(int parm) { int cognum; parm1 = parm; cognum = cognew(&enter, stack); return cognum; }Keeping track of line numbers after the file is split is tricky. GCC manages to know the original line numbers after a header file is included. I'm sure a similar method could be used. I thought about that issue when I was working on Taz C. My plan was to use a PRAGMA to indicate the original file name and line numbers to the later stages. Now a source level debugger -- that would be nice. The debugger used with GCC is GDB, which is really ugly. Maybe somebody can put a pretty GUI face on it so that it's usable by mere mortals like me.
There are others:
https://sourceware.org/gdb/wiki/GDB Front Ends
Yes. I'm working on that now.
It's taken me a week to fully re-understand and update the Spin calling convention. That sounds stupid, I know, but my problem is that there are so many slightly-better ways to code something in PASM that it can drive you crazy. I think I'm at the end of this part, but it's been dizzying.
I plan on using it a lot (like on the P1)
Mind you, I will also use C
Depends on what I am doing
+1
There is a place for PASM, SPIN2 and C (and Blockly).
I am more of an assembler programmer than high level. However, almost all of my P1 programs are a mix of SPIN & PASM. I do PASM where necessary, and SPIN otherwise.
With past micros, I haven't been able to use HLL because of what I have been doing. I have used multiple micros since the 80's to simplify the programming aspect. The P1 architecture has enabled me to use a HLL, and since SPIN is quite simple and easy, it's a no-brainer.
I suspect I will venture into C more on the P2 as well as SPIN & PASM. Might even try Bockly for may grandkids (8th on the way, 8 and under)
Although Parallax might need C to sell the Propeller, serious users will always need Spin/PASM to get the most from it.
-Phil
And with SPIN2 being so much faster, plus the additional P2 clock and instructions each being 2x faster, it will fit in even better!!!