I would love to see the instruction word be 40 bits instead of 32. This would allow the source and destination sections of the code word to be 13 bits each which would allow for a much bigger program/RAM space for each COG.
HUB access would still be in 8,16,or 32 bit chunks The COG could use all 40 bits for its instructions with the exception of signed math which would to be truncated to 32 bits because the sign bit has to be in the right place in order for transfers to the HUB to work out.
The big problem with writing in C is that you have to use the LMM which makes your programs run slowly. The propeller can run at a good clip but when you hit that restriction, it doesn't run so fast any more. With more COG RAM, even if it didn't use all 13 bits of address space, it would be a big improvement. You could have complete programs in COG RAM that were written in C.
This should leave the Propeller 2 code compatible with the original propeller I think so it wouldn't cause any issues other than needing to recompile and a EEPROM 25% larger to hold the extra byte per code word.
An indirect register would be great too but that is of lesser importance than being able to run decently sized programs directly in COG.
-Jack
Post Edited (Jack Buffington) : 4/8/2010 7:13:40 PM GMT
Jack just described part of the design of the Prop III, scheduled for...oh...let's say...2015. Anyway, the Prop II's ability to load in 8 longs at a time should make the large memory model (LMM) more palatable, that and the (future) fact that it'll basically run 8X faster than the current Prop. As I recall from one of Chip's webinars, the ability to load 8 longs in one fell swoop would give it the ability to run LMM code at half the rate of pure cog code, which should make for a pretty good clip. But, yeah, those of us appreciating the "everything's-a-register" symmetric beauty of the Prop have probably wished for a few more bits of internal address space for the cogs. Oh well, as was said in Contact I believe: Baby steps, baby steps, though an 8X speed bump and several other kinds of increased functionality for the Prop II (A/D, D/A, augmented counters and so on) are nothing to be sneezed at.
Andrey,
What you see on the table is not a Prop II (which doesn't exist yet). You're looking at a Prop II simulator made from a FPGA which is used for test purposes to develop the logic blocks which will eventually become the Prop II.
As it has been stated by Chip on numerous occasions that one of the big reasons for Parallax designing their own silicon in the first place was product longevity; to not be constrained by relatively short product life cycles of other brand's chips. In order to make something last for the long haul, a product has to be both unique and flexible. Does adding a simple user-designable bus (internal pins) make chip more flexible? I think so, and I'm not the only one either. If adding 64 pad-less "pins" is as simple as Chip had made it sound, then I think it's safe to say there will be more good than harm done. Not only that, but it would be at what expense? 2 Longs worth of register space?
As time goes on, and "TurboProp's" performance becomes relatively lower than future MCU's in the market, there will be plenty of attempts at squeezing out every last drop of processing power from the architecture. This is already being done with the current Prop! This is simply giving users another weapon in the arsenal. It doesn't even matter if not everyone uses is. After all, it's safe to say that not everyone will use every single ADC/DAC available on the Prop2. Does this mean it's not worth implementing? Maybe. But the flexibility it gives is invaluable, especially when you don't have as diverse a products range as other chip companies.
From what we currently know about it, the TurboProp will be significantly more flexible than the current Prop (which is already VERY flexible). Adding something as simple as internal pins will just make it that much more. Please Chip, incorporate those pins, and I'm sure you'll be satisfied with that decision in the long run when you see it being used for things you never imagined! "If you build it, they will come". The fact that more than half of the people who commented on this thread agree that it's a good idea should be sufficient proof that it will be worth while.
Comments
A 20MHz 65c02 can do a job a lot faster than a 20MHz PIC16.
6502: 4-5 clocks· · · · LDA address,X
Pic···· 48 Clocks
·
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/21/2010 4:46:47 PM GMT
I would love to see the instruction word be 40 bits instead of 32. This would allow the source and destination sections of the code word to be 13 bits each which would allow for a much bigger program/RAM space for each COG.
HUB access would still be in 8,16,or 32 bit chunks The COG could use all 40 bits for its instructions with the exception of signed math which would to be truncated to 32 bits because the sign bit has to be in the right place in order for transfers to the HUB to work out.
The big problem with writing in C is that you have to use the LMM which makes your programs run slowly. The propeller can run at a good clip but when you hit that restriction, it doesn't run so fast any more. With more COG RAM, even if it didn't use all 13 bits of address space, it would be a big improvement. You could have complete programs in COG RAM that were written in C.
This should leave the Propeller 2 code compatible with the original propeller I think so it wouldn't cause any issues other than needing to recompile and a EEPROM 25% larger to hold the extra byte per code word.
An indirect register would be great too but that is of lesser importance than being able to run decently sized programs directly in COG.
-Jack
Post Edited (Jack Buffington) : 4/8/2010 7:13:40 PM GMT
What you see on the table is not a Prop II (which doesn't exist yet). You're looking at a Prop II simulator made from a FPGA which is used for test purposes to develop the logic blocks which will eventually become the Prop II.
As time goes on, and "TurboProp's" performance becomes relatively lower than future MCU's in the market, there will be plenty of attempts at squeezing out every last drop of processing power from the architecture. This is already being done with the current Prop! This is simply giving users another weapon in the arsenal. It doesn't even matter if not everyone uses is. After all, it's safe to say that not everyone will use every single ADC/DAC available on the Prop2. Does this mean it's not worth implementing? Maybe. But the flexibility it gives is invaluable, especially when you don't have as diverse a products range as other chip companies.
From what we currently know about it, the TurboProp will be significantly more flexible than the current Prop (which is already VERY flexible). Adding something as simple as internal pins will just make it that much more. Please Chip, incorporate those pins, and I'm sure you'll be satisfied with that decision in the long run when you see it being used for things you never imagined! "If you build it, they will come". The fact that more than half of the people who commented on this thread agree that it's a good idea should be sufficient proof that it will be worth while.
-Mark S