The Propeller Tool could have a button at the top (like the ones on the Basic Stamp IDE) that allow you to easily select which chip you're programming for.
Post Edited (KenFordham) : 8/28/2008 2:19:17 AM GMT
Compatibility is always welcomed when it makes sense but at what cost? Sometimes it's good idea to go Back through The Future. Recycling is a good example of when it's a good idea but is Prop II? With your help the talent pool in the Propeller community will find ways around any inconveniences and have fun with the challenges. If Microsoft had taken a clean approach with Windows 95, would we have Linux today?? Would Apple OS be on the rise today?? The PIC world is compatible (so they tell me) but it's also one big mess. For prop II we need you to be a trailblazer so that we can become challenged and engaged for years to come. In case I wasn't clear, my vote is for a CLEAN slate. If you don't I'll be the first in line to say I TOLD YOU SO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 8/28/2008 3:08:15 AM GMT
Thank you for letting us post our feedback on this Chip!
I think my vote is clean slate. The story behind the Proppeller IC is how there were no compromises. Everything came out the way you wanted it. Everything worked. Of courses, there were probably many long, hard struggles justifying this or that. I can see you may go nearly insane trying to make arguments for all the "could it" or "should it" of the Prop II. Make the Prop II as best as you can and pushing ahead with the envelope of what it can do. If we break code compatiability, I am sure there will be some moaning and groaning, but in the end if it all that needs to be done is a software adjustments, not much is really lost, right?
Whichever way it goes, we'll work with it, so no pressure [noparse][[/noparse]8^)
Having said that, my vote is clean slate, as I value elegance over compatibility. As a possible solution, if I understood correctly than PASM is virtually unaffected, I suggest the following:
With the Pii using some nice linear RAM layout internally, the Spin interpreter for the Pii uses the [noparse]/noparse notation for legacy-compatible RAM addressing, with a tiny speed penalty due to the Spin interpreter overhead of the more complex addressing (maybe throw a warning if the address is > 32K?).
Develop a new notation for the new Pii RAM layout...e.g. () as in the old Basic way. This would use the new direct addressing and be a) faster on the Pii, and b) obviously incompatible with the Pi.
This way the legacy code is run the same on both, and Pii-only code is obviously not for Pi.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
I fully expect to be able to attach at least 2GB of external memory to PropII one way or another [noparse]:)[/noparse]
I vote for flat memory map mainly out of belief that you'll end up doing it sooner or later anyway and the possibility that we can detect the different chips in user code and do the right thing. Mask code won't have to play the detection game.
Being able to distinguish between Prop and PropII would allow making the current spin code function correctly for both. Today's chip version at $FFFF is in kind of a bad place, so maybe a cookie can be put in address $FFFFFFFF to differentiate the chips. Your call obviously.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
No backwards compatibility and avoid memory segmentation. If hurts Spin users like myself so be it. It would be nice to have a Prop that wasn't memory restricted and somewhat hostile to native code compilers.
And make room for a external memory bus, because some people will use the Prop as a desktop chip like the x86 or ARM or need it to build multi-media apps.
Is there a way you could take advantage of the fact that Prop I uses 4 clocks per instruction (versus the 1 clock for Prop II). Not sure if I'm thinking this through completely, but you may be able to leverage the fact that old code can be translated into new code in some way due to execution time (this didn't come out right!)
Use software to translate old to new. As has been said, this community will step up to the challenge. Look at what Tom did with the SD stuff. That object gets beat to death now, and he had it really early in the adoption of the Prop.
Ultimately, there won't be much of a change in the overall set of instructions, so people should be able learn the new stuff as quick as the old.
You could also look at it in the following way: Prop I was just a test, now you know how to do this (design silicon) thing. You've made a few mistakes, learned a bit, gotten TONS of feedback and ideas for other ways to do it (from the dudes on the forum). You're kinda smart (crud, you bought a nut farm, aren't we nuts enough?), you should be able to determine how to make the most out of the innovation process.
Chip, you're 39 (or 40, 1968, right?), you've got LOTS of silicon to design. Set yourself up for the future now, and let us grumble for tad. It'll all be forgotten once we see what you've done.
-Luke
PS - You MUST create a new name. Maybe the same theme, but you need to distinguish this thing as it's own, not just Rev 2...
PPS - Certain litho tools use the same Microsoft philosophy regarding the code that runs the tool. Everyone was concerned about the same set of code being able to run EVERY tool we (er, they) make, with just a few changes in machine constants, this is possible. But, the dudes (and dudettes) writing the code HATE it, and the size of the code is MONSTROUS. Clean slate is my vote.
I think the clean slate is the best option. The programs that work for the propeller are designed for the propeller. Let those users keep using their that version of the chip. Why hinder the next generation chip just so we can have a little bit of compatibility with something that was written for an older application? If the propeller II is to have a long lifespan, the compatibility issue won't last anywhere near the chip life. I think the clean slate option is the way to go.
Definitely, positively, without a question - 32 bits clean. You don't want the compiler writers to go "Dang, just a great chip, except for that 20/24 bits address and the pointers and..."
The ImageCraft C compiler already uses 32 bits for pointers and integers. It wastes data space, but is "forward looking" and speed wise, since the ALU is 32 bits, it doesn't suffer.
Okay, this has been really helpful. I appreciate everyone's input. It's true that compatibility has a limited lifespan, but overall cleanliness does not. Clean slate is the best approach. I was just initially cringing at 32-bit addressing in Spin, as it is extreme overkill at this point in time. But, 24 bits would be a half-cocked mess, so 32 it is. I feel good about this. Thanks, everyone, and feel free to keep posting if there's more you'd like to say.
Yeah, us comsumers want the best of course. [noparse]:)[/noparse] I imagine there is a number of timing sensitive setups that will break it's I/O requirements either way. So, it can't really be 100% compatible given the low level nature of that code.
Looks like you already have enough voters but I would vote for going clean slate/32bit pointers as well.
I don't know if you want to do this but you could include a new "pointer" type that automatically sized itself for whatever type of Prop it was on to help compatibility. You could also define a constant that was the start of rom/chars/log tables which would help as well. That way you should be able to make a lot of objects that run on both without any problems.
Have you thought about moving to maybe a 40 bit cog or is that too different? It would get around some problems and allow for a larger cog memory down the track and more instructions (although it would be a pain in the neck if attaching external memory).
Are you still planing on the bulk hub access and will this be a new instruction or something different? I couldn't see any way of fitting it in unless you play around with the flags on the RDxxsx/WRxxxx instructions like already done with the write result flag (c flag maybe?).
I think you will have the best microcontroller available with the Prop 2, So when it's released you should have the best language, best·IDE and loads of documentation.·If you can't do that because you·made your changes, then you should go with what you know.
If you do make the change, how about offering Pbasic for the Prop1 or create a niche for the SpinStamp
Post Edited (Capt. Quirk) : 8/28/2008 8:37:40 AM GMT
32 bit. A good choice. The next step will be 64 bits. This will give the ability to address all the available memory on earth if organised as 64 bit words. And the prize is low: if you store 32 bit information in 64 bit locations, you loose half of the memory. But how often do we today store 1 bit information in n-Bit words? And who cares about the importance of information? We should not take more care for memory consumption than for fuel consumption
ps: who knows the ultimate address length, when we will run out of elementary particles in the universe?
I believe: about 110 Bits? True?
Woke up to a huge overnight thread, and I guess it's too late to put my 2p's worth in, by saying break compatibility, as you've already decided to break it anyway, so what if a few changes to code are going to be needed, it was gonna happen anyway, with the extra speed and optimisations, and the way C flag was going to be used for WAITPEQ instructions etc. 99% of current code would have to be modified slightly anyway, so my opinion was going to be change it for the better NOW, rather than get us used to backwards compatibility, otherwise it would also hinder not only PropII but also later Prop models, because we'd have been used to compatibility.
Anyway, good choice peeps [noparse];)[/noparse]
Onwards and upwards.
I'm late to this party but my vote is for FLAT memory space. RAM at the bottom ROM at the top. Any pointers to be 32Bits.
What we love about the Prop is its regularity, elegance, simplicity....Would be sad to see that messed up with memory holes, banked memory, segment addressing, or other kludges that have annoyed programmers for decades.
24Bit pointers is makes me cringe. To limiting and not "regular" with your natural word length. I'm sure when the Prop II is done there will come an itch for the Prop III as by then you'll be able to cram even more logic onto the same piece of silicon for the same price. That 24 bit limit might come back to haunt you.
A compatibility switch seems to add even more complication, consider I create a new Spin object in PropII mode but I have to use old ready made objects that are written for Prop I. Messy.
If all goes well you may sell a million times more PropIIs than PropIs. At that point you'll wonder why you worried about compatibility so much.
By the way I think it's amazing that a chip design company, even the designer himself, involves us mere mortals in the design process in such an open way. Has this ever hapend before ? I look forward to spending my money on the results of this process.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
One point I seem to have missed. Some time ago we were asked if we would like more RAM or more COGS. Then all of a sudden we seem to be lucky enough to be looking forward to both and a bunch of other goodies. Where did all that extra silicon magically appear from ?
Just curious.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I favor a clean slate. Then hopefully, someone will write a program to translate old code to the new chip. The Propeller IDE should either throw an error or a warning if you have targeted the Prop II and use something that may not work
I would not think in terms of the PropI and PropII, but PropII and PropIII.
What are you going to do in the next revision should drive your decisions.
You've already done fantastic work with the PropI. People will adjust their
software to handle compatibility, they will do this because the architecture
has such promise.
Chip. How will rdlong access a 32 bit address with one long instruction ?
Oops. Never mind. Not enough coffee yet [noparse]:)[/noparse]·I guess the better question is: will you have any kind of post increment or other variations? This has been requested/suggested before many times.
Lord knows I've tried to assemble all the Propeller II features Parallax has mentioned. And we don't know ALL that you plan for Prop II.
But, another voice piping up says, compatibility is nice, but not at the expense of making Prop II the best IT can be.
Make Prop II work like it should; flat memory space, optimized for running as fast as possible, and with an IDE which 'knows' which Prop (I or II) the programmer is writing for. Prop I already provides its version#; guessing Prop II also has its own too (CHIPVER = 2 ?). I'm no programmer wizard, but all the other suggestions the 'wizards' need should also be incorporated (well, there probably are some limits to this).
Comments
The Propeller Tool could have a button at the top (like the ones on the Basic Stamp IDE) that allow you to easily select which chip you're programming for.
Post Edited (KenFordham) : 8/28/2008 2:19:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 8/28/2008 3:08:15 AM GMT
I think my vote is clean slate. The story behind the Proppeller IC is how there were no compromises. Everything came out the way you wanted it. Everything worked. Of courses, there were probably many long, hard struggles justifying this or that. I can see you may go nearly insane trying to make arguments for all the "could it" or "should it" of the Prop II. Make the Prop II as best as you can and pushing ahead with the envelope of what it can do. If we break code compatiability, I am sure there will be some moaning and groaning, but in the end if it all that needs to be done is a software adjustments, not much is really lost, right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Those who can, do.Those who can’t, teach.
Having said that, my vote is clean slate, as I value elegance over compatibility. As a possible solution, if I understood correctly than PASM is virtually unaffected, I suggest the following:
With the Pii using some nice linear RAM layout internally, the Spin interpreter for the Pii uses the [noparse]/noparse notation for legacy-compatible RAM addressing, with a tiny speed penalty due to the Spin interpreter overhead of the more complex addressing (maybe throw a warning if the address is > 32K?).
Develop a new notation for the new Pii RAM layout...e.g. () as in the old Basic way. This would use the new direct addressing and be a) faster on the Pii, and b) obviously incompatible with the Pi.
This way the legacy code is run the same on both, and Pii-only code is obviously not for Pi.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Jim Fouch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
I vote for flat memory map mainly out of belief that you'll end up doing it sooner or later anyway and the possibility that we can detect the different chips in user code and do the right thing. Mask code won't have to play the detection game.
Being able to distinguish between Prop and PropII would allow making the current spin code function correctly for both. Today's chip version at $FFFF is in kind of a bad place, so maybe a cookie can be put in address $FFFFFFFF to differentiate the chips. Your call obviously.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
And make room for a external memory bus, because some people will use the Prop as a desktop chip like the x86 or ARM or need it to build multi-media apps.
Is there a way you could take advantage of the fact that Prop I uses 4 clocks per instruction (versus the 1 clock for Prop II). Not sure if I'm thinking this through completely, but you may be able to leverage the fact that old code can be translated into new code in some way due to execution time (this didn't come out right!)
Use software to translate old to new. As has been said, this community will step up to the challenge. Look at what Tom did with the SD stuff. That object gets beat to death now, and he had it really early in the adoption of the Prop.
Ultimately, there won't be much of a change in the overall set of instructions, so people should be able learn the new stuff as quick as the old.
You could also look at it in the following way: Prop I was just a test, now you know how to do this (design silicon) thing. You've made a few mistakes, learned a bit, gotten TONS of feedback and ideas for other ways to do it (from the dudes on the forum). You're kinda smart (crud, you bought a nut farm, aren't we nuts enough?), you should be able to determine how to make the most out of the innovation process.
Chip, you're 39 (or 40, 1968, right?), you've got LOTS of silicon to design. Set yourself up for the future now, and let us grumble for tad. It'll all be forgotten once we see what you've done.
-Luke
PS - You MUST create a new name. Maybe the same theme, but you need to distinguish this thing as it's own, not just Rev 2...
PPS - Certain litho tools use the same Microsoft philosophy regarding the code that runs the tool. Everyone was concerned about the same set of code being able to run EVERY tool we (er, they) make, with just a few changes in machine constants, this is possible. But, the dudes (and dudettes) writing the code HATE it, and the size of the code is MONSTROUS. Clean slate is my vote.
The ImageCraft C compiler already uses 32 bits for pointers and integers. It wastes data space, but is "forward looking" and speed wise, since the ALU is 32 bits, it doesn't suffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I don't know if you want to do this but you could include a new "pointer" type that automatically sized itself for whatever type of Prop it was on to help compatibility. You could also define a constant that was the start of rom/chars/log tables which would help as well. That way you should be able to make a lot of objects that run on both without any problems.
Have you thought about moving to maybe a 40 bit cog or is that too different? It would get around some problems and allow for a larger cog memory down the track and more instructions (although it would be a pain in the neck if attaching external memory).
Are you still planing on the bulk hub access and will this be a new instruction or something different? I couldn't see any way of fitting it in unless you play around with the flags on the RDxxsx/WRxxxx instructions like already done with the write result flag (c flag maybe?).
If you do make the change, how about offering Pbasic for the Prop1 or create a niche for the SpinStamp
Post Edited (Capt. Quirk) : 8/28/2008 8:37:40 AM GMT
ps: who knows the ultimate address length, when we will run out of elementary particles in the universe?
I believe: about 110 Bits? True?
Post Edited (ErNa) : 8/28/2008 9:19:27 AM GMT
Anyway, good choice peeps [noparse];)[/noparse]
Onwards and upwards.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
What we love about the Prop is its regularity, elegance, simplicity....Would be sad to see that messed up with memory holes, banked memory, segment addressing, or other kludges that have annoyed programmers for decades.
24Bit pointers is makes me cringe. To limiting and not "regular" with your natural word length. I'm sure when the Prop II is done there will come an itch for the Prop III as by then you'll be able to cram even more logic onto the same piece of silicon for the same price. That 24 bit limit might come back to haunt you.
A compatibility switch seems to add even more complication, consider I create a new Spin object in PropII mode but I have to use old ready made objects that are written for Prop I. Messy.
If all goes well you may sell a million times more PropIIs than PropIs. At that point you'll wonder why you worried about compatibility so much.
By the way I think it's amazing that a chip design company, even the designer himself, involves us mere mortals in the design process in such an open way. Has this ever hapend before ? I look forward to spending my money on the results of this process.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ D Rat
Dave Ratcliff· N6YEE
Just curious.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How generous of Chip to even seek our opinions in the first place!!!!!
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
John Abshier
What are you going to do in the next revision should drive your decisions.
You've already done fantastic work with the PropI. People will adjust their
software to handle compatibility, they will do this because the architecture
has such promise.
Scott
Oops. Never mind. Not enough coffee yet [noparse]:)[/noparse]·I guess the better question is: will you have any kind of post increment or other variations? This has been requested/suggested before many times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 8/28/2008 2:27:57 PM GMT
Lord knows I've tried to assemble all the Propeller II features Parallax has mentioned. And we don't know ALL that you plan for Prop II.
But, another voice piping up says, compatibility is nice, but not at the expense of making Prop II the best IT can be.
Make Prop II work like it should; flat memory space, optimized for running as fast as possible, and with an IDE which 'knows' which Prop (I or II) the programmer is writing for. Prop I already provides its version#; guessing Prop II also has its own too (CHIPVER = 2 ?). I'm no programmer wizard, but all the other suggestions the 'wizards' need should also be incorporated (well, there probably are some limits to this).
Waiting to get Prop II in hand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko