Don't get me wrong, I think the P2 is amazing, Chip built a great chip that I want to use in future projects. It adds so much awesome stuff.
I just think he went off the rails with Spin2. I, also, fear that Parallax is going down the same path it did with P1 initially. Where it's only got a closed source x86/Windows only compiler for a new language that no one knows. At least this time around the community provided alternatives are coming online earlier, which helps the small group here on the forums that are in the know, but right now the official supported/backed path is x86 Spin2 compiler stuck into the same closed source Windows only PropTool P1 had.
This can't be what Ken and Parallax really wants... they can't be hoping for P2 success with just this as the launch offering.
I am trying to decide what I think about all this.
Why is an interpreter a good idea? Can someone give me the top 3 pro's?
Pro's
* Code size ? ( P2 has loads of resources )
* ??
* ??
Cons
* Speed
* Confusing PASM Interop
* Highly constrained limited toy language
Code size is the only advantage I can think of. It seems to me that the most logical approach would be to use FastSpin for your initial development and only move to Spin2 if you find that your application won't fit when compiled to native code instead of byte code. My guess is that most applications will never get to that point.
I am trying to decide what I think about all this.
Why is an interpreter a good idea? Can someone give me the top 3 pro's?
Pro's
* Code size ? ( P2 has loads of resources )
* ??
* ??
Cons
* Speed
* Confusing PASM Interop
* Highly constrained limited toy language
Well, code size is a pretty big one (moreso on P1 with 32K RAM, but still important). Less memory used by code -> more space for other stuff. And bytecode decoding is hardware-accelerated, so the speed is actually much better than a pure interpeter (like Spin1 has)
I wonder if fastspin can get a bytecode backend...
I'm curious about what Chip said about Spin2 code being relocatable...
Wonder if that means you could bring in a object from say uSD card and then run it...
That might be interesting...
I kinda agree with David. Unless you have some kind of giant buffer that takes up most of HUB RAM, it's hard to imagine running out of space for code for usual applications.
But, I am often running out of RAM on P1, so it's definitely nice to have an option for the case of needing small code.
Our customers would want us to launch with an open-source compiler that works under Windows and Mac operating systems, preferably Linux too.
The needs vary by customer type. Most of our current commercial product development customers use Windows. Their purchasing horizon is quite long due to design cycles, a challenge when we can only grow the business with retained earnings while selling smaller numbers of prototype chips. The enthusiast, hobbyist, and educator use all three operating systems (Win, Mac, Linux) and have a much faster uptake in the early months with a good volume, helping us with the purchase of modules, boards and whatever else we produce around the P2 that we can sell in the near-term. These latter customers often become commercial product developers, too.
Our customer base has all types: commercial, educational, hobby, etc. This means they need support for operating systems of their choice.
But first, Chip simply needs to finish Spin2. Customers have booked many trays of P2 chips and they'll want to program them within a week or two. On Monday we take delivery of the final P2 prototypes and will have them mounted on P2 evaluation boards by the evening. Chip will be able to test the final A/D-D/A with the Rev C repairs and many subsequent, important and expensive activities will follow. We need to clear the way of interruptions and encourage Chip to get us closer to simply being able to program the P2 with Spin2.
Chip has now put most of his professional career into the Propeller 1 and 2. We certainly want open-source compilers that run on anything, but this exact moment in time isn't the right time to fully identify those solutions. I want them; you want them; we all want them. But we must first be able to program the P2 in Spin.
What we have at release isn't clear, nor have we had an extensive discussion about the possibilities. Many of us are busy running the business we currently have, not the one we will become. Changes lie ahead and we're looking forward to them, a whole bunch! I'll see Chip this afternoon and hope to come away with a clear understanding of the state of our compiler.
I can hear you say "but you've absolutely got to be thinking about this and have a plan - how could Parallax put years and millions into this effort and not have a plan?" It's coming soon.
.. Customers have booked many trays of P2 chips and they'll want to program them within a week or two. On Monday we take delivery of the final P2 prototypes and will have them mounted on P2 evaluation boards by the evening. Chip will be able to test the final A/D-D/A with the Rev C repairs and many subsequent, important and expensive activities will follow. We need to clear the way of interruptions and encourage Chip to get us closer to simply being able to program the P2 with Spin2.
? Customers can program P2 now.
Customers wanting to write programs for P2, will expect a language they are familiar with, or very easy porting from a language they are familiar with.
Comments above show Spin2 rather fails both those tests.
Existing right now are language users are familiar with :
fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler
but missing is a decent GUI debugger.
If you want rapid customer ramp, it would have been smarter to have Chip work on a good debugger so that all those languages users are familiar with, can SingleStep/Break/Watch - which other vendors offer.
I am trying to decide what I think about all this.
Why is an interpreter a good idea? Can someone give me the top 3 pro's?
Pro's
* Code size ? ( P2 has loads of resources )
* ??
* ??
Cons
* Speed
* Confusing PASM Interop
* Highly constrained limited toy language
One of the advantages of a good Byte-Coded language, is portability.
However, Spin2 is designed to only run on P2, there are no plans for a PC version. Spin2 is also coded in x86 assembler, I'm not sure anyone will consider that 'open source'.
Given Spin2 has now separated so much from Spin1, it may have been smarter to use Python as the core language template, as Python is already out there, running on many platforms.
Given Spin2 has now separated so much from Spin1, it may have been smarter to use Python as the core language template, as Python is already out there, running on many platforms.
How would that even work? Assuming the core language paradigms stay the same (untyped except for hub access width, "object-based", static memory allocation, no metaprogramming) as they have to be for the fast bytecode approach, you can't just take the syntax, concepts and whatnot of a dynamic scripting language. You can kindof make the syntax look similiar (like Java is similiar to C++), but in that regard Spin(2) already is very similiar to Python, with the significant indentation and all. It's basically just missing the colons after IFs and similiar statements (which always annoy me in Python...) and the assignment operator is different.
@"Ken Gracey"
You have been able to program the P2 in Spin (and an unofficial variant of Spin2) for a while now using FlexGui (FastSpin/etc.). If you guys (Chip especially) had worked with Eric, then official Spin2 could have been done a while ago.
I think the priority on Spin first is maybe not the best for long term. Yes you have existing customers that know and use Spin, but you have way more potential success with customers that will never touch Spin. That's where the official Parallax supported alternatives to Spin that are widely used (BASIC, C, C++, etc.) will be the win. PASM2 is where the real magic is, and those standard languages with inline PASM2 and libraries utilizing PASM2 is what you should want first. Especially since there was already a solution for existing customers that want Spin on P2.
Personally, I find Spin2 to be close enough to Fastspin to be OK.
I've got a fairly large code (2bit tiled gui) that I went about converting from Fastspin to Spin2.
The only major difference I found was the @ giving only relative addresses in Spin2 instead of absolute addresses.
The other things I found are things that FastSpin will probably change to match Spin2 (my guess).
Seems like the major differences between Spin1 and Spin2 are related to hardware changes, so could be expected.
I'm optimistic that Spin2 will turn out to be just fine. There are a lot of improvements compared to Spin1.
I'm really glad to have "=>" now being ">=", for example.
Personally, I find Spin2 to be close enough to Fastspin to be OK.
I've got a fairly large code (2bit tiled gui) that I went about converting from Fastspin to Spin2.
The only major difference I found was the @ giving only relative addresses in Spin2 instead of absolute addresses.
The other things I found are things that FastSpin will probably change to match Spin2 (my guess).
Seems like the major differences between Spin1 and Spin2 are related to hardware changes, so could be expected.
I'm optimistic that Spin2 will turn out to be just fine. There are a lot of improvements compared to Spin1.
I'm really glad to have "=>" now being ">=", for example.
FastSpin is an optimizing compiler so I would think you'd want to use it for most purposes unless its generated code is too big. Even then, I'm sure Eric could add a CMM mode that would exceed the speed of interpreted Spin2 but approach its code density. It seems to me that the best approach would be for Parallax to work with Eric and adopt FastSpin/C/BASIC as its official toolchain.
It would be wonderful if FastSpin or Spin2 could have an integrated debugger. I've not heard of any plans for that though...
Seems the P2 hardware is more amenable to making this work though...
I guess that would be good although I have to admit that I haven't used a debugger in many years. In fact, I'm not sure I ever used them much although I did write a few.
There are so many new things that the language has to do that it is impossible to make it compatible with the original.
What new things does it have to do that fastspin doesn't do now? Genuine question, not trolling -- I'm going to have to make changes to fastspin, obviously. The current fastspin syntax is (almost) backwards compatible with Spin1 and works for both P1 and P2 as long as you stay away from some of the hardware intrinsics, so I guess I'm missing some things.
(I've been out of action for a while, trying to catch up...)
Well, code size is a pretty big one (moreso on P1 with 32K RAM, but still important). Less memory used by code -> more space for other stuff. And bytecode decoding is hardware-accelerated, so the speed is actually much better than a pure interpeter (like Spin1 has)
I wonder if fastspin can get a bytecode backend...
There's no theoretical reason it can't. I've tried to make the setup easy to add new backends, and there are already 2 (the C output code and the ASM one, which also has a binary option).
It could be fair bit of work though to make it exactly compatible with an existing bytecode though. For example it would be very difficult to implement inline assembly in Spin1 bytecode, and the result probably wouldn't work very well.
My understanding is that on the P1 the SPIN byte code interrupter is built into ROM and is loaded at boot time and begins running your byte code SPIN program.
Now on the P2 there is no ROM SPIN code interrupter so is the new P2 SPIN program byte code or pure assembly. In which case the interrupter has to be loaded along with your SPIN2 program.
I have a tray of P2's due shortly. I've been hanging out for Spin2 because my intent has been to get my P1 OS running on P2. For that, I use Kye's magnificent FAT32 driver. I've written the P2 ASM SD driver section many months ago. As you know I wrote the SD boot code for the P2 ROM so this was a natural extension. Now here comes the "BUT". The FAT32 section is written in spin1 and all this time I've been expecting to get a Spin2 language/compiler that would compile the spin1 code. I'm NOT impressed!
Now, I could use Fastspin but...
Parallax doesn't seem inclined to support Eric
I want to use the interpreter, not compiled code.
While I tried a few times, it just didn't seem to resonate with me
The fact that the underlying spin2 interpreter is a completely different animal does not matter. What matters is the high level language. Spin1 was easy to learn. Spin2 is still unknown.
Spin2 needs to be called something other than Spin since it is a NEW language. It is definitely not a SPIN1 extension! And everyone is over new languages of the day.
There is ABSOLUTELY NO REASON that Spin2 could not be upwards compatible with Spin1. In fact, there is EVERY REASON that is should be upwards compatible with Spin1.
Re-use of Spin1 code for P2 - gives an almost instant library for P2
Shows users and potential users of Spin1 and/or Spin2 that it is an easy language supported by 2 micros.
Reinforces the "naysayers" we've been arguing against for the past 12-15 years that spin is here to stay, and a good base to start venturing into the micro world.
IMHO the only way Spin2 will succeed is if it is backwards compatible to Spin1. Otherwise there is ZERO reason to support it. It will become an orphan, and spin1 will also suffer as a result.
Python / Micropython
IMHO Chip's time would have been better spent in making python run on the P2. The language is the current flavor of the year and having that on P2 would have been far better tweeked than doing Spin2 which will only run on P2.
Python is quite similar to Spin. Given the current direction of Spin2, it would make more sense to me to abandon Spin2 right now, and put the effort in making micropython work for P2.
Anyone want a tray of P2's? I am so disheartened right now that I think it's time I moved on to something else.
My understanding is that on the P1 the SPIN byte code interrupter is built into ROM and is loaded at boot time and begins running your byte code SPIN program.
Now on the P2 there is no ROM SPIN code interrupter so is the new P2 SPIN program byte code or pure assembly. In which case the interrupter has to be loaded along with your SPIN2 program.
Yes, the byte-code interpreter engine has to be loaded in Spin2.
I think Chip has made Spin2 smaller than COG sized, to give a little room for in-line assembler.
I've not seen comments yet on size/placement (COG/LUT/HUB) limits on in-line assembler in Spin2 ?
So, here is an issue that I think makes it impossible to make Spin1 compatible with Spin2:
Spin2 supports bitfields for ALL variables, not just I/O pin registers.
This is done by a '.[bitfield]' suffix after the variable, after a possible index.
SomeVariable.[bitfield]++
-or-
SomeLongVariable.byte[index].[bitfield]
-or-
long[pointer][index].[bitfield]
The conflict comes when Spin1 does something like this:
DIRA[23..16]
-or-
DIRA[8]
That last one would look like register[dira+8].
Things have grown and expanded in context. Rather than introduce syntax exceptions for backward compatibility, it seems plain to me that we just need to let Spin2 be what it really is, not a retrofit.
If this bitfield issue wouldn't have flared up so greatly, I'd already be onto the documentation, but the last few days have been spent thinking about how to best implement topbit..bottombit syntax.
And it seems Rayman has already implemented a largish program in Spin2, without any documentation, even.
Well, code size is a pretty big one (moreso on P1 with 32K RAM, but still important). Less memory used by code -> more space for other stuff. And bytecode decoding is hardware-accelerated, so the speed is actually much better than a pure interpeter (like Spin1 has)
I wonder if fastspin can get a bytecode backend...
There's no theoretical reason it can't. I've tried to make the setup easy to add new backends, and there are already 2 (the C output code and the ASM one, which also has a binary option).
It could be fair bit of work though to make it exactly compatible with an existing bytecode though. For example it would be very difficult to implement inline assembly in Spin1 bytecode, and the result probably wouldn't work very well.
Well @ersmith my guess is that it would make sense to build a RiscV backend, so fastspin can run on other computers...
You are doing us all a big favor with FasSpin and FlexGui. @"Roy Eltham" is working on the SimpleTools Libraries, that is super good news because it will get SimpleIDE and Blockly to compile with FastSpin.
So, here is an issue that I think makes it impossible to make Spin1 compatible with Spin2:
Spin2 supports bitfields for ALL variables, not just I/O pin registers.
This is done by a '.[bitfield]' suffix after the variable, after a possible index.
SomeVariable.[bitfield]++
-or-
SomeLongVariable.byte[index].[bitfield]
-or-
long[pointer][index].[bitfield]
The conflict comes when Spin1 does something like this:
DIRA[23..16]
-or-
DIRA[8]
That last one would look like register[dira+8].
Things have grown and expanded in context. Rather than introduce syntax exceptions for backward compatibility, it seems plain to me that we just need to let Spin2 be what it really is, not a retrofit.
If this bitfield issue wouldn't have flared up so greatly, I'd already be onto the documentation, but the last few days have been spent thinking about how to best implement topbit..bottombit syntax.
And it seems Rayman has already implemented a largish program in Spin2, without any documentation, even.
If the difference between the average non-P1-specific Spin1 program and it's Spin2 equivalent is that little, why not just maek a "offical" source converter script? Like, turning DIRA[8] into DIRA.[8] whereever it comes up is just a simple regular expression. Same for the operator differences.
EDIT: I guess there's the much bigger problem that most Spin1 programs use WORDs to store pointers, which obviously won't fly. So you'd still need some non-IO-related rework.
The angst around here in the last few days has been very high. A year ago, many of you were enthusiastic about discussing Spin2 features. Now, it's practically a hot-button issue. It's Spin1 compatibility or death! Or, it should be Python and/or C++, but not Spin, at all. There's no winning around here, lately.
I'm going to keep working on Spin2 because that's what I think the best course of action is. I have a really good feeling about it and I'm looking forward to getting it documented and writing code with it. I just need to see about this top..bottom stuff, first.
Chip,
He told Cluso to shut up. Cluso deserves more respect than that.
Re: Spin2, I've already said basically the same thing several times, and you either didn't understand it or just don't want to do the compiler work (which is all it is). I know part of why you are hung up on this, it's because of how the compiler parses the code, and getting it to be properly context aware (which is what's needed to resolve the bitfield syntax issue) is a huge pain in 386 asm. It's even more of a pain because it's parse to build the symbol table, then parse and encode as you go, instead of the more typical parse into an AST then do everything from the AST, like build the symbol table, determine context, and then encode using all that built up stuff. Anyway, you do need to get Spin2 done, and at this point you should probably just make it what you think is best, because you don't have time to listen to us here anymore. Things will work out eventually.
@cgracey, yes, I also agree with @"Roy Eltham", get your Version finished and don't care about Spin1.
It needs to get out so @"Ken Gracey" can do his part to get P2 out there.
Since it is not in ROM you can tweak it later to accept more of the P1 syntax in the compiler, producing the same opcodes, say dira[1..5] will produce DIRA[1 addbits 5].
You might be able to Just accept the [low..high] and [high..low] with constants at compile time, for everything else one need to use the new syntax.
But this would make porting P1 to P2 more smooth.
Anyways, finish it, ruff like it is, document it so Ken can start going, and then you still can tweak it.
I personally like the new syntax way more then the old one, except I used PortB on the P1 a lot for bit moving.
The nice thing in P1 [constant..constant] is the inbuild bit reversal and shifting.
Comments
I just think he went off the rails with Spin2. I, also, fear that Parallax is going down the same path it did with P1 initially. Where it's only got a closed source x86/Windows only compiler for a new language that no one knows. At least this time around the community provided alternatives are coming online earlier, which helps the small group here on the forums that are in the know, but right now the official supported/backed path is x86 Spin2 compiler stuck into the same closed source Windows only PropTool P1 had.
This can't be what Ken and Parallax really wants... they can't be hoping for P2 success with just this as the launch offering.
Why is an interpreter a good idea? Can someone give me the top 3 pro's?
Pro's
* Code size ? ( P2 has loads of resources )
* ??
* ??
Cons
* Speed
* Confusing PASM Interop
* Highly constrained limited toy language
Well, code size is a pretty big one (moreso on P1 with 32K RAM, but still important). Less memory used by code -> more space for other stuff. And bytecode decoding is hardware-accelerated, so the speed is actually much better than a pure interpeter (like Spin1 has)
I wonder if fastspin can get a bytecode backend...
Wonder if that means you could bring in a object from say uSD card and then run it...
That might be interesting...
I kinda agree with David. Unless you have some kind of giant buffer that takes up most of HUB RAM, it's hard to imagine running out of space for code for usual applications.
But, I am often running out of RAM on P1, so it's definitely nice to have an option for the case of needing small code.
The needs vary by customer type. Most of our current commercial product development customers use Windows. Their purchasing horizon is quite long due to design cycles, a challenge when we can only grow the business with retained earnings while selling smaller numbers of prototype chips. The enthusiast, hobbyist, and educator use all three operating systems (Win, Mac, Linux) and have a much faster uptake in the early months with a good volume, helping us with the purchase of modules, boards and whatever else we produce around the P2 that we can sell in the near-term. These latter customers often become commercial product developers, too.
Our customer base has all types: commercial, educational, hobby, etc. This means they need support for operating systems of their choice.
But first, Chip simply needs to finish Spin2. Customers have booked many trays of P2 chips and they'll want to program them within a week or two. On Monday we take delivery of the final P2 prototypes and will have them mounted on P2 evaluation boards by the evening. Chip will be able to test the final A/D-D/A with the Rev C repairs and many subsequent, important and expensive activities will follow. We need to clear the way of interruptions and encourage Chip to get us closer to simply being able to program the P2 with Spin2.
Chip has now put most of his professional career into the Propeller 1 and 2. We certainly want open-source compilers that run on anything, but this exact moment in time isn't the right time to fully identify those solutions. I want them; you want them; we all want them. But we must first be able to program the P2 in Spin.
What we have at release isn't clear, nor have we had an extensive discussion about the possibilities. Many of us are busy running the business we currently have, not the one we will become. Changes lie ahead and we're looking forward to them, a whole bunch! I'll see Chip this afternoon and hope to come away with a clear understanding of the state of our compiler.
I can hear you say "but you've absolutely got to be thinking about this and have a plan - how could Parallax put years and millions into this effort and not have a plan?" It's coming soon.
Ken Gracey
Customers wanting to write programs for P2, will expect a language they are familiar with, or very easy porting from a language they are familiar with.
Comments above show Spin2 rather fails both those tests.
Existing right now are language users are familiar with :
fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler
but missing is a decent GUI debugger.
If you want rapid customer ramp, it would have been smarter to have Chip work on a good debugger so that all those languages users are familiar with, can SingleStep/Break/Watch - which other vendors offer.
However, Spin2 is designed to only run on P2, there are no plans for a PC version. Spin2 is also coded in x86 assembler, I'm not sure anyone will consider that 'open source'.
Given Spin2 has now separated so much from Spin1, it may have been smarter to use Python as the core language template, as Python is already out there, running on many platforms.
How would that even work? Assuming the core language paradigms stay the same (untyped except for hub access width, "object-based", static memory allocation, no metaprogramming) as they have to be for the fast bytecode approach, you can't just take the syntax, concepts and whatnot of a dynamic scripting language. You can kindof make the syntax look similiar (like Java is similiar to C++), but in that regard Spin(2) already is very similiar to Python, with the significant indentation and all. It's basically just missing the colons after IFs and similiar statements (which always annoy me in Python...) and the assignment operator is different.
You have been able to program the P2 in Spin (and an unofficial variant of Spin2) for a while now using FlexGui (FastSpin/etc.). If you guys (Chip especially) had worked with Eric, then official Spin2 could have been done a while ago.
I think the priority on Spin first is maybe not the best for long term. Yes you have existing customers that know and use Spin, but you have way more potential success with customers that will never touch Spin. That's where the official Parallax supported alternatives to Spin that are widely used (BASIC, C, C++, etc.) will be the win. PASM2 is where the real magic is, and those standard languages with inline PASM2 and libraries utilizing PASM2 is what you should want first. Especially since there was already a solution for existing customers that want Spin on P2.
I've got a fairly large code (2bit tiled gui) that I went about converting from Fastspin to Spin2.
The only major difference I found was the @ giving only relative addresses in Spin2 instead of absolute addresses.
The other things I found are things that FastSpin will probably change to match Spin2 (my guess).
Seems like the major differences between Spin1 and Spin2 are related to hardware changes, so could be expected.
I'm optimistic that Spin2 will turn out to be just fine. There are a lot of improvements compared to Spin1.
I'm really glad to have "=>" now being ">=", for example.
Seems the P2 hardware is more amenable to making this work though...
Ken has the right idea, given what Flexgui provides, the only remaining disaster scenario here is if Spin2 doesn't get finished.
It doesn't need to be perfect, tbh I don't care how I have to specify a range of pins or bits, so long as its possible and documented.
What new things does it have to do that fastspin doesn't do now? Genuine question, not trolling -- I'm going to have to make changes to fastspin, obviously. The current fastspin syntax is (almost) backwards compatible with Spin1 and works for both P1 and P2 as long as you stay away from some of the hardware intrinsics, so I guess I'm missing some things.
(I've been out of action for a while, trying to catch up...)
There's no theoretical reason it can't. I've tried to make the setup easy to add new backends, and there are already 2 (the C output code and the ASM one, which also has a binary option).
It could be fair bit of work though to make it exactly compatible with an existing bytecode though. For example it would be very difficult to implement inline assembly in Spin1 bytecode, and the result probably wouldn't work very well.
Now on the P2 there is no ROM SPIN code interrupter so is the new P2 SPIN program byte code or pure assembly. In which case the interrupter has to be loaded along with your SPIN2 program.
Mike
I hear you. BUT...
I have a tray of P2's due shortly. I've been hanging out for Spin2 because my intent has been to get my P1 OS running on P2. For that, I use Kye's magnificent FAT32 driver. I've written the P2 ASM SD driver section many months ago. As you know I wrote the SD boot code for the P2 ROM so this was a natural extension. Now here comes the "BUT". The FAT32 section is written in spin1 and all this time I've been expecting to get a Spin2 language/compiler that would compile the spin1 code. I'm NOT impressed!
Now, I could use Fastspin but...
Parallax doesn't seem inclined to support Eric
I want to use the interpreter, not compiled code.
While I tried a few times, it just didn't seem to resonate with me
The fact that the underlying spin2 interpreter is a completely different animal does not matter. What matters is the high level language. Spin1 was easy to learn. Spin2 is still unknown.
Spin2 needs to be called something other than Spin since it is a NEW language. It is definitely not a SPIN1 extension! And everyone is over new languages of the day.
There is ABSOLUTELY NO REASON that Spin2 could not be upwards compatible with Spin1. In fact, there is EVERY REASON that is should be upwards compatible with Spin1.
Re-use of Spin1 code for P2 - gives an almost instant library for P2
Shows users and potential users of Spin1 and/or Spin2 that it is an easy language supported by 2 micros.
Reinforces the "naysayers" we've been arguing against for the past 12-15 years that spin is here to stay, and a good base to start venturing into the micro world.
IMHO the only way Spin2 will succeed is if it is backwards compatible to Spin1. Otherwise there is ZERO reason to support it. It will become an orphan, and spin1 will also suffer as a result.
Python / Micropython
IMHO Chip's time would have been better spent in making python run on the P2. The language is the current flavor of the year and having that on P2 would have been far better tweeked than doing Spin2 which will only run on P2.
Python is quite similar to Spin. Given the current direction of Spin2, it would make more sense to me to abandon Spin2 right now, and put the effort in making micropython work for P2.
Anyone want a tray of P2's? I am so disheartened right now that I think it's time I moved on to something else.
I think Chip has made Spin2 smaller than COG sized, to give a little room for in-line assembler.
I've not seen comments yet on size/placement (COG/LUT/HUB) limits on in-line assembler in Spin2 ?
That's just an incredible amount of noise.
Shut up.
Luv U:)
Spin2 supports bitfields for ALL variables, not just I/O pin registers.
This is done by a '.[bitfield]' suffix after the variable, after a possible index.
SomeVariable.[bitfield]++
-or-
SomeLongVariable.byte[index].[bitfield]
-or-
long[pointer][index].[bitfield]
The conflict comes when Spin1 does something like this:
DIRA[23..16]
-or-
DIRA[8]
That last one would look like register[dira+8].
Things have grown and expanded in context. Rather than introduce syntax exceptions for backward compatibility, it seems plain to me that we just need to let Spin2 be what it really is, not a retrofit.
If this bitfield issue wouldn't have flared up so greatly, I'd already be onto the documentation, but the last few days have been spent thinking about how to best implement topbit..bottombit syntax.
And it seems Rayman has already implemented a largish program in Spin2, without any documentation, even.
Well @ersmith my guess is that it would make sense to build a RiscV backend, so fastspin can run on other computers...
You are doing us all a big favor with FasSpin and FlexGui. @"Roy Eltham" is working on the SimpleTools Libraries, that is super good news because it will get SimpleIDE and Blockly to compile with FastSpin.
Good Times ahead...
Mike
This is highly inappropriate for these forums.
If the difference between the average non-P1-specific Spin1 program and it's Spin2 equivalent is that little, why not just maek a "offical" source converter script? Like, turning DIRA[8] into DIRA.[8] whereever it comes up is just a simple regular expression. Same for the operator differences.
EDIT: I guess there's the much bigger problem that most Spin1 programs use WORDs to store pointers, which obviously won't fly. So you'd still need some non-IO-related rework.
No need to take offense where none was meant.
The angst around here in the last few days has been very high. A year ago, many of you were enthusiastic about discussing Spin2 features. Now, it's practically a hot-button issue. It's Spin1 compatibility or death! Or, it should be Python and/or C++, but not Spin, at all. There's no winning around here, lately.
I'm going to keep working on Spin2 because that's what I think the best course of action is. I have a really good feeling about it and I'm looking forward to getting it documented and writing code with it. I just need to see about this top..bottom stuff, first.
He told Cluso to shut up. Cluso deserves more respect than that.
Re: Spin2, I've already said basically the same thing several times, and you either didn't understand it or just don't want to do the compiler work (which is all it is). I know part of why you are hung up on this, it's because of how the compiler parses the code, and getting it to be properly context aware (which is what's needed to resolve the bitfield syntax issue) is a huge pain in 386 asm. It's even more of a pain because it's parse to build the symbol table, then parse and encode as you go, instead of the more typical parse into an AST then do everything from the AST, like build the symbol table, determine context, and then encode using all that built up stuff. Anyway, you do need to get Spin2 done, and at this point you should probably just make it what you think is best, because you don't have time to listen to us here anymore. Things will work out eventually.
@cgracey, yes, I also agree with @"Roy Eltham", get your Version finished and don't care about Spin1.
It needs to get out so @"Ken Gracey" can do his part to get P2 out there.
Since it is not in ROM you can tweak it later to accept more of the P1 syntax in the compiler, producing the same opcodes, say dira[1..5] will produce DIRA[1 addbits 5].
You might be able to Just accept the [low..high] and [high..low] with constants at compile time, for everything else one need to use the new syntax.
But this would make porting P1 to P2 more smooth.
Anyways, finish it, ruff like it is, document it so Ken can start going, and then you still can tweak it.
I personally like the new syntax way more then the old one, except I used PortB on the P1 a lot for bit moving.
The nice thing in P1 [constant..constant] is the inbuild bit reversal and shifting.
dirb:=whatever
a:=dirb[1...4]
b:=dirb[7..5]
Enjoy!
Mike