Hubexec makes the Prop into a much more familiar look for the average joe coder. And, as has been noted in other topics, when said people dig down and discover Cogexec they'll go "What the heck is that? That's just wierd! Can it really execute from the general registers like that?" ... and then the logic of deterministic execution starts to dawn and the lights come on ...
Open ends make it exciting, doesn't it? Who wants to be boxed in by a 512 limit?
Actually, it amazes me how much you can do with ~512 instructions, but still when dealing with graphical display drivers, I've often been forced to leave things out...
It looks like your lack of sleep is starting to show. Hubexec is an awesome feature for the prop2. It will open BIG doors...I realize it could cause some laziness in coding, but in the hands of some "Jedi coder" the prop2 will be able to perfom some amazing feats. It's all a matter of scale. No second-guessing needed:)
It looks like your lack of sleep is starting to show. Hubexec is an awesome feature for the prop2. It will open BIG doors...I realize it could cause some laziness in coding, but in the hands of some "Jedi coder" the prop2 will be able to perfom some amazing feats. It's all a matter of scale. No second-guessing needed:)
I think you're right about lack of sleep. I've noticed myself coming to premature and wrong conclusions a lot, lately. There were several features I had added to the assembler to make it handle addressing modes properly and I had no recollection of having done so. I was surprised to find that they were already implemented when I went in there to "fix" things. I know this is from lack of sleep over the last few months, as it's too early for dementia, yet.
Also, I think I've also developed a bit of dependency on the forum for validation of ideas. All these brains here are like creative multipliers that are fantastic to work with. You couldn't hire such a broad base of enthusiastic experts. It works best when there is unhindered free will without any compulsion, and that's what we have here. It's a surprising development to me, and not something I would have dared hope for. The internet makes it possible.
I think using the forums as a sounding board and source of ideas has done amazing things for the P2 development but you also need to remain the keeper of the vision of what is sane and elegant and "simple" about the Propeller architecture whether it be P1, P2 or P3. I think that vision, elegance and simple complexity is what brought most of us to the Propeller. That can really only come from you. We shouldn't validate designs and ideas so much, your vision is the litmus test for what is and isn't "Propeller".
When you come to us and say, "I have room on silicon for more, what can we make it do?" The forum is a great force multiplier and open arena for debate about the design issues and needs but I still trust your sense as to what should ultimately end up in a validated Propeller design. The forum has often shown its value as a cauldron of ideas and even though some days, the loudest voice appears to have set the design, you come back with an implementation tempered with your view of the Propeller, those are the features that have been WIN/WIN cases.
The openness of this process from when you shared the first FPGA emulation through the testing and design discussion still amazes me even though I sit on the edges as a participant. It's an amazing and unprecedented experience to observe and play along in.
As for "too" open ended, I'm mixed on that. The beauty is that you can look at the P2 as a bigger, better, faster P1 and stop there and still reap the benefits. This is a great transitional benefit. With Spin2/PASM2 looking essentially the same as the P1, folks can come right over and play. All of the added features (multi-tasking, HUBEX, multi-threading, etc) can be learned and built upon the basic fundamental truths that come from the P1 experience.
The beauty of the "open endedness" might come more from the fact that someone can come over from another micro and initially see a single processor with a good sized chunk of program memory to get them started. A comfy cozy environment to play in. Then the realization of all the Propeller features that they never had before are all hidden under that structure familiar to them at which point their journey begins.
I'm very excited by the potential awaiting everyone!
Personally I don't think there is any such thing as "[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Too Open-Ended". Just like there has never been and probably will never be any such thing as, "too much RAM". I say leave it and [/FONT]let creative genius blossom.
I like the proposal Ross put out there. What I didn't, and still don't like is the idea that we need SPIN+PASM to conform to the more mainstream means and methods.
It's entirely possible to overlay the things we need to make reuse sane and productive on top of SPIN+PASM being unified and expressive in terms of both code and data we see today. This is something we all need.
The idea that we need to force reuse didn't and still doesn't hold, because it involves breaking the strengths of SPIN+PASM, not seen much elsewhere. That is all.
What I didn't, and still don't like is the idea that we need SPIN+PASM to conform to the more mainstream means and methods.
I agree completely. Let the other languages deal with that. There is not enough SPIN adoption to even be concerned about things like code re-use ... unless it's just spin stuff.
What I would not like is not being able to use SPIN objects or programs (not using PASM of course) that have already been written.
Did you know that there were two threads started to discuss SPIN2 so that things don't get lost in the 300+ page blog thread? I don't have time to think about it, but others here certainly do.
While HUBEX wasn't my thang, I fully expect to be blown away by what others do with it.
With just a DE0, one is practically compelled to use HUBEX, anyway (like Tubular pointed out). This activity may change how I use the P2 in the future.
Commercially, you use whatever you are given. With the medical devices I've coded for in the past, there is no question that we would have exploited HUBEX and everything else the Prop had. Its presence can't help but promote commercial sales.
@Jazzed, yes. Agreed. Running P1 SPIN should be able to happen easily. Maybe we can compartmentalize it somehow to run in a subset of HUB memory space. $10000 might be a candidate.
Seems to me, the changes needed to maximize SPIN on P2 will make SPIN for P1 unable to just work without doing something like that, or a tool to migrate code. Consequence of abandoning compatability early on.
Comments
Actually, it amazes me how much you can do with ~512 instructions, but still when dealing with graphical display drivers, I've often been forced to leave things out...
It looks like your lack of sleep is starting to show. Hubexec is an awesome feature for the prop2. It will open BIG doors...I realize it could cause some laziness in coding, but in the hands of some "Jedi coder" the prop2 will be able to perfom some amazing feats. It's all a matter of scale. No second-guessing needed:)
I think you're right about lack of sleep. I've noticed myself coming to premature and wrong conclusions a lot, lately. There were several features I had added to the assembler to make it handle addressing modes properly and I had no recollection of having done so. I was surprised to find that they were already implemented when I went in there to "fix" things. I know this is from lack of sleep over the last few months, as it's too early for dementia, yet.
Also, I think I've also developed a bit of dependency on the forum for validation of ideas. All these brains here are like creative multipliers that are fantastic to work with. You couldn't hire such a broad base of enthusiastic experts. It works best when there is unhindered free will without any compulsion, and that's what we have here. It's a surprising development to me, and not something I would have dared hope for. The internet makes it possible.
I think using the forums as a sounding board and source of ideas has done amazing things for the P2 development but you also need to remain the keeper of the vision of what is sane and elegant and "simple" about the Propeller architecture whether it be P1, P2 or P3. I think that vision, elegance and simple complexity is what brought most of us to the Propeller. That can really only come from you. We shouldn't validate designs and ideas so much, your vision is the litmus test for what is and isn't "Propeller".
When you come to us and say, "I have room on silicon for more, what can we make it do?" The forum is a great force multiplier and open arena for debate about the design issues and needs but I still trust your sense as to what should ultimately end up in a validated Propeller design. The forum has often shown its value as a cauldron of ideas and even though some days, the loudest voice appears to have set the design, you come back with an implementation tempered with your view of the Propeller, those are the features that have been WIN/WIN cases.
The openness of this process from when you shared the first FPGA emulation through the testing and design discussion still amazes me even though I sit on the edges as a participant. It's an amazing and unprecedented experience to observe and play along in.
As for "too" open ended, I'm mixed on that. The beauty is that you can look at the P2 as a bigger, better, faster P1 and stop there and still reap the benefits. This is a great transitional benefit. With Spin2/PASM2 looking essentially the same as the P1, folks can come right over and play. All of the added features (multi-tasking, HUBEX, multi-threading, etc) can be learned and built upon the basic fundamental truths that come from the P1 experience.
The beauty of the "open endedness" might come more from the fact that someone can come over from another micro and initially see a single processor with a good sized chunk of program memory to get them started. A comfy cozy environment to play in. Then the realization of all the Propeller features that they never had before are all hidden under that structure familiar to them at which point their journey begins.
I'm very excited by the potential awaiting everyone!
Personally I don't think there is any such thing as "[FONT=Arial, Tahoma, Verdana, Geneva, sans-serif]Too Open-Ended". Just like there has never been and probably will never be any such thing as, "too much RAM". I say leave it and [/FONT]let creative genius blossom.
I like the proposal Ross put out there. What I didn't, and still don't like is the idea that we need SPIN+PASM to conform to the more mainstream means and methods.
It's entirely possible to overlay the things we need to make reuse sane and productive on top of SPIN+PASM being unified and expressive in terms of both code and data we see today. This is something we all need.
The idea that we need to force reuse didn't and still doesn't hold, because it involves breaking the strengths of SPIN+PASM, not seen much elsewhere. That is all.
Count me as a fan otherwise!
I agree completely. Let the other languages deal with that. There is not enough SPIN adoption to even be concerned about things like code re-use ... unless it's just spin stuff.
What I would not like is not being able to use SPIN objects or programs (not using PASM of course) that have already been written.
Did you know that there were two threads started to discuss SPIN2 so that things don't get lost in the 300+ page blog thread? I don't have time to think about it, but others here certainly do.
With just a DE0, one is practically compelled to use HUBEX, anyway (like Tubular pointed out). This activity may change how I use the P2 in the future.
Commercially, you use whatever you are given. With the medical devices I've coded for in the past, there is no question that we would have exploited HUBEX and everything else the Prop had. Its presence can't help but promote commercial sales.
Seems to me, the changes needed to maximize SPIN on P2 will make SPIN for P1 unable to just work without doing something like that, or a tool to migrate code. Consequence of abandoning compatability early on.