As far as I understand there are situations where one want to share complex data structures between many readers and writers where atomic operations are essential for coordinatig access and achieving mutual exclusion.
If you have a solution to that problem that does not use atomic operations the computer science world would like to know.
Something looks wrong with the opcode counts Roy made. LOCKSET is used 3 times but LOCKCLR is used 7 times. Normally I would expect them to be occurring in matched pairs. Someone has written some odd code there.
LOCKNEW is only used once but there are 4 occurrences of LOCKRET ! What on earth is going on there?
Which object(s) in OBEX are using locks like this I'm curious to see what a mess the code is:)
Intelligent/Smart IO could be used for the pins collectively. Then each pin could be--dare I say it--a "pin head" or "pinhead." Each pin is a little brain in and of itself, separate from the COGS. Kind of matches the beanie, doesn't it (which some want retired, though I'm okay with it)? I'll probably lose my account for mentioning "pinhead," though. Well, it's been fun.
With the simularities of this new Propeller beast to the P1, it would seem a shame to change the nomenclature. People here have complained many times about XMOS changing the terminology used in conjunction with their chips (and disputed the truthfulness). Keep (or choose) something unique...and push/market that. Set your own rules. Lead, don't follow.
I like how Ken is thinking (planning ahead) and getting ready to position or market this killer chip that Chip & Co. are developing. Keep up the good work!!
The naming of the Propeller parts and/or it's product brief have to change because nobody knows what it is or that it is even a micro-controller. I can demonstrate this fact as follows:
They are a big electronics distributor around here. They have a huge catalogue. They have a lot of micro-controllers. If you go to the micro-controllers section of the catalogue you will not find the Propeller in any category. Not even "Miscellaneous". You will not find Propellers under the "processors" section either.
Anyone one searching for a micro-controller there for their next project will not ever hear of a Propeller.
So where are the Propellers? Well they can be found under:
HOLD ON NOW, DON'T SWEAR LIKE THAT, MODERATOR MONKEY WILL EAT YOU.
"Smile" was used because I didn't want MODERATOR MONKEY to EAT ME!
Its also commonly used by farmers here in minnesota, and trailer trash, to avoid getting beat by their wives.
I have been eaten by Moderator Monkey so many times in the past, that my 100% American Blood, born, raised, "10 bajillion lakes(minnesohda)(dontchakno)", FREE speech, normally uncensored,,, should clearly show, as some of you mods here know me well.
I'm sure ive given some mods blisters from all the darn modding I have forced upon them. Actually I'm pretty sure im on a few mods, "people's posts to visit daily" job list.
See I had to edit "darn" from its original format.
So the new collective for 'core' is "A Farm of Cores".
But where would we exchange our "HAY"?
Can we exchange code for this Farm on a HAY exchange? Would we be welcome there? http://www.hayexchange.com/index.php
I believe Cluso has made a strong case for jettisoning a lot of the non-standard terminology that quite possibly been as detrimental to the Prop as any technical one.
Cogs, tiles, whatever you want to call them, they ultimately get referred to as cores when explained to someone new.
Remember the customer people.
We are trying to get them to pick the Prop.over the competitor's solution. One chip vs another.
Wasting that critically short window of time by also.forcing them to learn the dogma of.Prop orthodoxy is
About the worst thing that can be done. If you want to'differentiate' yourself, do it with features and solutions, not what is seen as simply marketing spin.
Lbook at Microsoft and the Start menu fiasco. Pre-release focus groups said don'remove it, upon RTM everyone said the same, after the first patch it was repeated again, and again. Finally, after losing $Billions and market share are they coming to their senses.
How does this relate?
Parallel has had the better part of a decade in which to expose/inculcate people with the Prop mythos.
Outisde of this forum I have never seen more than a few posts bother to explain the Prop except in standard uC terminology. Ie.cores,etc.
If you want to be succesful in an arena where decisions are made from careful comparison, then make it as easy as possible for you to be comparable.
If you want to sell yourself/product as the next big thing, better than sliced.bread, as the One True Way, maybe start a religion?
Instead of asking the choir, spend a few bucks on a simple focus group and look at the feedback.
I got on someone's list in the Bay Area, and the occasional $50 for an hour of my time with 9 other people is interesting.
+1 for the excellent renaming suggestions for cog ram and hub too.
I absolutely agree, Core(s) it should be!
It will then come up in search entries and be compared with other multi-core chips. We are seeing numerous ARM multi-cores appearing. Microcontrollers will no doubt follow, and then Parallax is clearly in the lead. And you will get a lot of free press because they understand what cores is.
Next, I think the cog memory should be Core RAM Registers/Memory and described as Private Core RAM Memory 2KB (496 x 32bit longs with 128bit wide access to Common Memory).
And lastly, the hub memory should be described as Common RAM Memory 512KB (byte/word/long/quadlong), shared between all Cores, and usable as expanded instruction and/or memory space.
We have to ditch our favourite words to embrace the market that should be able to understand these simpler definitions.
I'm are 64 years born in Polen
But from 1976 living in Sweden --- needed change country (I think You know what ones control them in that time) and I worked to end theirs control
It is Propeller that started learn me English language (had before no problems to read it but never write in it)
It was Forum that press in me to that.
I will try to get the docs done soon for the current Prop2 FPGA files. This project will carry on, as it's the long-term goal. I think by the time we make it, we'll have built-in DDR3 support for really fast memory.
I am curious. How old are you? I've always gotten the feeling that either you're a really old Swede or you've come from Eastern Europe.
Old MacChip he had a farm, E-I-E-I-O,
And on that farm he had a Propeller, E-I-E-I-O,
With a COG COG here and a COG COG there
Here a COG, there a COG, everywhere a COG COG
Old MacChip he had a farm, E-I-E-I-O.
Old MacChip he had a farm, E-I-E-I-O,
And on that farm he had a Juglandaceae, E-I-E-I-O,
With a ...
...I don't know what sound does a walnut tree make?
COG is OK to me, It separates the prop from the world. But what does it stand for? The new propeller reminds me for a butterfly, as now we just doubled the 8 cores, Like having a second wing. II0: I²O might be better, as people know I²C and may be curious to understand, what I²O means.
COG is OK to me, It separates the prop from the world.
That's exactly the problem, it separates the prop from the world. Nobody reading this gibberish about COGS and HUB and Spin has any clue what the thing is and they move on to the vast array of other devices they can use that are nicely categorized in online catalogues by familiar criteria like RAM size, FLASH size, MIPS, MHz, data/instruction width, IO pin count, number of ADCs, etc.
I believe that calling a spade a "spade" is a very good idea.
Those processors in the Propeller should be referred to as "cores" all the world and his dog (see picture) knows what "cores" are. Or call them "processors" even.
That shared RAM should just be called "RAM", coz that is what it is.
The HUB thing need not even be mentioned in product briefs, that's just a teeny technical detail about how RAM is shared among processors.
Trust me, Chip. When I use locks, it's not because they're a luxury. It's because there was no other way to do it.
Also, don't forget, you're looking at locks used in assembly code only. They're much more prevalent in Spin code. In any event, getting rid of them would be a huge mistake!
Although one master hardware lock is enough (since slave locks can be programmed), it can create a bottleneck. One lock per core has been about right for the P1, so I would suggest the same going forward.
-Phil
Phil, could you give an example of why you want the CTRs to remain? If the pin brains handle all kinds of things, the only thing I see the CTRs doing is operating on pins that are not close together. The CTRs have random pin access. Pins aside, you do a lot with FRQ and PHS things, right? These are certainly quicker to access than by messaging a pin serially. I don't have any great desire to remove the CTRs, but I do wonder what you see in them. Thanks in advance for any input here.
There was some discussion started regarding locks, flags, etc. on the P2.
ozpropdev started a thread for it, there was also considerable discussion in the main P2 thread.
At least a few of us asked to increase the number of locks, ideally to 32. At the time you indicated it was simple to do, but if adding more is one more thing to break the camels back I understand.
- Local (within a COG )Locks
I also brought up having local locks within the COGs (only needed if we have threading), and through some discussion we realized that SETB could be used to create a 'lock' since it returns the previous state of the bit in the C flag.
So that leads to - can we maybe keep SETB and CLRB, they were very useful, not just for the lock usage.
- Flags
I requested having some flags that could be accessed by the COGs so the basic signalling between COGs could happen without using HUB operations.
One of the concerns was arbitration in the case of multiple COGs concurrently writting to a flag.
I've given that some more thought, and really they would work fine and get around the arbitration issue if writting a flag was a HUB operation and reading was a non-HUB operation.
The reason for the read being non-HUB is to avoid the expence of using a HUB operation for polling.
The idea is the flags are for signalling ('hand waving'), actual transfer of data would happen via the HUB.
Cluso99 has also presented some concepts for having adjacent COG's communicate without using the HUB.
The flags and COG to COG communication would be useful for keeping power consumption down by reducing the need to access the HUB.
Maybe thinking about some of these in terms of the simplified COGs and factoring out functionality into shared resources like you are considering for the CORDIC, etc. might be useful.
I'm are 64 years born in Polen
But from 1976 living in Sweden --- needed change country (I think You know what ones control them in that time) and I worked to end theirs control
It is Propeller that started learn me English language (had before no problems to read it but never write in it)
It was Forum that press in me to that.
Oh, that's pretty interesting.
We need you to get better and come to the USA and redo whatever you did in Poland.
Actually, thinking about it a bit as I checked the greenhouse, it's "RAM" and "Registers".
RAM because a headline figure of 512k puts the P1+ on par, if not better than, many other chips out there.
Registers because if you write "512-words RAM" anywhere it's just going to confuse people. '512 words?'. 'surely that a typo and they mean 512k?' '512 words?' 'What useful work can you do with 512 words of RAM?'
There was some discussion started regarding locks, flags, etc. on the P2.
ozpropdev started a thread for it, there was also considerable discussion in the main P2 thread.
At least a few of us asked to increase the number of locks, ideally to 32. At the time you indicated it was simple to do, but if adding more is one more thing to break the camels back I understand.
- Local (within a COG )Locks
I also brought up having local locks within the COGs (only needed if we have threading), and through some discussion we realized that SETB could be used to create a 'lock' since it returns the previous state of the bit in the C flag.
So that leads to - can we maybe keep SETB and CLRB, they were very useful, not just for the lock usage.
- Flags
I requested having some flags that could be accessed by the COGs so the basic signalling between COGs could happen without using HUB operations.
One of the concerns was arbitration in the case of multiple COGs concurrently writting to a flag.
I've given that some more thought, and really they would work fine and get around the arbitration issue if writting a flag was a HUB operation and reading was a non-HUB operation.
The reason for the read being non-HUB is to avoid the expence of using a HUB operation for polling.
The idea is the flags are for signalling ('hand waving'), actual transfer of data would happen via the HUB.
Cluso99 has also presented some concepts for having adjacent COG's communicate without using the HUB.
The flags and COG to COG communication would be useful for keeping power consumption down by reducing the need to access the HUB.
Maybe thinking about some of these in terms of the simplified COGs and factoring out functionality into shared resources like you are considering for the CORDIC, etc. might be useful.
Thanks,
Chris Wardell
I've thought about this, too, but lots of nets between all cogs, would take a lot of power. Between adjacent cogs, maybe not so much - if they actually wound up adjacent in the layout.
Comments
Re: Locks
As far as I understand there are situations where one want to share complex data structures between many readers and writers where atomic operations are essential for coordinatig access and achieving mutual exclusion.
If you have a solution to that problem that does not use atomic operations the computer science world would like to know.
Something looks wrong with the opcode counts Roy made. LOCKSET is used 3 times but LOCKCLR is used 7 times. Normally I would expect them to be occurring in matched pairs. Someone has written some odd code there.
LOCKNEW is only used once but there are 4 occurrences of LOCKRET ! What on earth is going on there?
Which object(s) in OBEX are using locks like this I'm curious to see what a mess the code is:)
With the simularities of this new Propeller beast to the P1, it would seem a shame to change the nomenclature. People here have complained many times about XMOS changing the terminology used in conjunction with their chips (and disputed the truthfulness). Keep (or choose) something unique...and push/market that. Set your own rules. Lead, don't follow.
I like how Ken is thinking (planning ahead) and getting ready to position or market this killer chip that Chip & Co. are developing. Keep up the good work!!
The naming of the Propeller parts and/or it's product brief have to change because nobody knows what it is or that it is even a micro-controller. I can demonstrate this fact as follows:
Go to http://www.elfaelectronics.com And try to find the Propeller chips.
They are a big electronics distributor around here. They have a huge catalogue. They have a lot of micro-controllers. If you go to the micro-controllers section of the catalogue you will not find the Propeller in any category. Not even "Miscellaneous". You will not find Propellers under the "processors" section either.
Anyone one searching for a micro-controller there for their next project will not ever hear of a Propeller.
So where are the Propellers? Well they can be found under:
"Electronics & Automation > Embedded / Wireless / Education > Kits / Prototyping & Development Boards > Breadboards / Kits > Propeller Microcontrollers"
in the ELFA menu system. WTF? Not even under "digital circuits" WTF?
On the plus side ELFA does carry a lot of Parallax products.
mindrobots, That's a bonus "COGlets" sounds awful.
It's quite instructive to go and read the P1 datasheet to see how confused even Parallax are with their terms...
8-Cog Multiprocessor Microcontroller
eight processors, called cogs
32-bit Multicore Architecture
eight symmetric 32-bit processors (cogs) in one microcontroller
In that case, DO IT!
Get it out to the factory, and on the parallax store by JUNE? (lol?) (timing is everything)
(then we can pair it with this SODIMM PI and KICK Smile!)
http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/
By the way, how big is that package anyway?
the well-known picture below shows the P1 to be a 1-COG processor...
...as a cog is the tooth on a rotating gearwheel.
+100
And by someone in the USA! Perhaps he is British.
HOLD ON NOW, DON'T SWEAR LIKE THAT, MODERATOR MONKEY WILL EAT YOU.
"Smile" was used because I didn't want MODERATOR MONKEY to EAT ME!
Its also commonly used by farmers here in minnesota, and trailer trash, to avoid getting beat by their wives.
I have been eaten by Moderator Monkey so many times in the past, that my 100% American Blood, born, raised, "10 bajillion lakes(minnesohda)(dontchakno)", FREE speech, normally uncensored,,, should clearly show, as some of you mods here know me well.
I'm sure ive given some mods blisters from all the darn modding I have forced upon them. Actually I'm pretty sure im on a few mods, "people's posts to visit daily" job list.
See I had to edit "darn" from its original format.
So the new collective for 'core' is "A Farm of Cores".
But where would we exchange our "HAY"?
Can we exchange code for this Farm on a HAY exchange? Would we be welcome there?
http://www.hayexchange.com/index.php
Cogs, tiles, whatever you want to call them, they ultimately get referred to as cores when explained to someone new.
Remember the customer people.
We are trying to get them to pick the Prop.over the competitor's solution. One chip vs another.
Wasting that critically short window of time by also.forcing them to learn the dogma of.Prop orthodoxy is
About the worst thing that can be done. If you want to'differentiate' yourself, do it with features and solutions, not what is seen as simply marketing spin.
Lbook at Microsoft and the Start menu fiasco. Pre-release focus groups said don'remove it, upon RTM everyone said the same, after the first patch it was repeated again, and again. Finally, after losing $Billions and market share are they coming to their senses.
How does this relate?
Parallel has had the better part of a decade in which to expose/inculcate people with the Prop mythos.
Outisde of this forum I have never seen more than a few posts bother to explain the Prop except in standard uC terminology. Ie.cores,etc.
If you want to be succesful in an arena where decisions are made from careful comparison, then make it as easy as possible for you to be comparable.
If you want to sell yourself/product as the next big thing, better than sliced.bread, as the One True Way, maybe start a religion?
Instead of asking the choir, spend a few bucks on a simple focus group and look at the feedback.
I got on someone's list in the Bay Area, and the occasional $50 for an hour of my time with 9 other people is interesting.
+1 for the excellent renaming suggestions for cog ram and hub too.
Thanks for info on Doc's
I'm are 64 years born in Polen
But from 1976 living in Sweden --- needed change country (I think You know what ones control them in that time) and I worked to end theirs control
It is Propeller that started learn me English language (had before no problems to read it but never write in it)
It was Forum that press in me to that.
Old MacChip he had a farm, E-I-E-I-O,
And on that farm he had a Propeller, E-I-E-I-O,
With a COG COG here and a COG COG there
Here a COG, there a COG, everywhere a COG COG
Old MacChip he had a farm, E-I-E-I-O.
Old MacChip he had a farm, E-I-E-I-O,
And on that farm he had a Juglandaceae, E-I-E-I-O,
With a ...
...I don't know what sound does a walnut tree make?
Also, maybe HUB RAM should be "shared RAM" and COG RAM should be "private RAM"?
Or, HUB RAM as last level cache?
Propeller are not multiCOG, not multiCORE.
It is Parallel 8 Multi uComputers.
MultiCORE. stands only for X simple CPU's that still needs some extras to work
Propellers COG's ALL are standalone uComputers that everyone can work indepedently
'Shared RAM' and 'Local RAM'?
I believe that calling a spade a "spade" is a very good idea.
Those processors in the Propeller should be referred to as "cores" all the world and his dog (see picture) knows what "cores" are. Or call them "processors" even.
That shared RAM should just be called "RAM", coz that is what it is.
The HUB thing need not even be mentioned in product briefs, that's just a teeny technical detail about how RAM is shared among processors.
Phil, could you give an example of why you want the CTRs to remain? If the pin brains handle all kinds of things, the only thing I see the CTRs doing is operating on pins that are not close together. The CTRs have random pin access. Pins aside, you do a lot with FRQ and PHS things, right? These are certainly quicker to access than by messaging a pin serially. I don't have any great desire to remove the CTRs, but I do wonder what you see in them. Thanks in advance for any input here.
It 14 meters on the edge, divided by 1,000.
There was some discussion started regarding locks, flags, etc. on the P2.
ozpropdev started a thread for it, there was also considerable discussion in the main P2 thread.
http://forums.parallax.com/showthread.php/153329-Locks-flags-and-Port-D-XCH-discussion
Several things:
- Locks
At least a few of us asked to increase the number of locks, ideally to 32. At the time you indicated it was simple to do, but if adding more is one more thing to break the camels back I understand.
- Local (within a COG )Locks
I also brought up having local locks within the COGs (only needed if we have threading), and through some discussion we realized that SETB could be used to create a 'lock' since it returns the previous state of the bit in the C flag.
So that leads to - can we maybe keep SETB and CLRB, they were very useful, not just for the lock usage.
- Flags
I requested having some flags that could be accessed by the COGs so the basic signalling between COGs could happen without using HUB operations.
One of the concerns was arbitration in the case of multiple COGs concurrently writting to a flag.
I've given that some more thought, and really they would work fine and get around the arbitration issue if writting a flag was a HUB operation and reading was a non-HUB operation.
The reason for the read being non-HUB is to avoid the expence of using a HUB operation for polling.
The idea is the flags are for signalling ('hand waving'), actual transfer of data would happen via the HUB.
Cluso99 has also presented some concepts for having adjacent COG's communicate without using the HUB.
http://forums.parallax.com/showthread.php/155014-We-re-looking-at-5-Watts-in-a-BGA!?p=1256534&viewfull=1#post1256534
The flags and COG to COG communication would be useful for keeping power consumption down by reducing the need to access the HUB.
Maybe thinking about some of these in terms of the simplified COGs and factoring out functionality into shared resources like you are considering for the CORDIC, etc. might be useful.
Thanks,
Chris Wardell
Oh, that's pretty interesting.
We need you to get better and come to the USA and redo whatever you did in Poland.
Thanks for all your input here, Sapieha.
Actually, thinking about it a bit as I checked the greenhouse, it's "RAM" and "Registers".
RAM because a headline figure of 512k puts the P1+ on par, if not better than, many other chips out there.
Registers because if you write "512-words RAM" anywhere it's just going to confuse people. '512 words?'. 'surely that a typo and they mean 512k?' '512 words?' 'What useful work can you do with 512 words of RAM?'
Shame, it's just a gnats whisker too big to fit on a module with a pin out like so :
Won't it fit? That's a 64-pin 0.9 package right? So 22.86mm between rows of pins?
I've thought about this, too, but lots of nets between all cogs, would take a lot of power. Between adjacent cogs, maybe not so much - if they actually wound up adjacent in the layout.
I will increase the locks to 32 in the hub.
Electronics for Dogs...
Chapter 1 - Do NOT hike your leg up on any electrical or electronic apparatus...
C.W.