Should the next Propeller be code-compatible?
cgracey
Posts: 14,256
Big question here that I didn't think I'd be asking anyone...
·
·
Should the next Propeller be:
·
A) kept code-compatible with the current Propeller
·
········································· -or-
·
made a little different to better accommodate the expanded memory
·
·
In any case, the next Propeller will have 256KB+ of SRAM, analog-capable pins, many additional assembly instructions, improved CTRs and Video, etc. These can all be cleanly implemented in ways that don't break current Spin and assembly code. For example, there are new pointer modes for the RDxxxx/WRxxxx instructions that can reach beyond the current 16-bit address space.·Compatibility would require a non-flat memory map, with the normal 32KB RAM + 32KB ROM followed by a new 256KB RAM + 256KB ROM.
·
The advantage of code-compatibility is that you get an immediate speed improvement, without having to make any changes to your code. Then, you can begin taking advantage of the new features. The new 256KB RAM would be very usable for screen buffers and such, but not necessarily for Spin code.
·
The advantage of breaking compatibility is that you get one flat memory map that kind of clears the slate on legacy issues. We wouldn’t need LOG and SINE tables in ROM anymore, since each cog would have its own CORDIC system. The new RAM would be realized contiguously, so Spin would need to be modified to handle the extra address space. This would require minor changes to some Spin and assembly code.
·
So, which do you think is better: compatibility or clean slate?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
·
·
Should the next Propeller be:
·
A) kept code-compatible with the current Propeller
·
········································· -or-
·
made a little different to better accommodate the expanded memory·
·
In any case, the next Propeller will have 256KB+ of SRAM, analog-capable pins, many additional assembly instructions, improved CTRs and Video, etc. These can all be cleanly implemented in ways that don't break current Spin and assembly code. For example, there are new pointer modes for the RDxxxx/WRxxxx instructions that can reach beyond the current 16-bit address space.·Compatibility would require a non-flat memory map, with the normal 32KB RAM + 32KB ROM followed by a new 256KB RAM + 256KB ROM.
·
The advantage of code-compatibility is that you get an immediate speed improvement, without having to make any changes to your code. Then, you can begin taking advantage of the new features. The new 256KB RAM would be very usable for screen buffers and such, but not necessarily for Spin code.
·
The advantage of breaking compatibility is that you get one flat memory map that kind of clears the slate on legacy issues. We wouldn’t need LOG and SINE tables in ROM anymore, since each cog would have its own CORDIC system. The new RAM would be realized contiguously, so Spin would need to be modified to handle the extra address space. This would require minor changes to some Spin and assembly code.
·
So, which do you think is better: compatibility or clean slate?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Comments
Is it possible that there might be a hardware switch to select between these options?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
After that, Nobody uses the compatible mode anymore, everybody would always opt for the Turbo mode.
All the paging and banking around could be an additional debugging and support headache.
Go for a clean slate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
The bootloader and program loader could also use this indicator to choose between a Spin I or Spin II interpreter if there was a reason to have two interpreters.
The only reason for a "hardware switch" would be if the cog instruction set would need incompatible differences between the two modes. That doesn't seem necessary.
My bias would be to provide upward compatibility as much as possible without restricting the new features (like forcing the memory map to be Prop I compatible), fix as much of the differences in software as possible (like having two Spin interpreters and copying part of ROM to the 2nd 32K of RAM when needed)
Post Edited (Mike Green) : 8/28/2008 12:58:22 AM GMT
The Propeller II is much more than just a faster Propeller I - perhaps it should have another name.
I think there will be many who continue using the Propeller I as it is still a highly capable processor. The Propeller II is not a "desperately needed" chip, it's just that we're all excited about what the next generation of an already great chip will be able to achieve.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
suffered as a result ....
I don't mind some slight pain to port Propeller I to Propeller II if that gives me a leap in hardware spec.
( .... As long as you don't stray too far from the current brilliant cog concept that is
My 2c worth ..
Isn't is really about the "Prop Tool" though? It would seem to make sense to expand/enhance it such that it handles whichever Prop you are working with appropriately.
Edit: looks like Mike already made a similar point while I was fighting with Firefox' refusal to allow me to "submit" my response! I agree Mike!
Post Edited (Paul Sr.) : 8/28/2008 1:14:32 AM GMT
IMHO, having a flat memory model outweighs any advantage of backward compatibility.
Anyway, the Prop2 is sounding to me like an evolution, not a revolution. So, I'd have to say A would be the best pick.
PS: I think I'd rather see 64-bits and more COG RAM...
That way, we've got the current Propeller and it's body of code, and the newer, faster design (series maybe) that has somewhat different code.
Parallax plans to continue selling the existing Propeller for quite some time, meaning that code will continue to have a home for quite some time. It's a great chip, and it's very friendly in a lot of ways. From here, the new scale will break some of that friendliness, and that's a good thing going forward. The larger scale and speed will make it applicable for more tasks and maybe more commercial in nature. (code protection, etc...) Not that the current Propeller isn't capable --that goes without saying.
With new features, there are gonna be code rewrites as people want to optimize and leverage those. Why not leverage that natural activity then?
The next jump is a significant one too! Seems a pity to hobble it and break the straightforward design approach we all like so much. I don't think compatibility is worth it in the very longer term, and both chips are for the very longer term, right?
I'll bet with the activity seen here, translators will be available in a short time, meaning code can move from one body to another without serious difficulty. That difficulty will always be there, as people will want to do both. Let software handle that. I think we all will be surprised at how that goes.
New projects, on the new chip won't have to suffer if the instruction set is clean like it is right now. IMHO, that's a big draw worth keeping.
The problem I see with the hardware switch is that there will be lots of code that assumes the switch is one way or the other way. Breaks the lego style object reuse model and that's just not worth doing. Segmenting the memory is a kludge, but it won't split the code and could lead to more objects that work with both chips.
I'm really torn on that as a larger body of Propeller code is good.
The scale differences suggest to me that this is more of a feel good than anything else though. The differences in the two chips will rapidly manifest themselves, splitting the code anyway, so why not make the most of the split? That's where I'm ending up.
New users can just jump in with either Propeller. It's a bit of a split to move from one to another, but it would be anyway, so I think that's a wash too in the longer term.
(spank me, if you must, but I gotta ask for a simple means to sync the video generators so they can be used at the same time, on the same pins, overlay style It's not very doable right now, and I wish it was!)
Edit: Since there will be a split of some kind, it is now completely justified to enhance the Prop Tool to handle in-line directives. Nothing fancy, just a few options that will be needed to allow people to write one file that boils down to an executable on either chip, if that's the intent. A side benefit is closing that gap for those who have been needing it on the more complex efforts. The greater scale will take things in that direction anyway, so now's the time!
Doing that would preserve another big draw and that's being able to put lots of stuff in one file in the Propeller tool. IMHO, that's one to keep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Post Edited (potatohead) : 8/28/2008 1:18:45 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Once we understand the small differences, I am sure someone will write a source conversion program to at least identify (and maybe fix) the incompatibilities.
I know this would be complicate the ide but why couldn't there be a constant that is set in the main object that would specify the propeller type that the compiler would use to do its error checks and compiling.
Which current instructions would be obsolete? It seems that at compile time they could be converted if propII was specified.
If I understand the wrlong example, you would still use wrlong with propII not?
With the amount of rom available does it matter if there is a sin cos table in there?
This jump will end up a bit less than optimal, but there are some mitigating circumstances. The multiple for on chip ram is larger than that for the added address bits. That's a net gain, and if done kludge free, will tee things up for Prop III.
For data, it's up to the user, so almost completely a gain there. Non issue, IMHO.
Is there an option to incorporate the simpler addressing via unused or redundant condition / instruction bits? Guess that's going back to the hardware switch, but it would be a conditional one per instruction, leaving people the option to use it for memory optimization, if they need it, but not so forced as a global switch would be. Muddies the instruction set some, but perhaps that's not so bad?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
become incompatible, which would bother me because of all the effort that has
been put forward. However *if* a bulk of it would be compatible, then by all means
press forward...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Exactly the kind of thing you don't want to leave off the table today. (and wouldn't that be cool)
Since assembly isn't gonna be all that different, (good, because that's what is hard) that leaves SPIN. I think the elegance penalty is probably mitigated by the additional speed to be had overall. Plus, it's roomy enough for C / LMM programs to do their thing. That's a lot of options really.
I want to second Mike's idea of the memory hole. Nobody wants to manage the different ROM locations years from now, right?
Simple and sweet says, RAM at the bottom, ROM at the top. Of course, that's a BIG HOLE, but addresses are addresses and it sort of follows the do it once idea. That way, newer ROM builds down, RAM builds up until someday Parallax fills it with the Propeller MEGA or something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Mark
I'd accept that if there were a run-time bit which could be set to switch in and out of compatibility mode but if there's only one mode, flat memory with ROM at top end is my preference. You really don't want to destroy the elegant design do you ?
I have made some comments on this subject before, especially with current users who have chosen to use 16-bit Spin word variables to hold pointers. One problem is that the PropTool doesn't allow conditional compilation so it's not possible to code for both, using long now wastes space, using word creates problems for the future. My preference is for a new type "addr" which is 16-bit or 32-bit depending on some PropTool / source setting or other. That plus ChipVer helps make code compatible between Mk I and Mk II.
My opinion is that it's up to the programmer to make sure their code is compatible with both versions and as long as PropTool supports that there should be no problems. The unacceptable situation would be having to keep two separate code bases.