SPIN improvements
pedward
Posts: 1,642
I've been thinking about what SPIN needs to improve as a language. I've been thinking of hacking on the OSS compiler to add support for a few things. I saw in the P2 polishing thread there are others with a similar interest in improving SPIN.
I'd like this thread to be a place where people can enumerate their opinions on what needs to be added to SPIN.
I'm thinking about things that are compiler only, so the runtime doesn't need to change. This would essentially be SPINv1.5 and SPIN2.0 would coincide with the Prop 2 and that runtime. SPIN 1.5 would be constrained to only features that can be implemented with the existing runtime, so it would be compatible with the Prop1. SPIN2.0 would be exclusive to the Prop 2.
Some things I've discussed with others:
-Static type checking support (typing checking of parameters passed to methods, perhaps dynamic type conversion)
-Float (single precision) native 32bit support
-Strings
-Structures
-Name space (using the PERL :: notation?)
I'd like this thread to be a place where people can enumerate their opinions on what needs to be added to SPIN.
I'm thinking about things that are compiler only, so the runtime doesn't need to change. This would essentially be SPINv1.5 and SPIN2.0 would coincide with the Prop 2 and that runtime. SPIN 1.5 would be constrained to only features that can be implemented with the existing runtime, so it would be compatible with the Prop1. SPIN2.0 would be exclusive to the Prop 2.
Some things I've discussed with others:
-Static type checking support (typing checking of parameters passed to methods, perhaps dynamic type conversion)
-Float (single precision) native 32bit support
-Strings
-Structures
-Name space (using the PERL :: notation?)
Comments
That means anyone is at liberty to add, subtract, change anything they want in the Spin iterpreter to support whatever language features they like. You want unsigned longs? No problem.
I'm bit worried about forking the Spin compiler and adding/changing functionality. Last thing we want is a plethora of incompatible langage dialects. It would be great if there were only one "True Spin" maintained by Roy and Parallax. People could fork and hack whatever versions they like and if anything good comes out and they are accpeted those changes could be submitted back to the "True Spin" Backwards compatibility would have to be maintained.
There hasn't been an initiative from Ken at Parallax to do this, but everyone agrees that SPIN needs to be improve. I was taking the initiative to do this without someone asking. I want to see it get done, and I think this is the best way, just do it.
The beauty is that I'm just asking for suggestions, because I feel there are other people with more experience with SPIN that can contribute ideas. I don't necessarily need adopt all of the ideas provided, but I'm not naive enough to think that I know everything.
The spin2cpp preprocessor is designed to stand on its own and just take a file as input and a buffer of characters as output. It could probably be incorporated into Roy's compiler.
Granted, this approach may not accommodate every enhancement one might wish to make, but things like object name spaces and embedded floating point would not be an issue.
-Phil
Yes.
The preprocessor has to invoke the compiler. From the Prop Tool you could to it the way I do with a Perl/Tk script that attaches a button to the Prop Tool and, when invoked, sends the Prop Tool keystrokes and mouse commands. That's the way my '.debug processor works, which controls both the Prop Tool and PST and uses Propellent as the back-end compiler. Granted, it would be easier if the Prop Tool provided hooks for stuff like this, but it doesn't and probably never will.
-Phil
I mean, many enhancements have to take place at the 'pre-compilation' stage, right?
One possible downside to the preprocessor model is the reporting of compilation errors, since those will occur in the Core Spin target and have to be mapped back to the original code.
-Phil
I'm assuming the future is SimpleIDE and Roys compiler. Works fine for me so far.
I am currently working with Jeff Martin on a validation tool for the compiler. This is an important step in getting the compiler to be used as the "official" one. Once the validation tool is up and running, we can make sure my compiler fully works properly (as much as possibly anyway) in both success and failure (properly reporting errors) cases. I have talked with Jeff about substituting my compiler in for the current one in Prop Tool, it wouldn't be that hard, so it may happen (depending on Jeff's time which is rather packed). Anyway, we want to get the validation tool working first thing so that we can use it to validate stuff when we make changes and additions to the compiler. I know it adds another delay before getting new features, but it's the safest course of action for keeping the compiler stable.
Anyway, I was originally planning to use a pre-exisiting full preprocessor with my compiler, but there are several problems with that (primarily with Spin/PASM syntax confusing it). I've decided to just implement stuff similar to what BST does, and additionally adding #include. It's first on my list after the validation tool.
Roy
I don't know how BST does it, but it would be nice to be able to recognize a preprocessor directive (in a PRE section perhaps) that included one or more programs to be run in succession from the command line. Each program in the list would take the original source (or the output from the previous one) in STDIN, and produce the processed output on STDOUT (or errors in some standard form on STDERR). The compiler would get the output from the last program in the list.
-Phil
And thus was born Make...
-Phil
Here's an example of how my debug preprocessor might be called, absent the special treatment from the Prop Tool IDE button:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PRE debug.exe PUB start | i debug "Testing the Spin DEBUG function:\r\r" repeat i from -10 to 10 debug " The value of i is ", dec3 i, ", and i-squared is ", dec i*i, ".", #CRThe PRE section lists the command-line tool(s) required to process the source code before the compiler sees it. This would very much simplify the procedure I use now, which is to force the IDE to create an archive, extract the files from the archive into a separate directory, process them, then pass the TopLevel file to Propellent. Of course, it would not address the extra control I exert over PST, but that's beyond the scope of the example you asked for.
-Phil
Thanks for the example! As you say, multiple programs could be listed to form what Unix/Linux users would call a pipeline where the output of one feeds the input of the next culminating in the Spin compiler itself.
Also, I assume from my example that the preprocessor path is an environment variable, separately defined from the default source file path.
-Phil
I've attached a patch to the open source spin compiler to add the spin2cpp preprocessor. It supports #define of simple macros (no parameters), #include, #ifdef/#else/#endif etc. This isn't a complete patch, since it doesn't do the UTF-8 to PASCII translation (the preprocessor always outputs UTF-8, even from Unicode 16 input) and doesn't have command line support for defines yet. Both of those features will be straightforward to add. To use the patch, unzip the file in the root of your spin compiler source code (checked out from svn) and then apply the patch in patch.diff.
That looks very cool, but what happens on Mac and Linux? debug.exe is presumably a Windows tool, so in general it won't run on other platforms :-(. So the Spin source code would become host platform specific, which seems awkward.
A more general solution might be to have a scripting language built in to the PRE section itself, so the preprocessing could be specified in a platform independent manner. But that's getting very ambitious, I think!
-Phil
-Phil
Here is a usefull example of Phil's PRE directive.
PRE rm -rf * PUB start | i debug "Testing the Spin DEBUG function:\r\r" repeat i from -10 to 10 debug " The value of i is ", dec3 i, ", and i-squared is "You might guess I'm not taken with the idea.
To make the thing crossplatform and safe probably means making it more like a scripting language built into the Spin Source.
But then it starts to look like a built in make file.
Why not use Make like normal people?
I really think that is something that should be built into the IDE or whatever, and not the compiler/language.
ersmith,
I'll take a look at that patch this weekend (when I next work on the compiler project stuff). Seems like it should just drop in, if so then it should be available by Monday. Thanks!