I really hope that Chip and Jeff are able to produce a Spin dev environment entirely in-house, like they did with the Propeller Tool.
Perhaps, but do you really want that coded in x86 Assembler ?
'entirely in-house' also has its own bottle-necks and risks.
Of course, there is nothing preventing Chip and Jeff taking the already existing, open-source Spin2cpp as a starting point, and thereby finishing faster....
A commercial benefit of a software flow like Spin2cpp than can emit both P1 and P2 ASM, is it extends the life of the P1, which can be sold today.
Parallax do need to ensure the P1 life extends to well after P2 eventual release, as well as cover the risk of P2 never being released.
IIRC Chip does have a P2 Spin kernel mostly done, but lagging somewhat behind the P2 opcode changes ?
Once the P2 hardware is signed off, one compelling feature that would be great to add to such a P2 Spin kernel, would be source-level debug support.
That is one are where Parallax lag a long way behind the alternatives.
#include <propeller.h>
const int LED = 1;
void main(void)
{
DIRA |= LED;
while(1)
OUTA ^= LED;
}
I've always thought these kinds of "look how simple it is!" tests are a bit silly, because the triviality of the example means that it's simple to implement in just about any language
Really? I have only been programming for 32 years and your code is gobbledegook to me, whereas my PropBASIC example is, no doubt, understandable by pretty much anyone.
How come you didn't list your generated PASM code, BTW? I'm betting that PropBASIC kicked butt.... :-D
I do hope that you'll start with a formal grammar for Spin this time, though. That's an essential part of defining the language. Moreover, working from such a grammar, makes writing a recursive-descent parser that much easier.
Perhaps, but do you really want that coded in x86 Assembler ?
Oh, for heavens sake! Who said that would happen again? Chip's a smart and adaptable guy. I'm sure he'll find a dev platform for Spin that doesn't rely on Windows -- or even the X86, for that matter.
Really? I have only been programming for 32 years and your code is gobbledegook to me, whereas my PropBASIC example is, no doubt, understandable by pretty much anyone.
How come you didn't list your generated PASM code, BTW? I'm betting that PropBASIC kicked butt.... :-D
Because I'm at work, and I simply typed it into the forum, not the compiler. Also, yeah, C expression syntax can look like gobbledegook if you're not used to it, but it's pretty simple when you're fluent. It's also almost identical in Spin. It could easily have been a little more readable, but compiled to PASM in COGC mode it should generate the same output as the PropBasic version.
...For example, if SetPinDirection() and TogglePin() are defined by the standard Prop libs, or elsewhere in your own code, it could look like this:
I see some things are not tagged as optimize, such as the auto-inlines Jason mentioned.
Auto-inline generally goes much further than that. If the generated output code is more efficient to represent inline than with a function call, it should be inlined regardless, unless that's disabled for debugging reasons. (we don't get debugging on the Prop, so this is moot). If the cache-flush hit from doing a call / push / pop / ret sequence is more costly than the extra instruction cost for inlining slightly larger code, then it "should" be inlined. If it's an inner loop where performance is critical, it might be inlined if the added code cost is below some threshold. Etc, etc.
If you have a helper function in one file that is:
PUB TogglePin( pin )
OUTA[pin] ^= 1
It costs more to call the function than it would cost to just insert the code in-line. It has nothing to do with how often it's called, it's about how much performance you lose by doing this:
push stack frame
push return address
push pin argument
call TogglePin function (function toggles the pin, returns to pushed address)
pop stack frame
This is a trivial example, but it's the kind of thing LOTS of people do to improve code readability, and the current Spin compiler does no optimization whatsoever for these. Simple Set() / Get() methods on objects become performance pigs because of this, and there's really no need for it.
I really hope that Chip and Jeff are able to produce a Spin dev environment entirely in-house, like they did with the Propeller Tool. Without citing examples, I feel that the latter has maintained an integrity that some of the various outsourced tools have not -- and cannot. It's just the nature of outsourcing that contractors get busy with other stuff and can't always respond to Parallax's needs when called upon or hew to Parallax's priorities. I'm one of those people, so I understand the problem.
-Phil
I would really like to see the official Spin compiler from Parallax written in a language other than x86 assembly language.
Lots of good ideas here, got me thinking. Maybe adding Linux to my Elev-8
Does anyone know if there is enough weight capacity on the Elev-8 for a hard drive? Maybe a networking card too?
I wasn't worried about the cooling fans for processor and GPU, because I figured we could just repurpose couple of the copter blades for that.
From wikipedia: "An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints."
From Parallax: "The Propeller microcontroller is designed to perform multiple tasks simultaneously, and without the need for interrupts or the dictates of an onboard operating system."
From me: "To the degree Python is adapted for embedded use, it is no longer Python"
Dorie and Mickster are real engineers. The rest of you are software developers.
Delphi is really Pascal isn't it? It wouldn't be my first choice but it would be better than x86 assembly language.
Could the Spin compiler be written in Spin? If it could, you could compile it with spin2cpp to generate code that runs under Windows, Macintosh, Linux and it could also potentially allow it to run directly on the P2 to generate a self-hosting system.
Could the Spin compiler be written in Spin? If it could, you could compile it with spin2cpp to generate code that runs under Windows, Macintosh, Linux and it could also potentially allow it to run directly on the P2 to generate a self-hosting system.
I hope you're kidding. That path leads to madness.
I would really like to see the official Spin compiler from Parallax written in a language other than x86 assembly language.
Yes. Didn't someone already do a HLL Spin derived from the ASM sources ? Can't recall what language ?
Of course Spin2cpp is a C version, and that does exist in open source form, right now...
PropBASIC is coded in FreePascal, effectively similar to Delphi, but more open.
For command line tools, the same source can often compile in both Delphi or FreePascal.
Could the Spin compiler be written in Spin? If it could, you could compile it with spin2cpp to generate code that runs under Windows, Macintosh, Linux and it could also potentially allow it to run directly on the P2 to generate a self-hosting system.
Anything is possible... - and notice this path requires that Spin2cpp is co-operated with closely.
Numerous other languages self-host, so this is not a rare thing.
The Oberon compiler in Project Oberon, is written in Oberon.
Not likely, without better string-handling primitives.
-Phil
Well, x86 assembly language doesn't have particularly good string handling so I don't see how Spin would be worse if it came to a choice between the two.
Didn't someone already do a HLL Spin derived from the ASM sources ? Can't recall what language ?
Yes, it's OpenSpin, written in C++ by Roy Eltham, a fully vetted and tested compiler for compatibility with Chip's x86 ASM version.
-Phil
I had assumed that OpenSpin would be the basis for the P2 version of Spin but it is my understanding that Chip again plans to write the P2 Spin compiler in x86 assembly language and after that is done Roy will again translate that into C++. I would think it would be better to have Chip act as the language architect and have Roy or someone else write the official compiler in C++ or some other high-level language.
If the formal grammar is in place first then Spin can be written in Logo as far as I'm concerned. Or Whitespace. The problem with implementing the language before the grammar is that it's a near certainty that it then can't be formalized, which means that there will be potential for ambiguities within the language.
If a grammar exists it's nearly trivial to implement and re-implement in whatever you prefer.
If the formal grammar is in place first then Spin can be written in Logo as far as I'm concerned. Or Whitespace. The problem with implementing the language before the grammar is that it's a near certainty that it then can't be formalized, which means that there will be potential for ambiguities within the language.
If a grammar exists it's nearly trivial to implement and re-implement in whatever you prefer.
Yes, a formal language design would be helpful including both the language syntax and semantics.
My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
And if I understand correctly, this is where ViewPort shines but I never hear much of anyone using it.
Above is a link to the 30-day demo version in my DropBox.
Anyone heard anything about Hanno Sander since his cycling accident, BTW?
My biggest gripe with Spin is that it doesn't easily lend itself to global objects - For example, if I want 5 different objects that all use the serial output for debugging, I have to jump through some strange hoops to make that happen. C/C++ have no trouble with this at all, but require the use of headers, so there's a little more typing involved.
And if I understand correctly, this is where ViewPort shines but I never hear much of anyone using it.
Above is a link to the 30-day demo version in my DropBox.
Anyone heard anything about Hanno Sander since his cycling accident, BTW?
So, how do you formalize syntax? I understand that this would simplify parsing and allow a lot of standardized tools to play roles within the compiler. What I fear is that it would mandate largish text constructs in little corners of the language where maybe a colon character could have been used.
My thought has been to get Spin2 going on my current platform (x86) and then get it working in Spin, itself, making the final departure from x86.
So, how do you formalize syntax? I understand that this would simplify parsing and allow a lot of standardized tools to play roles within the compiler. What I fear is that it would mandate largish text constructs in little corners of the language where maybe a colon character could have been used.
My thought has been to get Spin2 going on my current platform (x86) and then get it working in Spin, itself, making the final departure from x86.
That sounds like a good plan. It would be nice to be able to run the same version of Spin self-hosted on the P2 as we run on the PC under Windows, Mac, and Linux. Do you plan to write two code generators, one for x86 and one for P2?
So, how do you formalize syntax? I understand that this would simplify parsing and allow a lot of standardized tools to play roles within the compiler. What I fear is that it would mandate largish text constructs in little corners of the language where maybe a colon character could have been used.
My thought has been to get Spin2 going on my current platform (x86) and then get it working in Spin, itself, making the final departure from x86.
That sounds like a good plan. It would be nice to be able to run the same version of Spin self-hosted on the P2 as we run on the PC under Windows, Mac, and Linux. Do you plan to write two code generators, one for x86 and one for P2?
So, how do you formalize syntax? I understand that this would simplify parsing and allow a lot of standardized tools to play roles within the compiler. What I fear is that it would mandate largish text constructs in little corners of the language where maybe a colon character could have been used.
My thought has been to get Spin2 going on my current platform (x86) and then get it working in Spin, itself, making the final departure from x86.
That sounds like a good plan. It would be nice to be able to run the same version of Spin self-hosted on the P2 as we run on the PC under Windows, Mac, and Linux. Do you plan to write two code generators, one for x86 and one for P2?
I hadn't thought that far, but it could be done.
Sounds like it will be an interesting project. Let me know if you'd like any help with it.
I assume "formal syntax" just means that there's a proper spec for what the language syntax follows and definitive rules for how to parse it without ambiguity.
Context-free grammar goes even further, and is a definitive set of rules whereby you can clearly decide what a given token is (or isn't) based on past context and a single future token, without having to have "compiled" what you've seen so far. It makes it easier to compile as you can build a finite state machine from the syntax automatically (this is what Yacc / Lex do, rather unreadably).
C is context free, C++ isn't, though I can't remember exactly why.
Comments
Perhaps, but do you really want that coded in x86 Assembler ?
'entirely in-house' also has its own bottle-necks and risks.
Of course, there is nothing preventing Chip and Jeff taking the already existing, open-source Spin2cpp as a starting point, and thereby finishing faster....
A commercial benefit of a software flow like Spin2cpp than can emit both P1 and P2 ASM, is it extends the life of the P1, which can be sold today.
Parallax do need to ensure the P1 life extends to well after P2 eventual release, as well as cover the risk of P2 never being released.
IIRC Chip does have a P2 Spin kernel mostly done, but lagging somewhat behind the P2 opcode changes ?
Once the P2 hardware is signed off, one compelling feature that would be great to add to such a P2 Spin kernel, would be source-level debug support.
That is one are where Parallax lag a long way behind the alternatives.
Really? I have only been programming for 32 years and your code is gobbledegook to me, whereas my PropBASIC example is, no doubt, understandable by pretty much anyone.
How come you didn't list your generated PASM code, BTW? I'm betting that PropBASIC kicked butt.... :-D
+1
-Phil
Because I'm at work, and I simply typed it into the forum, not the compiler. Also, yeah, C expression syntax can look like gobbledegook if you're not used to it, but it's pretty simple when you're fluent. It's also almost identical in Spin. It could easily have been a little more readable, but compiled to PASM in COGC mode it should generate the same output as the PropBasic version.
...For example, if SetPinDirection() and TogglePin() are defined by the standard Prop libs, or elsewhere in your own code, it could look like this:
#include <propeller.h> void main(void) { SetPinDirection(0, PIN_OUTPUT); while(1) TogglePin(0); }Auto-inline generally goes much further than that. If the generated output code is more efficient to represent inline than with a function call, it should be inlined regardless, unless that's disabled for debugging reasons. (we don't get debugging on the Prop, so this is moot). If the cache-flush hit from doing a call / push / pop / ret sequence is more costly than the extra instruction cost for inlining slightly larger code, then it "should" be inlined. If it's an inner loop where performance is critical, it might be inlined if the added code cost is below some threshold. Etc, etc.
If you have a helper function in one file that is:
It costs more to call the function than it would cost to just insert the code in-line. It has nothing to do with how often it's called, it's about how much performance you lose by doing this:
This is a trivial example, but it's the kind of thing LOTS of people do to improve code readability, and the current Spin compiler does no optimization whatsoever for these. Simple Set() / Get() methods on objects become performance pigs because of this, and there's really no need for it.
I wasn't worried about the cooling fans for processor and GPU, because I figured we could just repurpose couple of the copter blades for that.
From wikipedia: "An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints."
From Parallax: "The Propeller microcontroller is designed to perform multiple tasks simultaneously, and without the need for interrupts or the dictates of an onboard operating system."
From me: "To the degree Python is adapted for embedded use, it is no longer Python"
Dorie and Mickster are real engineers. The rest of you are software developers.
It is Pascal. I mentioned it because I think that's what the original PropTool was written in, if I'm not mistaken.
I hope you're kidding. That path leads to madness.
Both excellent, forward looking choices.
-Phil
Of course Spin2cpp is a C version, and that does exist in open source form, right now...
PropBASIC is coded in FreePascal, effectively similar to Delphi, but more open.
For command line tools, the same source can often compile in both Delphi or FreePascal.
Anything is possible... - and notice this path requires that Spin2cpp is co-operated with closely.
Numerous other languages self-host, so this is not a rare thing.
The Oberon compiler in Project Oberon, is written in Oberon.
Yes, but Spin for P2 is likely to have those better string handing features.
-Phil
Yes.
If a grammar exists it's nearly trivial to implement and re-implement in whatever you prefer.
And if I understand correctly, this is where ViewPort shines but I never hear much of anyone using it.
Above is a link to the 30-day demo version in my DropBox.
Anyone heard anything about Hanno Sander since his cycling accident, BTW?
http://onerobot.org/products/viewport/
Edit:
Oh, I see that there was an update last March. v4.82 is what I have been using because v4.89 had issues with PropBASIC. Need to test this v4.9 myself.
http://onerobot.org/products/viewport/download/
I emailed Hanno back in November after the second earthquake. He and his family were fine.
He has a new web site:
www.robotmagic.org
My thought has been to get Spin2 going on my current platform (x86) and then get it working in Spin, itself, making the final departure from x86.
I hadn't thought that far, but it could be done.
Context-free grammar goes even further, and is a definitive set of rules whereby you can clearly decide what a given token is (or isn't) based on past context and a single future token, without having to have "compiled" what you've seen so far. It makes it easier to compile as you can build a finite state machine from the syntax automatically (this is what Yacc / Lex do, rather unreadably).
C is context free, C++ isn't, though I can't remember exactly why.