I'm looking forward to having ZiCog running 8 times faster and without the need for external RAM. Complete with on board VT100 screen. It will soon be time for another CP/M in a matchbox design:)
Clearly compilers targeting LMM are getting an unfair advantage over bytecode interpreters like Zog. Unfair I say:)
Presumably existing PASM code, and hence existing LMM kernels will run unchanged (or almost unchanged) on the Prop II without the benefits of the available speed ups. So we wont have to wait for new code generators in order to use Catalina on the Prop II.
I tried to clarity this during the webinar, but didn't get an entirely satisfactory answer. Without the final details, I think it is too early to say that this is true. Some instructions do seem to change. But I could have misunderstood.
My understanding is that a lot of the PASM code should just be able to recompile for Prop2, however there are some changes needed due to how the registers (like cnt, ina, outa, etc.) are not directly accessed in prop 2, but instead have instructions to read/write them. It wouldn't be very hard to make a program that can automatically translate PASM from Prop 1 to Prop 2 form.
Heater, you should be able to get significant performance gains for Zog (over the raw clock speed boost and 4:1 instruction latency differences) due to the new instructions and registers. I'm sure more details will become available soon. Of course, the C LMM kernels will be able to get significant gains from these also. Especially in stack related stuck (smaller code, and faster).
Spin on the Prop 2 will be faster than just the raw clock speed and instruction latency differences also.
Any help with creating a faster stack in HUB on the Prop II might help Zog a lot. Faster external RAM or FLASH access for code would be a huge boost especially if we ever get to move data and stack into HUB. In that situation Zog may still give any LMM targeted compiler a run for it's money due to the lower code memory bandwidth requirements. Zog is out out of the running yet:)
At one time Chip mentioned the possibility of using the new cog fifo as a stack. This is either 512B or 2KB (128 or 512 longs). This would be a huge advantage to lots of code
Here is a quote from williamk a new user of XMOS products on the xcore forum:
So far I couldn't get anything to work, as I'm not a big coder, and I think I got too much used to the Arduino IDE and the Xmos IDE is making me nuts...
This is not uncommon. I've been programming since The Ark and had to deal with a lot worse tools than that but Eclipse makes me nuts as well. Then there is getting Eclipse and the Android tool chain running, what a palaver. This stuff is really not a good intro to programming for the uninitiated.
Where Eclipse wins is when you have fully integrated a whole slew of tools like debugger, timing analyser, signal trace viewer etc etc. But this is hardly stuff for the raw beginner.
I think that old hands tend to forget how much they know. I minor problem for them can be overcome almost instinctively, for a beginner that same minor problem can be a black hole they fall into and perhaps give up the whole idea.
I want to come back on the command-line tool option.
I'm somewhere inbetween a casual programmer and a professional (as I had several jobs where the main work was to code in high level languages but not in the most common C/C++.
The easyness of the propeller-tool results from beeing ONE SINGLE exe-file. Install FTDI-Driver install propeller-tool and you are ready to start coding. Hit F11 and your code is running.
Can you guarantee that a combination of a commandline-tool and an IDE will be THAT simple to install even on a quite MISconfigured PC from an amateur?
@Leon: you mentioned that for YOU installing eclipse worked always well. Now you seem to be a very professional code-developper.
To me if a professional says "no problem it always runs through" is almost an argument AGAINST easyness. As an expert you just ARE blind for
newbee problems. The big amount of knowledge you have creates this blindness. You have to add another kind of knowledge to become seeing again for this special kind of problems: If you have worked with a lot of newbees and all their crazy ideas how to do things in a stupid way.
Will there be a effort to make it as foolproof as possible? IMO opinion a single exe is inherent a lot of more foolproof than a tool-chain just because there are more parts than can be mixed up.
best regards
Stefan
P.S.: people that like to explore how things work and solve riddels as a detective will not complain about a complicated installation and configuration process. To such people this is a source of pleasure.
To the people that don't like it it is a source of pain. This has nothing to do with the fact that you need a certain amount of knowledge to develop software. The question is how much knowledge do you need to now to
reach a target of a certain complexity and how easy or difficult is it to get these knowledge?
Why not? Surely it's gonna get packaged up, just like Prop I was. Andre' at the least, will knock out a game dev system, and some demos that would appeal to the exact same people Prop I did. Now, they could use the Prop Tool, assuming it gets a Prop II update, or the product of this project. Depends on what attracts them, and how it's packaged, and where the code is, right?
This effort does not eliminate an expansion of our current Windows Propeller Tool to support Propeller 2. We will need these tools to program the Propeller before any GCC efforts are completed. Some customers may not be interested in a GCC set of tools.
I don't see how you can read this any other way than that Parallax intend to provide a Propeller Tool for the Prop II.
I still don't see many beginners using the Propeller 2.
The propellers (I & II) are much easier to use than their competitors. They are ideal for beginners. Most of the arguments we have in these forums are about how to make them more appealing to non-beginners. The Prop II, with its improved support for traditional languages, will probably achieve that - but this will not reduce its appeal to beginners.
Chip just said the Prop II will have a minimum boot loader, allowing fetching of whatever environment from a external storage device. Seems to me, a SPIN environment, like we have now, is not only possible, but not constrained by the design limits of ROM in Prop I. Beginner environments then, will happen, without impacting "pro" environments.
I'm very pleased by this, with the worry of fragmentation. Probably that's unavoidable on this larger scale.
Have you read the whole thread? From the very first post by Ken ...
The propellers (I & II) are much easier to use than their competitors. They are ideal for beginners. Most of the arguments we have in these forums are about how to make them more appealing to non-beginners. The Prop II, with its improved support for traditional languages, will probably achieve that - but this will not reduce its appeal to beginners.
Ross.
I have followed the whole thread but it's been going for a long time, and I'd forgotten that!
Actually, I would expect yes. With the changes Chip announced, the chip can be setup in a lot of interesting ways. It will have a boot ROM, that fetches everything else. Coupla scenarios:
1. Use Prop Tool, SPIN, PASM, LMM as it's done today, only get LMM sorted and do fun stuff like inline PASM, via LMM in SPIN. People would like that at lot, and not being constrained by resources and speed, like Prop I currently is, means framing that up, with common objects, etc... Could be a very nice, rapid dev / proto / hobby environment. And that kind of thing maps easily to what they would see in other environments, because it would run a whole lot like other environments do, without breaking what a Propeller is. The stumbling blocks proven out with Prop I can be worked on, and marginalized.
2. For the Pro, the chip boots right to a LMM / PASM environment, where the bulk of things runs LMM, perhaps XMM, with PASM either serving up a kernel, which can do debug, if desired, threads, etc... and PASM providing foundation blocks of functionality, video, I/O, math, who knows? It's going to be possible to target lots of things to that mode, without the hassle of dealing with the "friendly" bits. Just get serious.
3. A stripped down environment like 12 blocks could run a lot of pre-cooked things, requiring only light assembly and logic, for casual people, kids, etc... I'm intrigued by this idea, thinking that a market for fairly dedicated tools, closely integrated with code, might make a whole lot of sense. Hanno should be stoked. (among others) Bean's embedded BASIC would really shine here too. Enough code space to do real stuff, with interactive operation possible. That's very beginner friendly in ways we don't always see. Hope that happens.
Right now, the sharp divide of SPIN vs PASM, combined with basically non-native, or non-managed LMM code, forces people to think through a lot of stuff. Prop I does what it does, but it isn't always easy, as the boot-strapping work on C and other LMM / XMM things has shown. Possible though. Always good. Basically, Bill Henning figured out the VM model for LMM, extending the chip considerably beyond it's original design intent.
Most of that goes away on the new chip, with LMM being known, and a focus, it's going to present a lot differently. PASM won't be necessary for speed, and LMM will have tools, and native VM support now too. IMHO, many have not really started thinking through just what that means. To me, the COG becomes micro-code like, in that programs can be written there, and they will be, but that's now a specialized niche, instead of the primary path to getting the most out of the chip. LMM, running near 2:1 is going to rock pretty hard, and LMM can run either concurrently, or threaded, basically eliminating the COG instruction address space limit, while preserving most of the PASM advantages.
Thinking through a lot of the use cases where people CAN get stuff down now, but have to work for it, with that in mind, seems to me a whole lot of issues just go away, leaving the user / developer with a very I/O capable chip, determinism, concurrency, video, etc... with speed and scale more appropriate for a much wider set of use cases.
On the chance that my offer was missed (this is a busy thread); I will offer testing services to this effort. As a software engineer by profession, I think it will be fun to be the monkey loose on the keyboard for a project like this. If anyone is interested in my helping in that manner, just ping me when the time is right.
On the chance that my offer was missed (this is a busy thread); I will offer testing services to this effort. As a software engineer by profession, I think it will be fun to be the monkey loose on the keyboard for a project like this. If anyone is interested in my helping in that manner, just ping me when the time is right.
Thanks for reposting. All testers are appreciated! Hopefully test thread will be posted later so all contributors and testers can get together. A more private forum may be added for early test phase so things can easily remain on topic.
Guys, I just got back about an hour ago from the best, most productive UPEW ever!
Although I am pretty sure Ken wanted to kill me for it, I stole too much of Chips time (sorry, about 4-5h) and later about the same amount of time with Ken, and some with Steve - but the chat with Chip was incredibly productive, and means that LMM2 is
(a) moving away from my current theoretical status for it
(b) potentially MUCH faster than speculated here, with potentially being SIGNIFICANTLY faster than 50% of pure new Prop2 pasm speed
(c) all VM's and Spin will get a roughly 4x performance boost without recoding <-- due to Chip running with my modest suggestion and making it WAY BETTER
... actually Ken will probably pat me on the back instead, as the chat was VERY productive and opens new doors and makes faster LMM2 possible - but the real question is... will it fit on Prop2? Or have to wait for Prop3?
(I think he will chase me down with that paint ball chain gun if I suggest any more instructions for Prop2... instead working on LMM2... and Steve will offer to re-load the paintballs)
As much as I'd love to post more details, I've got too much to do quickly to help Prop2 and make LMM2 so that Prop2 running compiled LMM2 code becomes a real alternative - even a threat ~70Mhz arm cores but I have much more to discuss with Ken, Steve, Roy and others (after having a great face to face session with Ken, Steve and Kye); and like everyone on the forums, we are all thoroughly committed to making Prop2/C a killer alternative to other microcontrollers (or just a C/C++/gnu tool chain checkmark for suits, whatever works)
Now I need to sleep, I only slept about 7.5h in the last 72+ hours... and I am not 20 any more :-(
I am stoked, I am excited, I am updating my LMM2 design starting tomorrow :-)
p.s.
Who will be the first to send me a copy of the webminar I missed while on the Rhapsody of the Seas in Alaska?
p.p.s.
I know, I should not have suggested the additional instruction this late - but I had to, due to the vastly increased possible speed increase for LMM2 with it, and vast increase for ALL VM's after Chip improved the suggestion
I really envy you being at UPEW. I managed to log into the live feed to catch Chip's talk, but I'm sure there were many others there that were equally interesting.
I look forward to Chip (or yourself - hint, hint!) documenting the new/changed instructions, so that the GCC effort (as well as other LMM users), can benefit from them!
Like you, I eagerly await even miserly documentation on the new addressing modes, instructions and I/O architecture; but right now, I have exactly the same amount of docs as you do... (ie none)
Fortunately Kye will extract the information from Chip even if Ken has to hold Chip down, and Kye has to use a dental drill...
Also, regardless of GCC, I can't wait to see Catalina 2.
I really envy you being at UPEW. I managed to log into the live feed to catch Chip's talk, but I'm sure there were many others there that were equally interesting.
I look forward to Chip (or yourself - hint, hint!) documenting the new/changed instructions, so that the GCC effort (as well as other LMM users), can benefit from them!
Fantastic news Bill. I can only guess the LMM2 instruction would be to do with the jump instructions because these are double longs? This should be one killer of a chip
Kye is great for docs, so this sounds great too
I can hear Ross itching to get started on Catalina 2 from here (and he is ~10km away by crow)!
(c) all VM's and Spin will get a roughly 4x performance boost without recoding <-- due to Chip running with my modest suggestion and making it WAY BETTER
That sounds intriguing. Could you describe this new instruction?
Thanks Cluso99.. great guess, my original thought was using double longs precisely for far addresses and immediate word/long constants... but it would have taken too much logic :-(
My fallback solution (which I thought would take too much logic) turned out to be much easier to do, and Chip ran with it to make it far more generic and better - but before I talk more about it, I am waiting for what additional spin Chip will put on it... it was a crazy good talk session.
David, I will be happy to describe it once
(a) Chip says it fits and
(b) I find out what the final form is - in a couple of minutes he significantly improved on my original suggestion!
There is no point in getting hopes up until I find out if it makes it in, and in what final form.
Comments
I'm looking forward to having ZiCog running 8 times faster and without the need for external RAM. Complete with on board VT100 screen. It will soon be time for another CP/M in a matchbox design:)
Clearly compilers targeting LMM are getting an unfair advantage over bytecode interpreters like Zog. Unfair I say:)
I tried to clarity this during the webinar, but didn't get an entirely satisfactory answer. Without the final details, I think it is too early to say that this is true. Some instructions do seem to change. But I could have misunderstood.
Ross.
Heater, you should be able to get significant performance gains for Zog (over the raw clock speed boost and 4:1 instruction latency differences) due to the new instructions and registers. I'm sure more details will become available soon. Of course, the C LMM kernels will be able to get significant gains from these also. Especially in stack related stuck (smaller code, and faster).
Spin on the Prop 2 will be faster than just the raw clock speed and instruction latency differences also.
"a rising tide lifts all boats"
Ross.
This is not uncommon. I've been programming since The Ark and had to deal with a lot worse tools than that but Eclipse makes me nuts as well. Then there is getting Eclipse and the Android tool chain running, what a palaver. This stuff is really not a good intro to programming for the uninitiated.
Where Eclipse wins is when you have fully integrated a whole slew of tools like debugger, timing analyser, signal trace viewer etc etc. But this is hardly stuff for the raw beginner.
I think that old hands tend to forget how much they know. I minor problem for them can be overcome almost instinctively, for a beginner that same minor problem can be a black hole they fall into and perhaps give up the whole idea.
I'm somewhere inbetween a casual programmer and a professional (as I had several jobs where the main work was to code in high level languages but not in the most common C/C++.
The easyness of the propeller-tool results from beeing ONE SINGLE exe-file. Install FTDI-Driver install propeller-tool and you are ready to start coding. Hit F11 and your code is running.
Can you guarantee that a combination of a commandline-tool and an IDE will be THAT simple to install even on a quite MISconfigured PC from an amateur?
@Leon: you mentioned that for YOU installing eclipse worked always well. Now you seem to be a very professional code-developper.
To me if a professional says "no problem it always runs through" is almost an argument AGAINST easyness. As an expert you just ARE blind for
newbee problems. The big amount of knowledge you have creates this blindness. You have to add another kind of knowledge to become seeing again for this special kind of problems: If you have worked with a lot of newbees and all their crazy ideas how to do things in a stupid way.
Will there be a effort to make it as foolproof as possible? IMO opinion a single exe is inherent a lot of more foolproof than a tool-chain just because there are more parts than can be mixed up.
best regards
Stefan
P.S.: people that like to explore how things work and solve riddels as a detective will not complain about a complicated installation and configuration process. To such people this is a source of pleasure.
To the people that don't like it it is a source of pain. This has nothing to do with the fact that you need a certain amount of knowledge to develop software. The question is how much knowledge do you need to now to
reach a target of a certain complexity and how easy or difficult is it to get these knowledge?
I still don't see many beginners using the Propeller 2.
Ross.
I'm very pleased by this, with the worry of fragmentation. Probably that's unavoidable on this larger scale.
I have followed the whole thread but it's been going for a long time, and I'd forgotten that!
Easier than the Arduino and the ARM mbed?
1. Use Prop Tool, SPIN, PASM, LMM as it's done today, only get LMM sorted and do fun stuff like inline PASM, via LMM in SPIN. People would like that at lot, and not being constrained by resources and speed, like Prop I currently is, means framing that up, with common objects, etc... Could be a very nice, rapid dev / proto / hobby environment. And that kind of thing maps easily to what they would see in other environments, because it would run a whole lot like other environments do, without breaking what a Propeller is. The stumbling blocks proven out with Prop I can be worked on, and marginalized.
2. For the Pro, the chip boots right to a LMM / PASM environment, where the bulk of things runs LMM, perhaps XMM, with PASM either serving up a kernel, which can do debug, if desired, threads, etc... and PASM providing foundation blocks of functionality, video, I/O, math, who knows? It's going to be possible to target lots of things to that mode, without the hassle of dealing with the "friendly" bits. Just get serious.
3. A stripped down environment like 12 blocks could run a lot of pre-cooked things, requiring only light assembly and logic, for casual people, kids, etc... I'm intrigued by this idea, thinking that a market for fairly dedicated tools, closely integrated with code, might make a whole lot of sense. Hanno should be stoked. (among others) Bean's embedded BASIC would really shine here too. Enough code space to do real stuff, with interactive operation possible. That's very beginner friendly in ways we don't always see. Hope that happens.
Right now, the sharp divide of SPIN vs PASM, combined with basically non-native, or non-managed LMM code, forces people to think through a lot of stuff. Prop I does what it does, but it isn't always easy, as the boot-strapping work on C and other LMM / XMM things has shown. Possible though. Always good. Basically, Bill Henning figured out the VM model for LMM, extending the chip considerably beyond it's original design intent.
Most of that goes away on the new chip, with LMM being known, and a focus, it's going to present a lot differently. PASM won't be necessary for speed, and LMM will have tools, and native VM support now too. IMHO, many have not really started thinking through just what that means. To me, the COG becomes micro-code like, in that programs can be written there, and they will be, but that's now a specialized niche, instead of the primary path to getting the most out of the chip. LMM, running near 2:1 is going to rock pretty hard, and LMM can run either concurrently, or threaded, basically eliminating the COG instruction address space limit, while preserving most of the PASM advantages.
Thinking through a lot of the use cases where people CAN get stuff down now, but have to work for it, with that in mind, seems to me a whole lot of issues just go away, leaving the user / developer with a very I/O capable chip, determinism, concurrency, video, etc... with speed and scale more appropriate for a much wider set of use cases.
-Phil
Although I am pretty sure Ken wanted to kill me for it, I stole too much of Chips time (sorry, about 4-5h) and later about the same amount of time with Ken, and some with Steve - but the chat with Chip was incredibly productive, and means that LMM2 is
(a) moving away from my current theoretical status for it
(b) potentially MUCH faster than speculated here, with potentially being SIGNIFICANTLY faster than 50% of pure new Prop2 pasm speed
(c) all VM's and Spin will get a roughly 4x performance boost without recoding <-- due to Chip running with my modest suggestion and making it WAY BETTER
... actually Ken will probably pat me on the back instead, as the chat was VERY productive and opens new doors and makes faster LMM2 possible - but the real question is... will it fit on Prop2? Or have to wait for Prop3?
(I think he will chase me down with that paint ball chain gun if I suggest any more instructions for Prop2... instead working on LMM2... and Steve will offer to re-load the paintballs)
As much as I'd love to post more details, I've got too much to do quickly to help Prop2 and make LMM2 so that Prop2 running compiled LMM2 code becomes a real alternative - even a threat ~70Mhz arm cores but I have much more to discuss with Ken, Steve, Roy and others (after having a great face to face session with Ken, Steve and Kye); and like everyone on the forums, we are all thoroughly committed to making Prop2/C a killer alternative to other microcontrollers (or just a C/C++/gnu tool chain checkmark for suits, whatever works)
Now I need to sleep, I only slept about 7.5h in the last 72+ hours... and I am not 20 any more :-(
I am stoked, I am excited, I am updating my LMM2 design starting tomorrow :-)
p.s.
Who will be the first to send me a copy of the webminar I missed while on the Rhapsody of the Seas in Alaska?
p.p.s.
I know, I should not have suggested the additional instruction this late - but I had to, due to the vastly increased possible speed increase for LMM2 with it, and vast increase for ALL VM's after Chip improved the suggestion
I really envy you being at UPEW. I managed to log into the live feed to catch Chip's talk, but I'm sure there were many others there that were equally interesting.
I look forward to Chip (or yourself - hint, hint!) documenting the new/changed instructions, so that the GCC effort (as well as other LMM users), can benefit from them!
Ross.
Like you, I eagerly await even miserly documentation on the new addressing modes, instructions and I/O architecture; but right now, I have exactly the same amount of docs as you do... (ie none)
Fortunately Kye will extract the information from Chip even if Ken has to hold Chip down, and Kye has to use a dental drill...
Also, regardless of GCC, I can't wait to see Catalina 2.
http://www.youtube.com/watch?v=TPQ7KMCrPLE&feature=related&t=158
Is it safe?
-Phil
Kye is great for docs, so this sounds great too
I can hear Ross itching to get started on Catalina 2 from here (and he is ~10km away by crow)!
Thanks Cluso99.. great guess, my original thought was using double longs precisely for far addresses and immediate word/long constants... but it would have taken too much logic :-(
My fallback solution (which I thought would take too much logic) turned out to be much easier to do, and Chip ran with it to make it far more generic and better - but before I talk more about it, I am waiting for what additional spin Chip will put on it... it was a crazy good talk session.
David, I will be happy to describe it once
(a) Chip says it fits and
(b) I find out what the final form is - in a couple of minutes he significantly improved on my original suggestion!
There is no point in getting hopes up until I find out if it makes it in, and in what final form.
Itching, maybe - but not badly enough to start scratching until we get at least a whiff of silicon! :blank:
Ross.
Actually, I'd probably settle for just a reasonably reliable description of the instruction set
Ross.