Keep in mind that inline PASM in Spin will be hubexec execution mode. It can't really be anything else given the context. So it won't be full speed PASM as with COG/LUT execution (primarily with branches). Also, since starting hubexec incurs a delay to prime the fifo, short inline pasm will have a higher percentage of overhead cost.
This effect will favour skip-style coding, rather than using many short jumps.
Skip-style coding also benefits XIP code fetch.
... GCC already has a great optimizer and dead code elimination. Catching up to that in a brand new Spin compiler is going to take a bunch of work, but if the idea is to provide Spin for beginners and an initial offering while GCC is ramped up for P2 then I'm on board.
Dead code elimination should be less work, than getting "a great optimizer". I think already there in many alternate-spin paths ?
JasonDorie,
Yeah, hubexec will be faster than LMM, and a lot faster than bytecode or hybrids.
I don't think Spin being for beginners has to be mutually exclusive with Spin for advanced coders. Look at Arduino, that's C/C++ for beginners, but advanced coders can do more.
The key is the documentation/teaching tools, which parallax excels at (imho), and not requiring advanced features for typical use cases.
Having the compiler produce PASM from Spin will also have a lot of hubexec in it unless the entire Spin program can fit into one COGs local memory. Also, not sure how "optimized" this will be, writing an optimizing compiler for Spin to PASM is a giant task beyond just getting it to output PASM.
I hate to sound like a broken record, but that task is already done. If fastspin is considered defective for some reason then we can fix it (it is open source).
Or, if a completely new approach is desired then the GCC or clang back ends could be ported to P2 and a Spin front end put on them; that would have the advantage of giving C and C++ support pretty much for free.
I'm not entirely understanding the object limitations of Spin1, like Jason Dorie was talking about. Could someone explain what's needed, relative to what Spin1 already has? I want to understand this.
The example I gave related to the Elev8 project is this: I have an object called Prefs that I use to store global user preferences, read and write them to/from eeprom, and send/receive them over the serial connection. Any global user preference that needs to persist and be editable is managed by this object. Having a single object that managed its data in DAT space would mostly work in Spin - I could include the object in the various places it's used, and use the functions to read/write the DAT data and it would work.
In C++ I can create as many of these as I want, and pass them around. I generally only have one global one, with the single exception of when I'm reading one from somewhere, and don't want to overwrite the current one until I know the new one is correct (verified via checksum). In C++ this is trivial to manage - I pass a named object around as a pointer (or a reference, which is like a pointer, but has more restrictions).
In Spin, the only way to instantiate an object of a given type is like this:
ObjName : "Filename.spin"
So, you're including the code, and creating a local object all at once, and you can only use it from there.
What I want to be able to do is more like this:
TypeName : "Filename.spin"
pub DoSomething( TypeName : myObject ) | x, y
x := myObject.GetValue()
x *= 5
myObject.SetValue( x )
There's no way to do anything like that in Spin that I know of (at least that's intuitive or easy). You can't create a data structure and pass it around, referencing members by name in multiple objects, and you can't create an object (like an I2C object, or FDS) and pass that around to other things, call methods on it, etc. You can only *declare* it in your Spin code, and by declaring it you're essentially also creating it. Unless it uses all DAT members, in which case there's only ever one of them, which is also restrictive in some cases, but for different reasons.
Does that make sense? I'm hoping that gets it across - I have other examples, but I think this illustrates it fairly well. I can point you at a couple places in the Elev8 code where C/C++ made certain things quite a bit simpler than their Spin counterparts.
Jason, thanks for the example. I think I get it. I'm spooling back up to think about Spin2, still. I need to get all the concepts in my head, at once, so they become liquid again. It's been four years since I was last working on this.
I hate to sound like a broken record, but that task is already done. If fastspin is considered defective for some reason then we can fix it (it is open source).
Yup, fastspin seems a 'no brainer' of a starting point to me too....
That leaves just the byte-code back-end, which I think is all fastspin lacks ?
Keep in mind that inline PASM in Spin will be hubexec execution mode. It can't really be anything else given the context. So it won't be full speed PASM as with COG/LUT execution (primarily with branches). Also, since starting hubexec incurs a delay to prime the fifo, short inline pasm will have a higher percentage of overhead cost.
Having the compiler produce PASM from Spin will also have a lot of hubexec in it unless the entire Spin program can fit into one COGs local memory. Also, not sure how "optimized" this will be, writing an optimizing compiler for Spin to PASM is a giant task beyond just getting it to output PASM.
I get that full speed PASM isn't possible with hub exec, but I assume it's going to be as fast as LMM on the P1, and that'd be enough. P1 is in this weird space where LMM has amazing performance, but is hobbled by limited RAM, while CMM & Spin are memory conserving but the performance is orders of magnitude slower, and you can't mix the two.
If P2's tools support compilation to LMM/hubexec code, and it has enough RAM for large-ish programs, it'll be fine even if it's Spin. I don't care as much about the syntax of the language as I do about the feature set. GCC already has a great optimizer and dead code elimination. Catching up to that in a brand new Spin compiler is going to take a bunch of work, but if the idea is to provide Spin for beginners and an initial offering while GCC is ramped up for P2 then I'm on board.
Eric's spin2cpp already has some optimization as well as dead code elimination.
Can Spin2 please be saved as plain old ASCII (or UTF-8, since Unicode is necessary) instead of the UTF-16LE encoding that Prop Tool seems to use? UTF-8 is so much better than UTF-16LE, because the 7-bit ASCII parts of UTF-8 are just plain 7-bit ASCII, and only characters higher than 127 are weird, unlike UTF-16, where all characters are encoded weirdly.
In fact, can the OBEX upload page warn you when you try uploading UTF-16 files?
I thought of this because of this recent thread, where someone couldn't read anything from the OBEX because of the weird encoding.
Edited in response to JasonDorie's last post to be more clear that I'm complaining about UTF-16 and not Unicode in general.
Can Spin2 please be saved as plain old ASCII instead of the UTF-16LE encoding that Prop Tool seems to use? If Unicode is necessary, UTF-8 is so much better than UTF-16LE, because the 7-bit ASCII parts of UTF-8 are just plain 7-bit ASCII, and only characters higher than 127 are weird, unlike UTF-16, where all characters are encoded weirdly.
In fact, can the OBEX upload page warn you when you try uploading UTF-16 files?
I thought of this because of this recent thread, where someone couldn't read anything from the OBEX because of the weird encoding.
UTF-8 is required at a minimum for any of the Parallax custom font characters, which is probably why so much of the stuff in the Obex is Unicoded.
I hate to sound like a broken record, but that task is already done. If fastspin is considered defective for some reason then we can fix it (it is open source).
Yup, fastspin seems a 'no brainer' of a starting point to me too....
That leaves just the byte-code back-end, which I think is all fastspin lacks ?
We already have a perfectly good byte-code compiler in the form of openspin, so I don't think this is too pressing an issue. Again, if Spin2 is kept to "Spin1 + a few small changes" I'm sure it will be straightforward to get openspin to support it. I think Roy's done a good job with that code.
Thinking out loud - to get serious about this we need to NOT repeat certain things we've done before. NO custom fonts in ROM or in Propeller Tool, ...
I think that answers your question. Barring the circuit schematic symbols, though, being able to embed GIFs or BMPs in the source code would be a plus. An #image pragma with a link to an external file would probably suffice:
#image = "images/my_schematic.gif"
Then, depending upon the sophistication of the IDE, the image could be shown embedded at that location in the source code.
Another way to do it would be an IMG section, probably at the end of the program, with named image definitions given in base64 format. Then the actual images could be displayed with the #image pragma, followed by the image name from the IMG section.
Yet a third way would be the way it's done in HTML, which encompasses immediate images in base64, image files, and external URL references.
Can Spin2 please be saved as plain old ASCII instead of the UTF-16LE encoding that Prop Tool seems to use? If Unicode is necessary, UTF-8 is so much better than UTF-16LE,...
Thank you. I was just coming here to post about that.
Can we please adopt a sensible encoding for Spin 2 source?
As much as I despise Unicode, UTF-8 is the best option in the modern world.
Whilst we are at it, Unix/Linux line endings would be great.
Absolute disagreement. Tabs are faster to cursor through than spaces.
No they are not. Not in any editor that I used for years now.
Heathen.
Hmm...Little bit Christian, little bit Buddhist, little bit Pagan. Mostly atheist.
TABs on the other hand are the spawn of Satan himself. Sent to confuse us.
1) You never know how many spaces a TAB should be. Makes a mess of source code formatting when moved from machine to machine. Especially when intermixed with spaces.
2) Redundant. The space does everything you need from a TAB. It does not mess things up when moving code around.
The way Propeller Tool does "tabs" now is fine. You get to set the tab stops, and it inserts the chosen number of spaces when you hit TAB. No tab characters end up in the source code.
Let's allow them. Yeah, I know implementations vary, but that can be dealt with in just about any editor. There is no resolving that matter. Some will, some won't, some sometimes. Is what it is.
Re: ASCII & or UTF-8
YES! The special Parallax font in the PropTool is super spiffy, but... and we all know why. 'nuff said. This has implications for using a broad range of open dev tools as well as making an on-chip package sane and easy.
Re: Images
YES! #image [file]
Recently, I've been working across a number of disciplines, some computer code, fabrication, art, etc... And it's been a raw hassle. Total resource pig. So I simplified down everywhere I could.
ASCII (plain text, UTF-8) and Bitmaps
Those two are completely, utterly portable. Works everywhere. Works on just about anything. And, if we are eventually going to put something on the P2 itself, self-hosting style, these two are possible as well as practical. I keep including that case, not that it need be done at release, but that should it be done, it will have advantages in there being no dependencies, and or can be "done" and very stable.
I'm in favor of a simple "image [file]" spec being part of things. It can be ignored, but when not ignored, code can be presented in a compelling way very similar to how Prop Tool did it.
Despite the trouble inherent in PropTool, the fact that one can take a project, put all that is required for it into one file, and then use that is awesome! Extremely high value. For this image bit, we trade one file packaging, unless people want to do ASCII art, and we trade the custom font. Worth it, if you ask me. Very seriously worth it.
Downstream IDE / Special Tools kind of work may bear nice fruit. If we build that in right now, again it can be ignored, but it doesn't have to be. If it's there, I suspect it won't.
The rationale for this is so very often code alone isn't sufficient. It's almost always code + schematic + theory of operation. ASCII + Bitmaps can address all of that completely. It's not the most efficient, nor robust way, but it is useful and accessible on most anything, which I feel is worth it.
Re: Line encodings
I'm mixed about this. Both should be accepted by the Parallax supported tools. On that, you run them on whatever you can find and it works. Beyond that, it's bring your own editor, etc... and if people are there, they can manage whatever line encoding needs management. Seems this works about like tabs do. There is no resolving it.
Frankly, for both tabs and line encodings, shouldn't Parallax Education chime in? Whatever their experiences are matter. That's my preference.
HUB-EXEC will be much faster than LMM except in a few special cases.
LMM can only fetch and execute one instruction every 32 clocks.
Spin byte-code has some codes which are multiple bytes.
I believe we should aim to get spin1 bytecodes working on P2. This can be done separately to Chips SPIN2.
By doing this, we should be able to run a lot of P1 spin code. P1 PASM will have a lot of code that will translate easily, but there are a few gotchas. The first 64 instructions are basically/operationally the same, with the exception of the NR bit, and the C bit from shift/rotate instructions.
I am only interested in doing this, but only if it will be used. However, I seem to think its a dead horse.
The way Propeller Tool does "tabs" now is fine. You get to set the tab stops, and it inserts the chosen number of spaces when you hit TAB. No tab characters end up in the source code.
I have no idea about the Propeller Tool. Never used it. But that sounds fine to me.
I think it should use utf-8, we want to support other languages for comments at least.
Phil,
I like the #image or img tag idea a lot. The IDEs can display the image, or you can just view it yourself in whatever viewer you like. Much better than trying to build images from funky characters.
JasonDorie,
You are fine with being wrong, right? tab chars are an abomination, and should never be in any source code. You are the "heathen" for using tabs. :P Get a better editor/ide.
ersmith,
The only thing OpenSpin doesn't support that people seem hung up on is the @@@ thing. It has the preprocessor, unused method elimination (better than BSTs, producing smaller binaries), and extends spin in a few places (like symbol names can be 254 chars, and there can be more constants/public symbols). I'm currently working on a code cleanup pass, primarily aiming to reduce some of the redundancy that came from the port from x86 asm, but also refactoring some of the code gen stuff to be less hard coded. I've seen early versions of Chip's P2 version of the x86 ASM (what's inside of pnut) that has the P2 instruction encoding. Some of my refactoring will make it easier to incorporate that stuff.
Let's allow them. Yeah, I know implementations vary, but that can be dealt with in just about any editor.
Not quite.
Spin relies on white space indentation to delimit blocks.
If my source has spaces and tabs, my compiler may interpret them differently to what I see in the editor. This is not just a formatting issue it causes code to fail.
We already have a perfectly good byte-code compiler in the form of openspin, so I don't think this is too pressing an issue. Again, if Spin2 is kept to "Spin1 + a few small changes" I'm sure it will be straightforward to get openspin to support it. I think Roy's done a good job with that code.
ersmith,
The only thing OpenSpin doesn't support that people seem hung up on is the @@@ thing. It has the preprocessor, unused method elimination (better than BSTs, producing smaller binaries), and extends spin in a few places (like symbol names can be 254 chars, and there can be more constants/public symbols). I'm currently working on a code cleanup pass, primarily aiming to reduce some of the redundancy that came from the port from x86 asm, but also refactoring some of the code gen stuff to be less hard coded. I've seen early versions of Chip's P2 version of the x86 ASM (what's inside of pnut) that has the P2 instruction encoding. Some of my refactoring will make it easier to incorporate that stuff.
All of which sounds good.
Hmm, given all the above, isn't the obvious question why does Chip not focus on FPGA Hardware testing, and encourage the guys with rubber on the road, to get P2 versions of these existing (non X86 ASM) tools up ?
I think Chip is committed to make @ the be-all/end-all spec for the address of an entity, everywhere in the program (even in the DAT section). This will obviously require an extra compiler pass, but the end result will be way less confusing than what we have now.
Problem is, that's a very blunt tool that will break existing code bases.
TABs should be deprecated, but any users code should still compile just as it did before.
jmg,
I spent a fair amount of time trying to get @@@ working, and it's not possible with the current way code is compiled in OpenSpin(Chip's x86). It requires changing already compiled code after the fact (to fix up address values), and having full knowledge of all objects and their locations in memory after compiling and distilling. So it needs to modify the existing passes, and then add an additional pass to do the fix ups. Or rework how compiling works altogether.
The first Ptr example must know that object's PUB list, including that object's OBJ and VAR base. This would allow an object declared outside of the current scope to be fully used, once pointed to, as if it were in the current scope.
The second Ptr example must know a certain PUB within an object, including that object's OBJ and VAR base. This would allow for a more compact usage of a specific method. The only thing you need to know is how many parameters to give it. This would be handy for making generic number-printing methods, for example, where the output is indirect.
The third example is a means for an object to index to a different instance of its VARs. InstanceNumber would probably best be a relative value, since a certain object may be instantiated in several different arrays within an entire application. If you called methods at the base of the object array and passed the InstanceNumber to them, your relative values could range from 0+.
The syntax and mechanics of all this are indeterminate, yet, but does this look comprehensive?
I think Chip is committed to make @ the be-all/end-all spec for the address of an entity, everywhere in the program (even in the DAT section). This will obviously require an extra compiler pass, but the end result will be way less confusing than what we have now.
Comments
Skip-style coding also benefits XIP code fetch.
Yeah, hubexec will be faster than LMM, and a lot faster than bytecode or hybrids.
I don't think Spin being for beginners has to be mutually exclusive with Spin for advanced coders. Look at Arduino, that's C/C++ for beginners, but advanced coders can do more.
The key is the documentation/teaching tools, which parallax excels at (imho), and not requiring advanced features for typical use cases.
I hate to sound like a broken record, but that task is already done. If fastspin is considered defective for some reason then we can fix it (it is open source).
Or, if a completely new approach is desired then the GCC or clang back ends could be ported to P2 and a Spin front end put on them; that would have the advantage of giving C and C++ support pretty much for free.
Jason, thanks for the example. I think I get it. I'm spooling back up to think about Spin2, still. I need to get all the concepts in my head, at once, so they become liquid again. It's been four years since I was last working on this.
That leaves just the byte-code back-end, which I think is all fastspin lacks ?
In fact, can the OBEX upload page warn you when you try uploading UTF-16 files?
I thought of this because of this recent thread, where someone couldn't read anything from the OBEX because of the weird encoding.
Edited in response to JasonDorie's last post to be more clear that I'm complaining about UTF-16 and not Unicode in general.
UTF-8 is required at a minimum for any of the Parallax custom font characters, which is probably why so much of the stuff in the Obex is Unicoded.
We already have a perfectly good byte-code compiler in the form of openspin, so I don't think this is too pressing an issue. Again, if Spin2 is kept to "Spin1 + a few small changes" I'm sure it will be straightforward to get openspin to support it. I think Roy's done a good job with that code.
Eric
I think that answers your question. Barring the circuit schematic symbols, though, being able to embed GIFs or BMPs in the source code would be a plus. An #image pragma with a link to an external file would probably suffice:
Then, depending upon the sophistication of the IDE, the image could be shown embedded at that location in the source code.
Another way to do it would be an IMG section, probably at the end of the program, with named image definitions given in base64 format. Then the actual images could be displayed with the #image pragma, followed by the image name from the IMG section.
Yet a third way would be the way it's done in HTML, which encompasses immediate images in base64, image files, and external URL references.
-Phil
Can we please adopt a sensible encoding for Spin 2 source?
As much as I despise Unicode, UTF-8 is the best option in the modern world.
Whilst we are at it, Unix/Linux line endings would be great.
Oh, and any use of TAB should be a syntax error.
Absolute disagreement. Tabs are faster to cursor through than spaces. Heathen.
TABs on the other hand are the spawn of Satan himself. Sent to confuse us.
1) You never know how many spaces a TAB should be. Makes a mess of source code formatting when moved from machine to machine. Especially when intermixed with spaces.
2) Redundant. The space does everything you need from a TAB. It does not mess things up when moving code around.
Just say no to TABs.
-Phil
Let's allow them. Yeah, I know implementations vary, but that can be dealt with in just about any editor. There is no resolving that matter. Some will, some won't, some sometimes. Is what it is.
Re: ASCII & or UTF-8
YES! The special Parallax font in the PropTool is super spiffy, but... and we all know why. 'nuff said. This has implications for using a broad range of open dev tools as well as making an on-chip package sane and easy.
Re: Images
YES! #image [file]
Recently, I've been working across a number of disciplines, some computer code, fabrication, art, etc... And it's been a raw hassle. Total resource pig. So I simplified down everywhere I could.
ASCII (plain text, UTF-8) and Bitmaps
Those two are completely, utterly portable. Works everywhere. Works on just about anything. And, if we are eventually going to put something on the P2 itself, self-hosting style, these two are possible as well as practical. I keep including that case, not that it need be done at release, but that should it be done, it will have advantages in there being no dependencies, and or can be "done" and very stable.
I'm in favor of a simple "image [file]" spec being part of things. It can be ignored, but when not ignored, code can be presented in a compelling way very similar to how Prop Tool did it.
Despite the trouble inherent in PropTool, the fact that one can take a project, put all that is required for it into one file, and then use that is awesome! Extremely high value. For this image bit, we trade one file packaging, unless people want to do ASCII art, and we trade the custom font. Worth it, if you ask me. Very seriously worth it.
Downstream IDE / Special Tools kind of work may bear nice fruit. If we build that in right now, again it can be ignored, but it doesn't have to be. If it's there, I suspect it won't.
The rationale for this is so very often code alone isn't sufficient. It's almost always code + schematic + theory of operation. ASCII + Bitmaps can address all of that completely. It's not the most efficient, nor robust way, but it is useful and accessible on most anything, which I feel is worth it.
Re: Line encodings
I'm mixed about this. Both should be accepted by the Parallax supported tools. On that, you run them on whatever you can find and it works. Beyond that, it's bring your own editor, etc... and if people are there, they can manage whatever line encoding needs management. Seems this works about like tabs do. There is no resolving it.
Frankly, for both tabs and line encodings, shouldn't Parallax Education chime in? Whatever their experiences are matter. That's my preference.
LMM can only fetch and execute one instruction every 32 clocks.
Spin byte-code has some codes which are multiple bytes.
I believe we should aim to get spin1 bytecodes working on P2. This can be done separately to Chips SPIN2.
By doing this, we should be able to run a lot of P1 spin code. P1 PASM will have a lot of code that will translate easily, but there are a few gotchas. The first 64 instructions are basically/operationally the same, with the exception of the NR bit, and the C bit from shift/rotate instructions.
I am only interested in doing this, but only if it will be used. However, I seem to think its a dead horse.
Phil,
I like the #image or img tag idea a lot. The IDEs can display the image, or you can just view it yourself in whatever viewer you like. Much better than trying to build images from funky characters.
JasonDorie,
You are fine with being wrong, right?
ersmith,
The only thing OpenSpin doesn't support that people seem hung up on is the @@@ thing. It has the preprocessor, unused method elimination (better than BSTs, producing smaller binaries), and extends spin in a few places (like symbol names can be 254 chars, and there can be more constants/public symbols). I'm currently working on a code cleanup pass, primarily aiming to reduce some of the redundancy that came from the port from x86 asm, but also refactoring some of the code gen stuff to be less hard coded. I've seen early versions of Chip's P2 version of the x86 ASM (what's inside of pnut) that has the P2 instruction encoding. Some of my refactoring will make it easier to incorporate that stuff.
Spin relies on white space indentation to delimit blocks.
If my source has spaces and tabs, my compiler may interpret them differently to what I see in the editor. This is not just a formatting issue it causes code to fail.
Madness. Sure there is. Make TABs a syntax error. So easy.
All of which sounds good.
Hmm, given all the above, isn't the obvious question why does Chip not focus on FPGA Hardware testing, and encourage the guys with rubber on the road, to get P2 versions of these existing (non X86 ASM) tools up ?
IIRC the syntax of that was up for change, but how hard it is to add the operation ?
-Phil
TABs should be deprecated, but any users code should still compile just as it did before.
But there is no way Spin code will compiler under Spin 2 anyway.
I spent a fair amount of time trying to get @@@ working, and it's not possible with the current way code is compiled in OpenSpin(Chip's x86). It requires changing already compiled code after the fact (to fix up address values), and having full knowledge of all objects and their locations in memory after compiling and distilling. So it needs to modify the existing passes, and then add an additional pass to do the fix ups. Or rework how compiling works altogether.
I see three needs:
PtrToSpecificObject.ObjectMethodName(params) PtrToGenericObjectAndMethod(params) VarName[[InstanceNumber]]The first Ptr example must know that object's PUB list, including that object's OBJ and VAR base. This would allow an object declared outside of the current scope to be fully used, once pointed to, as if it were in the current scope.
The second Ptr example must know a certain PUB within an object, including that object's OBJ and VAR base. This would allow for a more compact usage of a specific method. The only thing you need to know is how many parameters to give it. This would be handy for making generic number-printing methods, for example, where the output is indirect.
The third example is a means for an object to index to a different instance of its VARs. InstanceNumber would probably best be a relative value, since a certain object may be instantiated in several different arrays within an entire application. If you called methods at the base of the object array and passed the InstanceNumber to them, your relative values could range from 0+.
The syntax and mechanics of all this are indeterminate, yet, but does this look comprehensive?
It must be done. Roy will do it.