I found it amusing that one of the arguments in that thread was, "8 cogs? what happens when you run out, and then you have to start putting multiple tasks on a single core?" As opposed to what? Starting with a single core, where you have to do that immediately? How is that an argument?
It's odd how engineers, a supposedly logical group, still manage to get caught up in these silly wars over which thing is better. Which language, which chip, which editor, etc, etc.. Use what works for you - it's not a holy war.
I've been lusting for more power recently in my quest to build more complicated flying things. For what I want to do, the Prop is still a fantastic choice, even though I might need two of them. I've considered using a Prop and something else, like an ARM or an Atmel. The Prop could read input from *everything* and control the servo outputs, and just communicate via high-speed serial or something with the other chip. The other chip could do the math-heavy number crunching and then send flight outputs back. So, basically, use someone's else's chip as a glorified co-processor to the Prop.
But every time I start thinking that way, I get back to, "but if I already have ONE Prop, why not just run C on the other one, and then float math is easy again, one programming environment, one chip, one instruction manual, cogs left over..."
I found it amusing that one of the arguments in that thread was, "8 cogs? what happens when you run out, and then you have to start putting multiple tasks on a single core?" As opposed to what? Starting with a single core, where you have to do that immediately? How is that an argument?
You mean this, "I have no doubt that you can do lots of fun things with a Parallax - and I have no doubt that you can do commercial projects with it. But I also have no doubt that 8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system."
Jason: I totally agree. Every time I need more from a prop, I find it way easier to just add another prop rather than a cheapie AVR or similar. The code is already there in many cases, and it is far easier (hence cheaper and faster) to use another prop. The only real problem is if production cost is a major issue - then there are always other micros, but never the same one!!!
And for the record, in case anyone other than the converted are reading this, I use 3 props in a low volume commercial design. I have commercially designed and programmed micros since 1976. Many of these designs were interfaces to mini and mainframe computers, including pcbs inside the mini/mainframe (i.e. on the bus). I regularly used multiple micros to simplify (and speedup) the project, so the prop fits precisely what I had been doing for 30+ years.
Now I only use ONE (1) micro for the job (Propeller P8X32A QFP) - same pinout, same chip, already in stock, well understood, simple to use, almost any array of internal peripherals, virtually no pinout restrictions, easy to use multiple chips. Need I say more?
... yes, why didn't Chip design the prop in the 80's? - would have made my life so much simpler!
And for the record, in case anyone other than the converted are reading this, I use 3 props in a low volume commercial design. ...
Now I only use ONE (1) micro for the job (Propeller P8X32A QFP) - same pinout, same chip, already in stock, well understood, simple to use, almost any array of internal peripherals, virtually no pinout restrictions, easy to use multiple chips. Need I say more?
See, this is the sort of thing Prop is ideally suited for, I think. Now you just need to make this story known to more of the UNconverted.
And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system.[/I]"
You might disagree, but it is an argument.
"Because I don't like the color" is also an argument. And, much like the one I posted, it's not a very good one.
I do disagree that you've lost much of the elegance. I've found many real-world applications where the Prop excels, and still have cores left over. Because the cogs can do more than a simple (ie dumb) peripheral, you can do some of your data prep on the cog that gets the data, saving time and effort in your main code.
Saying that because you might have to multiplex *something*, you might as well multiplex *everything* sounds like a child's argument.
Yep, it's a pretty poor argument against the multi-core "software as peripherals idea".
One could also say: "once you have used that UART on such and such MCU you have lost the convenience of having hardware peripherals".
Or: "Once you have used up all your MCUs cycles in that tight DDS loop you have lost, well, everything else on the chip (There is no time left to use anything)"
Or how about: "Once you have used all the RAM in your MCU you have lost the advantage of having lots of it in the first place".
See it's silly. You have resources, you use them, you don't have them anymore. An enginneers job is to use resources wisely.
Actually I have never run out of cogs even though I would have liked more. The reasons for adding extra props has been to separate processing code sections and have them communicate.
One of the props has 30 pins devoted to 512KB of SRAM and microSD, with 2 for comms. The main software on this prop is a very large program written in C (Catalina) and runs from XMM (SRAM). This prop is overclocked to 104MHz (6.5MHz xtal) (just because it can be overclocked). Another prop controls some interfaces, and a third prop controls a keypad and LCD in a remote box. Apart from the main C cog, other cogs run a mix of spin and pasm.
Each pasm program implements an intelligent I/O interface (serial, SPI, I2C, LCD, SRAM, RTC, etc, etc). The other programs are in spin and tie these together without any time constraints whatsoever. This method permits each code module (running in a core(s) = cog(s)) to be separately tested and validated. Because interaction between modules is a simple minimal interface (mostly just an input and an output cyclic buffer), tying these together is a simple exercise without the need for interrupts.
Now, it could be said that the main prop (with SRAM) could be done with an ARM or other such beast. But this would only complicate the elegant and simple hardware design, and would actually be no cheaper. If I chose a super micro (ATMega or large PIC) the problem would be that none I know of have 512KB of SRAM. Some do have very large flash. But the advantage of the prop in this system is that the software is soft-loaded (after a minimal boot from eeprom) into Hub RAM and SRAM from the SD. Other micros use flash to store programs. This provides simple software upgrades and the ability to load other programs to perform various housekeeping and computations on the databases held on the SD. FAT16/32 is used so file transfers with the PC is simple and fast for the large data files.
"Because I don't like the color" is also an argument. And, much like the one I posted, it's not a very good one.
No, that's not really "much like" the other one. In fact, it's a rather poor analogy.
I do disagree that you've lost much of the elegance. I've found many real-world applications where the Prop excels, and still have cores left over. Because the cogs can do more than a simple (ie dumb) peripheral, you can do some of your data prep on the cog that gets the data, saving time and effort in your main code.
Except this doesn't really address the poster's point at all; ie, where there simply are not enough cores, or even close, to do everything that needs to be done.
Saying that because you might have to multiplex *something*, you might as well multiplex *everything* sounds like a child's argument.
You might do well to watch your own argument more closely. You're trying to make it a simple either-or when it in fact isn't: "something" or "everything." Ie, If you're required to multiplex quite a number of things, then yes, one can fairly argue that you've lost much of the elegance.
I suspect there's a bit of the fanboi mentality at work here. It's fine to disagree, but to call the other person's argument not an "argument" at all, or "childish" is a bit much.
A point I'd like to add to Cluso's, about the advantage of using multiple Props rather than a single more powerful CPU like an ARM: The Prop leaves all the messy high-frequency signals on the chip die, vastly simplifying circuit board design. You can easily get away with simple 1-layer double sided PCB's without ground planes or solder masks whereas if you are routing 20 MHz+ memory and data buses to external memory and I/O controllers, anything less than 4-layer will be completely unworkable and many pitfalls are added with regard to inductance and capacitive coupling in the routing.
Given any multi-processor implementation, there will be limits on where it performs well. A P1 is kind of small. Given a task that is within it's limits, the implementation is pretty great. Given a task that is outside it's limits, the implementation may well not be so great.
And this is news how?
Honestly, the points made about running out of cores, or wasting them, etc... really don't speak much to the implementation, UNLESS they also highlight where they are in the scale of things; otherwise, it's just bunk that feels good but doesn't really get anywhere productive.
1. Your job. Often people are constrained in ways they really don't want to talk about much, so they will basically say, "If you can make money, do it, but I can't"
2. Product design / business: If the thing is so great, go and make products with it, "and the market will speak" which makes some kind of sense, but not too much. The market is quite large, and entire niches could change with nothing but a blip registering on the macro look at things where the dominant players are. But that's not really the metric that makes any sense. If a private company doubles and is well capitalized, it's successful regardless of what "the market" tends to say about it, and frankly, that is one of the great advantages of private companies over public ones. Parallax being private is a clear selling point to anyone who gets this.
3. Cost of technology adoption: It can be expensive to learn / deploy new things. They are saying they don't have time, money, etc... for that, but if you do, great!
Since potatohead brought it up again, I'll explain my "put your money where your mouth is" comment ...
Chip and a few others have obviously decided on a particular "sweet spot" in terms of number of cogs, amount of hub memory, and amount of cog memory for the Propeller-1 (and the Propeller-2). Some of the constraints are technological and some of them are financial. Some of them involve the intersection of the two (chip area, available foundries and processes, tool limitations, etc.) Particularly for the Propeller-2, much of this has been shared on these forums as things have progressed. One can argue with the choices made, but most of the alternatives would either have delayed the production of either chip further or driven the cost up significantly and Ken has a good idea of the markets that Parallax has sold into throughout its history and has a pretty good idea of what new markets can be entered with these devices at different price points. Some things are just unexpected like the problems they've had with the chip layout tools and the 64 I/O pin Prop-1 that was planned. If that could have been built in a timely way, it might have significantly changed the projected market for the Prop-2 and the set of features included (based on anticipated cost, affordable package size and chip area).
Anyway, Parallax made their decisions. In order for those decisions and assumptions to be changed, somebody will have to make a proposal to Parallax with some financial projections that make sense and are compelling. Parallax (mostly Ken) has already made theirs. The costs involved are high and the potential for additional sales based on more cogs or more I/O pins or more speed or whatever is quite speculative.
Anyway, Parallax made their decisions. In order for those decisions and assumptions to be changed, somebody will have to make a proposal to Parallax with some financial projections that make sense and are compelling. Parallax (mostly Ken) has already made theirs. The costs involved are high and the potential for additional sales based on more cogs or more I/O pins or more speed or whatever is quite speculative.
As is the potential for additional sales regarding everything already in place for the P2: A chip, I would add, that will be a fair amount bigger, more power hungry, more exotic, and more expensive regardless.
This is business, I suppose. There are no sure-fire predictions (though some are better than others). As for working up a marketing/financial/technical analysis, that again is something that would have to be done inside Parallax. Probably they've done that and, I hope, took a wide look around when doing so. The rest of us, like myself, can only make observations based on what we see/hear, not just on the parallax.com forums but in our day-to-day work and on the internet more generally, as we see fit. (Most of this feedback is, of course, unfiltered but not without merit.)
Put another way, I like the Propeller concept and very much wish for it to succeed, enough so that I'll even take time out to put my two cents in here and, more importantly, try to sell others - clients, work contacts, etc. - on the Prop. Not enough, however, to devote the time and resources required to do a full-blown analysis, or anything of the sort, for Parallax as a freebie. And those people leaving comments, as linked above, explaining why the Prop holds no (or little) appeal for them? They are even less likely to do something like that,
You mean this, "I have no doubt that you can do lots of fun things with a Parallax - and I have no doubt that you can do commercial projects with it. But I also have no doubt that 8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system."
You might disagree, but it is an argument.
True, it is an argument. Every micro has it's limits, however none that I am aware of have the flexibility of the propeller. In many cases you can overcome the shortage of cores by using LMM to run several of the less demanding tasks with one cog. This may not be as fast or elegant as being able to dedicate a single core per task, but it is simpler than doing it with interrupts, and still has the advantage of deterministic timing.
Not sure if it is the heat here, or I just had a mini-stroke; however....
Has anyone ever considered the possibility of a 16-bit Prop?
What if(TM) the cores were 16-bit instead of 32? While I doubt we could get 2x8 on the silicon footprint, would 12-14 be out of the question? Or, what if there were 2 sets of 5-6 cores?
Responding to you because a neuron fired off when you opined that it does seem a waste of a 32-bit core for some of the more mundane objects.
Heck, if you really want to think out of the box, 4 32-bit cores, 4 16-bit, and maybe 8 8-bit cores... Oh, the possibilities.
Not sure if it is the heat here, or I just had a mini-stroke; however....
Has anyone ever considered the possibility of a 16-bit Prop?
What if(TM) the cores were 16-bit instead of 32? While I doubt we could get 2x8 on the silicon footprint, would 12-14 be out of the question? Or, what if there were 2 sets of 5-6 cores?
Responding to you because a neuron fired off when you opined that it does seem a waste of a 32-bit core for some of the more mundane objects.
Heck, if you really want to think out of the box, 4 32-bit cores, 4 16-bit, and maybe 8 8-bit cores... Oh, the possibilities.
The main problem with a 16 bit Propeller (or 8 bit) is that the instruction set uses all 32 bits to encode the instruction. See page 22 of the Propeller datasheet.
It's not just a case of reducing the width of data from 32 to 16 bits.
If you take a close look at the Propeller instructions bit encoding you will see what a magnificently elegant machine the Propeller is. Take away even one bit, never mind 16, and you have destroyed it.
We have:
8 bits to encode the different operations.
2 bits for conditional execution on C and Z.
3 bits to specifying whether to write C, Z and result.
1 bit to indicate direct/indirect addressing.
That leaves 9 bits each to specify the source and destination addresses of the operands. That is 512 locations hence the size of the COG memory space.
All instructions are the same format and take the same time to execute (baring HUB ops).
As you see, we cannot shrink that 32 bits without making vast changes to the way the Prop works.
On the other hand...a Prop III could be 64 bit giving many more bits for src and dst fields and hence huge COG space.
Also adding more COGs will decrease each COGs band width to HUB RAM at some point performance would actually suffer. I guess no one knows where the sweet spot is, it will depend on the applications, but 8 COGs feels about right.
With introduction of hardware threads in the P II the need for more COGs is reduced.
Oh yeah, It's been damn hot here as well. 34 C in Finland, who would have thought it. My brain stops working around about 25C.
It's more like "literal" vs "memory". IE, load the value #5 into an address, or load the value from memory location 5 into an address. There's no indirect addressing on P1.
If there were to be a new P1 design variant (and I am fairly sure there will not be, other than perhaps the P1B with 64 I/O), then additional cores could perhaps be added without the video section which would reduce the cog space somewhat. Perhaps the counters could be tarted up a little to increase their flexibility, particularly at serialising the input/output. But once this opened up, then more hub ram would be another request. And then we are into the P2 territory with why not add this and that.
For those (few) of us that push the P1 to its limit there are other simple ways to achieve what we are after without resorting to using other micros, either as an adjunct, or replacement. But when it comes to the crunch, I prefer to stick with the simple to use single variant propeller chip that I always have on-hand.
The difference is much easier to explain and understand without labels.
Say COG location 10 = 5 and location 6 = 3.
If you execute "add 10, 6", this means take the value, in this case 3, from COG memory location 6 and add it to the value contained in COG location 10, in this case 5, and write the total value into COG location 10, which is 8. (5+3) The value 6 in the instruction refers to a COG memory address where a value is found to operate with.
If you were to execute "add 10, #6", this means take the value 6, and instead of using it as a COG memory address where a value is found to operate with, it is used as the value to operate with directly. The instruction means take the value in COG memory location 10, which is 5, and add the value 6 to it, then write the total into COG memory location 10, which would contain 11. (5+6)
In either case, a value is encoded into the source field of the instruction and the octothorpe "#" determines whether or not that value is used as an address from which the source value is fetched, or used directly as the source value operand to complete the instruction.
This terminology can be confusing. "Literals" in Fortran were named constants. So for example you could define "THREE" as "3". Except they did not end up getting compiled into instructions as immediate values. Rather they were kept in memory in the "literal pool".
This had the strange consequence that you could get references to literals and then use that to change their values. "THREE" could be set to 4 at run time. With some odd resulting behaviour.
Comments
It's odd how engineers, a supposedly logical group, still manage to get caught up in these silly wars over which thing is better. Which language, which chip, which editor, etc, etc.. Use what works for you - it's not a holy war.
I've been lusting for more power recently in my quest to build more complicated flying things. For what I want to do, the Prop is still a fantastic choice, even though I might need two of them. I've considered using a Prop and something else, like an ARM or an Atmel. The Prop could read input from *everything* and control the servo outputs, and just communicate via high-speed serial or something with the other chip. The other chip could do the math-heavy number crunching and then send flight outputs back. So, basically, use someone's else's chip as a glorified co-processor to the Prop.
But every time I start thinking that way, I get back to, "but if I already have ONE Prop, why not just run C on the other one, and then float math is easy again, one programming environment, one chip, one instruction manual, cogs left over..."
You might disagree, but it is an argument.
Jason, One of the recent nuggets which went under the radar a while is an add-on for floating point that Eric wrote.
Not sure if you saw it. Posted here.
http://forums.parallax.com/showthread.php/142523-using-a-COG-as-a-floating-point-coprocessor?p=1127442&viewfull=1#post1127442
All you have to do is include the C file in your project.
And for the record, in case anyone other than the converted are reading this, I use 3 props in a low volume commercial design. I have commercially designed and programmed micros since 1976. Many of these designs were interfaces to mini and mainframe computers, including pcbs inside the mini/mainframe (i.e. on the bus). I regularly used multiple micros to simplify (and speedup) the project, so the prop fits precisely what I had been doing for 30+ years.
Now I only use ONE (1) micro for the job (Propeller P8X32A QFP) - same pinout, same chip, already in stock, well understood, simple to use, almost any array of internal peripherals, virtually no pinout restrictions, easy to use multiple chips. Need I say more?
... yes, why didn't Chip design the prop in the 80's? - would have made my life so much simpler!
"Because I don't like the color" is also an argument. And, much like the one I posted, it's not a very good one.
I do disagree that you've lost much of the elegance. I've found many real-world applications where the Prop excels, and still have cores left over. Because the cogs can do more than a simple (ie dumb) peripheral, you can do some of your data prep on the cog that gets the data, saving time and effort in your main code.
Saying that because you might have to multiplex *something*, you might as well multiplex *everything* sounds like a child's argument.
J
One could also say: "once you have used that UART on such and such MCU you have lost the convenience of having hardware peripherals".
Or: "Once you have used up all your MCUs cycles in that tight DDS loop you have lost, well, everything else on the chip (There is no time left to use anything)"
Or how about: "Once you have used all the RAM in your MCU you have lost the advantage of having lots of it in the first place".
See it's silly. You have resources, you use them, you don't have them anymore. An enginneers job is to use resources wisely.
One of the props has 30 pins devoted to 512KB of SRAM and microSD, with 2 for comms. The main software on this prop is a very large program written in C (Catalina) and runs from XMM (SRAM). This prop is overclocked to 104MHz (6.5MHz xtal) (just because it can be overclocked). Another prop controls some interfaces, and a third prop controls a keypad and LCD in a remote box. Apart from the main C cog, other cogs run a mix of spin and pasm.
Each pasm program implements an intelligent I/O interface (serial, SPI, I2C, LCD, SRAM, RTC, etc, etc). The other programs are in spin and tie these together without any time constraints whatsoever. This method permits each code module (running in a core(s) = cog(s)) to be separately tested and validated. Because interaction between modules is a simple minimal interface (mostly just an input and an output cyclic buffer), tying these together is a simple exercise without the need for interrupts.
Now, it could be said that the main prop (with SRAM) could be done with an ARM or other such beast. But this would only complicate the elegant and simple hardware design, and would actually be no cheaper. If I chose a super micro (ATMega or large PIC) the problem would be that none I know of have 512KB of SRAM. Some do have very large flash. But the advantage of the prop in this system is that the software is soft-loaded (after a minimal boot from eeprom) into Hub RAM and SRAM from the SD. Other micros use flash to store programs. This provides simple software upgrades and the ability to load other programs to perform various housekeeping and computations on the databases held on the SD. FAT16/32 is used so file transfers with the PC is simple and fast for the large data files.
Except this doesn't really address the poster's point at all; ie, where there simply are not enough cores, or even close, to do everything that needs to be done.
You might do well to watch your own argument more closely. You're trying to make it a simple either-or when it in fact isn't: "something" or "everything." Ie, If you're required to multiplex quite a number of things, then yes, one can fairly argue that you've lost much of the elegance.
I suspect there's a bit of the fanboi mentality at work here. It's fine to disagree, but to call the other person's argument not an "argument" at all, or "childish" is a bit much.
Given any multi-processor implementation, there will be limits on where it performs well. A P1 is kind of small. Given a task that is within it's limits, the implementation is pretty great. Given a task that is outside it's limits, the implementation may well not be so great.
And this is news how?
Honestly, the points made about running out of cores, or wasting them, etc... really don't speak much to the implementation, UNLESS they also highlight where they are in the scale of things; otherwise, it's just bunk that feels good but doesn't really get anywhere productive.
This speaks to a few things:
1. Your job. Often people are constrained in ways they really don't want to talk about much, so they will basically say, "If you can make money, do it, but I can't"
2. Product design / business: If the thing is so great, go and make products with it, "and the market will speak" which makes some kind of sense, but not too much. The market is quite large, and entire niches could change with nothing but a blip registering on the macro look at things where the dominant players are. But that's not really the metric that makes any sense. If a private company doubles and is well capitalized, it's successful regardless of what "the market" tends to say about it, and frankly, that is one of the great advantages of private companies over public ones. Parallax being private is a clear selling point to anyone who gets this.
3. Cost of technology adoption: It can be expensive to learn / deploy new things. They are saying they don't have time, money, etc... for that, but if you do, great!
Chip and a few others have obviously decided on a particular "sweet spot" in terms of number of cogs, amount of hub memory, and amount of cog memory for the Propeller-1 (and the Propeller-2). Some of the constraints are technological and some of them are financial. Some of them involve the intersection of the two (chip area, available foundries and processes, tool limitations, etc.) Particularly for the Propeller-2, much of this has been shared on these forums as things have progressed. One can argue with the choices made, but most of the alternatives would either have delayed the production of either chip further or driven the cost up significantly and Ken has a good idea of the markets that Parallax has sold into throughout its history and has a pretty good idea of what new markets can be entered with these devices at different price points. Some things are just unexpected like the problems they've had with the chip layout tools and the 64 I/O pin Prop-1 that was planned. If that could have been built in a timely way, it might have significantly changed the projected market for the Prop-2 and the set of features included (based on anticipated cost, affordable package size and chip area).
Anyway, Parallax made their decisions. In order for those decisions and assumptions to be changed, somebody will have to make a proposal to Parallax with some financial projections that make sense and are compelling. Parallax (mostly Ken) has already made theirs. The costs involved are high and the potential for additional sales based on more cogs or more I/O pins or more speed or whatever is quite speculative.
This is business, I suppose. There are no sure-fire predictions (though some are better than others). As for working up a marketing/financial/technical analysis, that again is something that would have to be done inside Parallax. Probably they've done that and, I hope, took a wide look around when doing so. The rest of us, like myself, can only make observations based on what we see/hear, not just on the parallax.com forums but in our day-to-day work and on the internet more generally, as we see fit. (Most of this feedback is, of course, unfiltered but not without merit.)
Put another way, I like the Propeller concept and very much wish for it to succeed, enough so that I'll even take time out to put my two cents in here and, more importantly, try to sell others - clients, work contacts, etc. - on the Prop. Not enough, however, to devote the time and resources required to do a full-blown analysis, or anything of the sort, for Parallax as a freebie. And those people leaving comments, as linked above, explaining why the Prop holds no (or little) appeal for them? They are even less likely to do something like that,
True, it is an argument. Every micro has it's limits, however none that I am aware of have the flexibility of the propeller. In many cases you can overcome the shortage of cores by using LMM to run several of the less demanding tasks with one cog. This may not be as fast or elegant as being able to dedicate a single core per task, but it is simpler than doing it with interrupts, and still has the advantage of deterministic timing.
Not sure if it is the heat here, or I just had a mini-stroke; however....
Has anyone ever considered the possibility of a 16-bit Prop?
What if(TM) the cores were 16-bit instead of 32? While I doubt we could get 2x8 on the silicon footprint, would 12-14 be out of the question? Or, what if there were 2 sets of 5-6 cores?
Responding to you because a neuron fired off when you opined that it does seem a waste of a 32-bit core for some of the more mundane objects.
Heck, if you really want to think out of the box, 4 32-bit cores, 4 16-bit, and maybe 8 8-bit cores... Oh, the possibilities.
The main problem with a 16 bit Propeller (or 8 bit) is that the instruction set uses all 32 bits to encode the instruction. See page 22 of the Propeller datasheet.
It's not just a case of reducing the width of data from 32 to 16 bits.
If you take a close look at the Propeller instructions bit encoding you will see what a magnificently elegant machine the Propeller is. Take away even one bit, never mind 16, and you have destroyed it.
We have:
8 bits to encode the different operations.
2 bits for conditional execution on C and Z.
3 bits to specifying whether to write C, Z and result.
1 bit to indicate direct/indirect addressing.
That leaves 9 bits each to specify the source and destination addresses of the operands. That is 512 locations hence the size of the COG memory space.
All instructions are the same format and take the same time to execute (baring HUB ops).
As you see, we cannot shrink that 32 bits without making vast changes to the way the Prop works.
On the other hand...a Prop III could be 64 bit giving many more bits for src and dst fields and hence huge COG space.
Also adding more COGs will decrease each COGs band width to HUB RAM at some point performance would actually suffer. I guess no one knows where the sweet spot is, it will depend on the applications, but 8 COGs feels about right.
With introduction of hardware threads in the P II the need for more COGs is reduced.
Oh yeah, It's been damn hot here as well. 34 C in Finland, who would have thought it. My brain stops working around about 25C.
Isn't it "Immediate/direct"?
Having indirect addressing would indeed make coding loops/tables easier but it doesn't easily fit the architecture.
Yes, I think you are right.
I think there was some confusion over this terminology in the Propeller manual. It's a long time since I checked.
For those (few) of us that push the P1 to its limit there are other simple ways to achieve what we are after without resorting to using other micros, either as an adjunct, or replacement. But when it comes to the crunch, I prefer to stick with the simple to use single variant propeller chip that I always have on-hand.
Say COG location 10 = 5 and location 6 = 3.
If you execute "add 10, 6", this means take the value, in this case 3, from COG memory location 6 and add it to the value contained in COG location 10, in this case 5, and write the total value into COG location 10, which is 8. (5+3) The value 6 in the instruction refers to a COG memory address where a value is found to operate with.
If you were to execute "add 10, #6", this means take the value 6, and instead of using it as a COG memory address where a value is found to operate with, it is used as the value to operate with directly. The instruction means take the value in COG memory location 10, which is 5, and add the value 6 to it, then write the total into COG memory location 10, which would contain 11. (5+6)
In either case, a value is encoded into the source field of the instruction and the octothorpe "#" determines whether or not that value is used as an address from which the source value is fetched, or used directly as the source value operand to complete the instruction.
This had the strange consequence that you could get references to literals and then use that to change their values. "THREE" could be set to 4 at run time. With some odd resulting behaviour.