william chan said...
Any plans to allow SPIN to declare "cog local variables" to increase speed, now that extra 128 longs are available in each cog?
Anything's possible. It would be simple to limit each Spin stack to 128 longs and keep all subroutine variables local. You just couldn't declare big arrays within nested subroutines, as they would compound and quickly exceed 128 longs.
william chan said...
Any plans to allow SPIN to declare "cog local variables" to increase speed, now that extra 128 longs are available in each cog?
Anything's possible. It would be simple to limit each Spin stack to 128 longs and keep all subroutine variables local. You just couldn't declare big arrays within nested subroutines, as they would compound and quickly exceed 128 longs.
You can devote one register (if any on spare) to spin to alter the behavior of accessing stack space locally or from hub ram
You can emulate the 1130/1800 call sequence exactly with the Propeller, without having a special return label, viz:
JMPRET MySub,#MySub+1 '11130/1800-style CALL.
MySub LONG 0-0
...
JMP MySub 'Indirect jump (return) via MySub
-Phil
Cool, Phil.· I hadn't realized that yet, and there is no assurance that I would ever have realized it.
It would then be easy to make the call sequence reentrant, I think -- but since you can't execute assembler from common storage there's no reason to do so, I guess -- except for recursive subroutines, which can be useful in control systems (or elsewhere) for calculaing various mathematical functions.· Hmmm.
Ken Peterson said...
The more I read, the more it seems the Prop II is going to be much more than a scaled-up version of the Prop I. It's going to be a whole different animal! Very exciting...
On the flip side, it's looking to me like the Prop2 won't replace Prop1 due to increased cost and complexity, but be a seperate product.· In other words, I'm thinking that many people will choose to stick with Prop1...
If there's room to split the inter-cog Dir line into DirH and DirL, I think this would eliminate the glitches without any fancy timing manipulation:
-Phil
Addendum: On second thought, the daisy-chained lines can be refactored, and reduced back to two. Priority is given to OutH, since cog outputs are ORed, and to eliminate shoot-through in the output stage.
The Prop II sounds like an exciting development. From what I read, it looks like it will be 8 cog w/ 256K ram, right? That makes sense to me, especially for those of us who need ram for video display with plenty to spare.
What I wonder about is the 128K ROM, what is in there? As one of the less sophisticated propeller users, I would find enhancements to SPIN to be extremely helpful. High on the list would be the addition of improved and simplified string handling where I can use strings as a variable type and in expressions without having to call a gazillion functions and have to remember to use pointers. Off-loading some of the most commonly used objects into ROM might also be nice (floating point, Keyboard, analog, SPI/I2C, etc) providing additional functionality whilst retaining the flexibility of programmers to choose whatever objects they want.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
Invent-O-Doc said...
Off-loading some of the most commonly used objects into ROM might also be nice (floating point, Keyboard, analog, SPI/I2C, etc) providing additional functionality whilst retaining the flexibility of programmers to choose whatever objects they want.
Not a bad idea as long as they are all configurable (no hard coded pins for example). However, I think the intent was to put the IDE and compiler into rom so the prop could become it's own freestanding computer. Is that still the goal?
Here at work, we are using a uCtlr with a 16-bit stack with a limit of 64 entries. Needing some way to pass parameters other than on the call stack, we made our own Parameter Stack with ideas from "Compiler Design in C" by Allen I. Holub, Appendix A.
Basically, the Parameter Stack is an array (of chars, in our case) with a char pointer as the stack pointer. There are a whole number of macros to work with the stack, but the most used are the stack initialization (sets the pointer to P_Stack[noparse][[/noparse]0]) and push and pop.
Back to the original question, "What would you want more of, cogs or RAM?" my answer is "YES!" To mangle a quote, "You can never have too many cogs, and you can never have too much RAM!" [noparse];)[/noparse]
Maybe there could be a note in the manual, "Why feature xxx is not in the Propeller Chip"; it would explain why there isn't serial I/O, ADC, PWM, etc. units -- push this as the ultimate in configurability: you don't need an ADC, you do not get one. If you need 7 serial I/O ports, they are ready!
I'd also like to see more explanations of how to implement these units in the Propeller. (Honestly, some of the documentation in the code leaves a LOT to be desired. "CLR A ; Clear the accumulator" is the type of comment to be avoided at all cost.)
Any plans to allow SPIN to declare "cog local variables" to increase speed, now that extra 128 longs are available in each cog?
Anything's possible. It would be simple to limit each Spin stack to 128 longs and keep all subroutine variables local. You just couldn't declare big arrays within nested subroutines, as they would compound and quickly exceed 128 longs.
That would be awesome!
It would greatly reduce the need to write objects in assembly.
Then we can use the same cog instead of allocating a new cog for an assembly object.
I can't wait.
You mean coming soon? No. The explanation that Parallax provided for the lower price (lower costs) is adequate. (Perhaps the moderators could lock this thread...)
No, it's because the manufacturing costs have dropped or been overestimated and some of the development costs have been sufficiently paid off so Parallax can afford to drop the price to encourage usage. The Prop II is still a ways off. From various visitors' comments, Chip is still working with the gate array Prop II simulator and it sounds like they're still in the process of laying out the chip. Chip and the others are very methodical and their primary goal is to have the Prop II work at least as well as the Prop I. You may have noticed that there have been no revisions or corrections to the chip design. There have been no errata published describing workarounds to errors in the chip design. The Prop II will not be offered until it's ready.
I have not been keeping with this post nor have I read the hundred plus comments on it(it has the most comments of any other post in forum history) But I simply am going to answer the title question:
I wish the propeller had 1M of RAM. 8 Cogs are fine, but it would be even better if you did away with RAM compleatly and replaced it with an external flash memory chip like an SD card. That way it would be virtual endless memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
microcontrolled, I hope they never do that. It would be sooo slooow or would eat up pins. More cog ram, relative jumps, and more hub ram along with more speed and more I/O would be nice.
:-O I never thought about the speed of the chip. But for a single chip to read a 1G memory card it would be slow. However I still wish they would increase the RAM threefold. It would give the program so much more space. I did see in the webinar how the new prop would be able to connect straight to a USB and then the prop plug would not even be needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
@OBC -- I don't think Prop I is going away, I just learned about it a few weeks ago and it is aimed like a laser beam at a bunch of projects that I had been thinking hmmmm too much circuitry bleck too much dev time ack too much Smile. It sounds like Prop II is being aimed like a laser beam at a rather different set of targerts, like video recognition and rendering. And that's great for the folks doing those things; if you need the horsepower you figure out how to mount the engine. But the most charming thing to me about Prop I is that all the high frequencies are on the die (unless you WANT to let them out) and you can stick it in a breadboard and breadboard it like a circa 1930's radio receiver, and you can make it work. I have missed being able to do that with something that can do useful work for a long time.
Yes! This is a good idea! This would double the internal RAM and give plenty of program space!! They could always make more than this though, that would make even more program space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
The cogs still have 512 longs of RAM. No nice way to increase that. With 8-long read/writes, though, and the large-model paradigm, this 512-long limit will be less of an issue than with the current chip.
That bigger ROM is going to be used, eventually, for sinking the entire development system into. This way, we can finally get OFF the PC for good, if we want to. I don't want us to keep wasting our time (and energy) writing perishable Windows apps. We've spent what has got to be cumulative man-years at Parallax wrestling with Windows to get what we needed, while at the same time we're chasing bizarre bugs which routinely result from Windows patches and upgrades. It's been like building on a sandy foundation all along, and it just gets worse and worse. There's no equity in it. We're going to have to create our own land with a limited Constitutional government. Liberty for whoever wants OFF. All on about 50 square millimeters of silicon.
Happy Independence Day!
Would it be possible to have NVRAM or some type of programmable/erasable ROM so we can update the editor?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Disclaimer: I cannot guarantee any information i post is accurate, but most of the time, it is correct.
Misses 8 bit computing
Matthew,
No, it's not possible to have NVRAM or programmable/erasable ROM. The manufacturing process doesn't support it. You have to be able to make a very specific gate oxide to produce EEPROM cells. You also have to be able to generate and manipulate relatively high voltages to erase and program the storage array. For NVRAM, you might be able to make a RAM with fairly low current draw and run that from a separate power supply input. You'd still need some kind of external battery. You can do that to some extent by shutting down all of the Propeller except for 1 cog, running that using the RCSLOW clock, and even shutting that down periodically. On the Prop I, you can probably get the current consumption down below 5uA that way.
a battery backed up ram like in rtc chips would be nice. most rtc can run for a decade off a button cell. if the prop2 had a ram area like that would be super helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are now in stock. Only $30. PCB available for $5
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
This is a very interesting topic. I did not see this before.
well IMO if there was 16 cogs, that would be 2560 MIPS total. I like the idea of more RAM, but 2560 MIPS? I mean, how could I refuse something like that.
I vote for 16 cogs!
Oh, and i'm sure you've had other people ask this before, but do you have any idea of how many Mhz the new one will run at? also any plans on when you are going to be releasing this?
How about a "hog the hub" feature - call it "COGHOG"
simple numerical prioritizing of which cogs get more hub time, so that the the hub could skip directly to a cog. Would open possiblities similar to DMA bursting. And it would make for interrupt-like cog servicing without really having to do interupts - one of the Props existing highlights. I think it could be controlled by one reg. and a new set of semiphores, but I can't guess how that would alter the hub hardware.
Is this a bad idea?
thanks
- Howard
~~~~~~
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
It will be only 8 physical COGs. But If I understand Chip it be posible to have up to 8 x 4 Logical COGs that give us 32 Logical COGs but with les cog memory.
With Logical GOGs You divide COG memory by same number as you divide one Physical COG in Logical COGs (2, 4 not sure if it be even 3).
It will be even extra indirect adresed RAM with every Physical COG (128 Longs).
It is that I understand Chips info on webinar!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
It would then be easy to make the call sequence reentrant, I think -- but since you can't execute assembler from common storage there's no reason to do so, I guess -- except for recursive subroutines, which can be useful in control systems (or elsewhere) for calculaing various mathematical functions.· Hmmm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
If there's room to split the inter-cog Dir line into DirH and DirL, I think this would eliminate the glitches without any fancy timing manipulation:
-Phil
Addendum: On second thought, the daisy-chained lines can be refactored, and reduced back to two. Priority is given to OutH, since cog outputs are ORed, and to eliminate shoot-through in the output stage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 12/16/2008 7:58:23 PM GMT
What I wonder about is the 128K ROM, what is in there? As one of the less sophisticated propeller users, I would find enhancements to SPIN to be extremely helpful. High on the list would be the addition of improved and simplified string handling where I can use strings as a variable type and in expressions without having to call a gazillion functions and have to remember to use pointers. Off-loading some of the most commonly used objects into ROM might also be nice (floating point, Keyboard, analog, SPI/I2C, etc) providing additional functionality whilst retaining the flexibility of programmers to choose whatever objects they want.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
Not a bad idea as long as they are all configurable (no hard coded pins for example). However, I think the intent was to put the IDE and compiler into rom so the prop could become it's own freestanding computer. Is that still the goal?
Basically, the Parameter Stack is an array (of chars, in our case) with a char pointer as the stack pointer. There are a whole number of macros to work with the stack, but the most used are the stack initialization (sets the pointer to P_Stack[noparse][[/noparse]0]) and push and pop.
--Rich
Maybe there could be a note in the manual, "Why feature xxx is not in the Propeller Chip"; it would explain why there isn't serial I/O, ADC, PWM, etc. units -- push this as the ultimate in configurability: you don't need an ADC, you do not get one. If you need 7 serial I/O ports, they are ready!
I'd also like to see more explanations of how to implement these units in the Propeller. (Honestly, some of the documentation in the code leaves a LOT to be desired. "CLR A ; Clear the accumulator" is the type of comment to be avoided at all cost.)
--Rich
That would be awesome!
It would greatly reduce the need to write objects in assembly.
Then we can use the same cog instead of allocating a new cog for an assembly object.
I can't wait.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Best, most current information about this is the two Chip Gracey webinars located at the
bottom of this page.
Lots of information about the Propeller II, right from the horse's mouth. [noparse]:)[/noparse]
Don't wait. There is still much to be done with Propeller I.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I wish the propeller had 1M of RAM. 8 Cogs are fine, but it would be even better if you did away with RAM compleatly and replaced it with an external flash memory chip like an SD card. That way it would be virtual endless memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
Would it be possible to have NVRAM or some type of programmable/erasable ROM so we can update the editor?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Disclaimer: I cannot guarantee any information i post is accurate, but most of the time, it is correct.
Misses 8 bit computing
No, it's not possible to have NVRAM or programmable/erasable ROM. The manufacturing process doesn't support it. You have to be able to make a very specific gate oxide to produce EEPROM cells. You also have to be able to generate and manipulate relatively high voltages to erase and program the storage array. For NVRAM, you might be able to make a RAM with fairly low current draw and run that from a separate power supply input. You'd still need some kind of external battery. You can do that to some extent by shutting down all of the Propeller except for 1 cog, running that using the RCSLOW clock, and even shutting that down periodically. On the Prop I, you can probably get the current consumption down below 5uA that way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are now in stock. Only $30. PCB available for $5
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
well IMO if there was 16 cogs, that would be 2560 MIPS total. I like the idea of more RAM, but 2560 MIPS? I mean, how could I refuse something like that.
I vote for 16 cogs!
Oh, and i'm sure you've had other people ask this before, but do you have any idea of how many Mhz the new one will run at? also any plans on when you are going to be releasing this?
P.S. OMG this tread has been revived AGIAN!!!!!!!!!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
How about a "hog the hub" feature - call it "COGHOG"
simple numerical prioritizing of which cogs get more hub time, so that the the hub could skip directly to a cog. Would open possiblities similar to DMA bursting. And it would make for interrupt-like cog servicing without really having to do interupts - one of the Props existing highlights. I think it could be controlled by one reg. and a new set of semiphores, but I can't guess how that would alter the hub hardware.
Is this a bad idea?
thanks
- Howard
~~~~~~
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
It will be only 8 physical COGs. But If I understand Chip it be posible to have up to 8 x 4 Logical COGs that give us 32 Logical COGs but with les cog memory.
With Logical GOGs You divide COG memory by same number as you divide one Physical COG in Logical COGs (2, 4 not sure if it be even 3).
It will be even extra indirect adresed RAM with every Physical COG (128 Longs).
It is that I understand Chips info on webinar!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha