I guess I'm Tail-End Charlie here.· Are those the only choices for enhancement, more Cogs or more RAM?· I'd like both, but there are other things equally important, or perhaps more important:
(1) a way to execute assembler language directly from shared memory.· I'm very new to the Propeller, though very experienced in assembler on other machines from building-fillers to pinhead-size.· Having to copy a program to a Cog's private memory in order to execute it (as seems necessary for Assembler in the Propeller) seems simply a waste.· But perhaps my understanding of the Propeller·is not yet perfect.
(2) a way to write reentrant code in assembler.· In any multiprocessing (or even merely multiprogramming) environment, reentrancy is essential -- especially if memory is limited.· Why make it necessary to have a separate copy of any subroutine one wishes to use?· Instead, it should be possible (as it is on almost any other multiprogramming system) to write a subroutine in such a way that multiple threads can use it with true simultaneity, without either making a separate copy or queueing up for sequential reuse of the code.· Currently this is precluded by (among other things) the way CALL stores a return address.· In the general world of computing, that method was wisely abandoned many decades ago.
If (1) and (2) were both possible, the Spin interpreter could be made reentrant and could be executed directly from ROM;·perhaps there wouldn't be any reason for Cog memory at all.· Memory could be flat, and assembler·programs could be much larger.· Also, of course, this would eliminate the waste from putting small programs in fixed-size memories per Cog.·
(3) a more versatile locking/queueing mechanism.· Right now, as I understand·it,·there are eight locks.··There ought to be many more.··Also it should be possible to request several in a single request.· If, for example, ·Cog0 needs locks 3 and 4, and Cog1 needs locks 4 and 5, and Cog2 needs locks 3 and 5,·it takes very meticulous programming, and a lot of extra code, to avoid deadlocks.· The ability to make a conditional request for multiple locks in a single request would make things easier.· As in Oklahoma, the Cogs should sing, if you can't give me all, give me nothin'.
Also, of course, interrupts.· These could be optional; use'em or not.· I read the defense, not having interrupts makes timing determinate among Cogs.· This is untrue, because there exist Hub instructions that take varying time and because there exist what should be called queued resources but are called mutually exclusive resources.· But even if it were strictly true, and timing were strictly determinate, so what?· I have thought long and hard, and I haven't thought of even the weakest reason why one would care whether timing is determinate or not.· To be useful, computers of all sizes must interact with an indeterminate universe of objects, from humans to servos and beyond.
1) Executing assembly directly from shared memory isn't going to happen. You really have to think of the shared memory as an I/O device. You have to use special instructions to access it, there's a large speed differential between local memory and shared memory, and the shared memory is a different size from local memory (byte addressable vs. long addressable).
2) The native instruction set doesn't need to provide reentrancy because there's no multiprocessing going on within any single cog. There are no interrupts, so the code doesn't get interrupted and possibly reentered.
3) The current locking mechanism really is adequate for the task. Most interprocessor communications, particularly in the case of I/O, can be done without locks anyway since it fits the single producer/consumer case where locks (other than the atomic nature of shared memory access) are not necessary.
4) Interrupts ... The Propeller, certainly the Prop I, is a microcontroller. It was designed to be able to do "bit-banged" type I/O for all sorts of devices like video generation (TV and VGA), asynchronous serial (UART-like), and synchronous serial (SPI/I2C) transfers where deterministic timing is absolutely necessary.
Mike, your arguments remind me of the following definition from Ambrose Bierce's The Devil's Dictionary:
Ostrich, n.
A large bird to which (for its sins, doubtless) nature has denied that hinder toe in which so many pious naturalists have seen a conspicuous evidence of design. The absence of a good working pair of wings is no defect, for, as has been ingeniously pointed out, the ostrich does not fly.
It is often hardest for those with the most experience in programming to come to grips with the unique and marvelous architecture that ithe Propeller presents. Everything that Mike says is well-founded, logical, and not the punchline of a "just so" story, as you seem to suggest (albeit with genteel eloquence). I would encourage you to dive in and immerse yourself in the Propeller. Only then will the benefits of its elegant design become manifest. Until then, one can't possibly know that eight locks are more than enough, or that interrupts and reentrancy are unnecessary. Once it soaks in, what may have appeared initially to be throwbacks or mere iconoclasms will reveal themselves as essential elements of a consistent vision. Moreover, you will rediscover just how much fun programming can be!
Ah, Phil. I think the Propeller is a marvelous device. I agree that reentrancy is not necessary, and that interrupts can be done without. I also think they'd be profound enhancements, and when I discovered this thread (earlier today), it seemed to me that the question being asked was not "is the Propeller any good" (of course it is), but "how could it be made even better".
I reject, though, the idea that callowness and inexperience enhance understanding. That's what teenagers think. Later they find out their parents weren't so dumb after all.
But it's time for a friendly grin and a hearty "Merry Christmas".
This is where a kernel runs in the COG, fetching instructions from the HUB, to be executed in COG space. There are then three options. SPIN, PASM native ASM running in COG space, and LMM where the larger program lives in the HUB.
IMHO, the LMM code could very easily be reentrant, as the Kernel would be capable of providing those facilities as "opcodes" leveraging gaps in the current instruction set. This is a supervisor kind of model, unlike either SPIN or PASM.
Carl Hayes said...
I reject, though, the idea that callowness and inexperience enhance understanding. That's what teenagers think.
I can't disagree with that, nor would I ever want to forget the things I've learned in order to recapture my teenage years! But, as in Zen, there's something to be said for setting experience aside momentarily and approaching novel concepts with a "beginner's mind". I guess that's what I was hinting at, since the Propeller is such a unique animal.
OTOH, aspects of it take me back to my first assembly programming, on the IBM 1130/1800, which had a similar architecture for subroutine calls (i.e. no native stacks or reentrancy; return address inserted into code on a CALL). It's still a pleasant memory, which programming the Propeller has helped to recall. (Only now, I know it's not reentrant and don't care. Back then, I'd never heard of reentrancy, so I couldn't care. )
Phil Pilgrim (PhiPi) said...
OTOH, aspects of it take me back to my first assembly programming, on the IBM 1130/1800, which had a similar architecture for subroutine calls (i.e. no native stacks or reentrancy; return address inserted into code on a CALL).
Now that take me back.· It wasn't my first assembler (that was on a 709, with vacuum tubes), but I spent some years doing process control -- furnace and forehearth temperatures in a glass bottle plant -- in assembler on an 1800.· Even then I wanted reentrancy -- not because I had multiple processes that needed the same subroutine (I didn't), but because certain successive-approximation calculations would have been more efficient if I could have used recursion (which requires reentrancy).· In later· (and earlier) work in 360s and 370s, I used recursive subroutines (subs that called themselves)·in many calculations.
The call mechanism in 1800s was a little easier to use, since it stored the return address at the entry point rather than at the exit point, and the return was an indirect branch through the entry.· Thus you didn't need a special kind of label, or any label, for the return-branch instruction; and you could return from anywhere.· Notwithstanding that, Propeller assembly is light-years better, easier,·and more advanced.· Gee,·I wish it had macros though.
I still have, somewhere around here, many thousands of lines of 1800 assembler.· It's the pack-rat in me.
@Carl: You may not need deterministic timing in the applications you've worked on, but there are types of applications where it is important. Deterministic timing is important in applications like generating a video signal or when interacting "at the bare metal" with signals or other chips. When you have deterministic timing, you can safely eke every last ounce of performance out of the chip, safe in the knowledge that every iteration of your loop is going to take exactly as much time as you planned for and no longer. For a TV video driver, if you miss the window for the next pixel or HSync, then the display will glitch or even cause the TV to fail to lock on. In this case missing the time window by a little bit isn't just a little bad, it's a lot bad - all or nothing.
When you have a system with nondeterministic timing, the only way to guarantee you don't miss the timing window is to plan for the worst-case situation; if there is a large spread between the best case and the worst case timing, then in a sense you're wasting CPU power during the times when the CPU hasn't been interrupted.
Your point that hub instructions are nondeterministic is incorrect. Hub instructions can take between 7 to 22 clock cycles, but they ARE deterministic. Yes there is a range of timings they can take, but that timing isn't random, and it also doesn't depend on any interaction with anything else any other cog is doing. The window for hub access goes around and around at a constant rate regardless of whether other cogs use their windows or not, and as long as you hit the hub access at the same time as the last loop iteration, you will wait the exact same number of clocks as you did the last iteration. Which means that as long as the rest of your loop is deterministic, the timing of your hub instruction is EFFECTIVELY deterministic because it will only have to wait exactly the same number of clocks as the last time you went through the loop before, and it never changes as long as the code executed doesn't change.
I think the point about interrupts is that with interrupts your code can be interrupted by other, unrelated code, but with cogs & no interrupts the cog run without being interfered with by other programs. You can't equate hub instructions or queued resources to interrupts because the design of the Propeller allocates hub resources in a deterministic round robin fashion to all 8 cogs in turn specifically to avoid that kind of nondeterminancy. The hub doesn't immediately "jump" to the next cog that needs the access, so you don't get any difference whatsoever in timing between 8 cogs accessing a resource, or just one accessing it.
TJHJ said...
Since this thread hit the 1st page again, How is prop II coming? Any Estimate on a release date?
TJ
It's moving along well. We added an extra 128x32 dual-port RAM to each cog which can function as a color lookup table for video, but also as a FIFO to mate PLL-timed I/O with the cog. The final chip is still probably a year away, maybe sooner. We hope to do a test chip soon to verify all the functional blocks.
I have one idea to ad External memory Controler to COGs.
That is not so much hardware and only few extra instructions
Can write more only if You are interested
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Dennis Ferron said... as long as you hit the hub access at the same time as the last loop iteration, you will wait the exact same number of clocks
And how would you assure that?· I think you can't assure hitting the hub assess at the same point in every iteration.· But I don't claim to know, absolutely.· Lessee -- if you put a hub instruction at the beginning of every loop -- no, it could still hit at the beginning of your hub access slot, or at the end, or in between.· Am I wrong about that?
Dennis Ferron said...
I think the point about interrupts is that with interrupts your code can be interrupted by other, unrelated code, but with cogs & no interrupts the cog run without being interfered with by other programs. You can't equate hub instructions or queued resources to interrupts because the design of the Propeller allocates hub resources in a deterministic round robin fashion to all 8 cogs in turn specifically to avoid that kind of nondeterminancy. The hub doesn't immediately "jump" to the next cog that needs the access, so you don't get any difference whatsoever in timing between 8 cogs accessing a resource, or just one accessing it.
With interrupts, if need be, you can mask them while doing a time-critical service.· Trust me, that has never, in years and years, been a problem.· You can always avoid being interrupted.
I think you confuse quantization with determinacy.· As I understand it, in the Propeller, your times are quantized.· You might get access at this· instant, or at that instant or another instant, but not in between.· That's quantization.· But unless you always hit at the same instant, it's indeterminacy.
All this is meaningless anyway.· Experience shows that, even with slow processors, time-critical service to peripheral devices is easy with interrupts, and also easy with dedicated processors.· No particular advantage for either scheme, and no real need for defensiveness when brainstorming is being done.
Again, I hope your Xmas (or whatever you choose to celebrate -- I celebrate them all) is filled with cheer, happiness, and Propeller goodies.
@Phil:· Ah, re-entrant coding brings me back to the Friden/Singer/ICL System Ten (1969-1993 and mainly went out of use in 1999, though still a few remain). It had up to 20 partitions (aka cogs) and common memory shared between them all (aka hub memory). The partitions were hardware time sliced. The re-entrant sections of the operating system were in common (hub). It was a RISC machine with no stack - the return address was exactly as per the Propeller. I wrote many huge re-entrant routines which would be loaded up in the morning and function all day long. Those were the days...·· And one reason why I love the Propeller - the other is·the pure simplicity of the Prop·with multiple cogs and no interrupts.
It's a shame the Prop II will not have more cogs (even a restricted set) but that is sealed. Hey, what about a Prop I as a separate section of the chip sharing just I/O???? Would be great for compatability too!!
Chip just revealed an·extra 128 longs in each cog - how much do you want to bet we will find even more uses for this???
@Chip: Is it possible to have an instruction to block swap it to main cog memory? I presume it does not have the 4-way access as main cog ram, so a way to quickly swap (yes swap, not copy) it to cog (fixed location ok) would be nice (128 clock cycles?? or maybe less (32 cycles)·if the swap could be 4 longs wide (as I gather the hub transfer may be).
Chip -· any info on the improved counters per cog ?? (pretty please)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ We used to marvel at Maxwell Smart·having a phone in his shoe. Now we just say what a stupid place to put a phone!
That FIFO sounds great! Does it work for input as well as output?
BTW, I had an idea for the direction registers, which is probably too late to bring up — but who knows? How much trouble would it be to split each of DIRA and DIRB into two: one for the upper (PMOS) driver, and the other for the lower (NMOS) driver? I've had a couple instances lately where this would be handy. One was emulating an ideal diode op-amp circuit using a counter (for a clamp); the other involved driving video for an overlay. Both had workarounds requiring external circuitry; but being able to select the drive direction(s), instead of just "both" or "none" would be handy — especially when the output is coming from a counter or the video circuitry, which can't be intermediated in real time by programming. As an alternative, being able to output to DIRx from a counter instead of OUTx would also work. But this is less satisfactory for the video circuitry, since you'd have to choose between DIRx and OUTx for all the pins it's driving.
While I'm at it, how hard would it be to add positive outputs (ina') to the negative outputs (!ina') that the counters are capable of? This would make it possible to create inputs with programmable (via resistors) hysteresis.
I'm constantly amazed at what those counters can do! They're really great for replacing external analog circuitry.
As Chip explained to me, the Dual Port RAM is capable of simultaneous Reads and Writes to two totally different addresses.· As it currently is in Layout you could potentially Write to two locations at the same time however I think that there will be logic guards·against this·scenario to prevent a collision of any kind.· Especially since each side of the RAM port could potentially be clocked at different rates. You can Read from any two addresses, or you can Write to one while you’re Reading from another, but never Write to both at the same time. · As far as the other request, couldn't you set the I/O so that it would default as an output to HIGH or LOW depending on the high side or low side that you wanted to drive, and then just modulate the I/O·as an input or an output to effectively get what you want. · Along similar lines, I think (I'm not positive) that you will be able to configure the counters·to a register other than the·I/O register... This means that you could direct the output to control the pin direction rather than its Output state. ·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
This dual-port SRAM has two completely separate interfaces for clock, enable, address, and data. It's basically two identical·SRAMs which converge at the four-transistor guts of each unique bit cell. There will never be a write/write conflict because it will never be used in such a way. When one side is configured for writing, the other side will be configured for reading. In FIFO modes, there will be a status bit to say if the read counter is equal to the write counter, so that when one side writes a value, the other will know when to read it.
The counters are going to undergo some·changes yet to accomodate the FIFO modes, while the video CLUT usage is all done. There are going to be not just 1- and 2-bit pixel modes, but 4- and 8-bit modes, also, which require the color lookup table (CLUT) SRAM (same as FIFO, different mode). All video is maintained internally as 5:5:5 RGB and there is hardware colorspace conversion for PAL/NTSC. Also, thanks to Andre LaMothe's input, we've got texture mapping, pixel lighting, and alpha blending with auto-incrementing pointers·-- all in one instruction. So, we should be able to do neat 3D polygon rendering.
Phil, we could split the DIR bits for PMOS and NMOS control, no problem. There is now a single set of IN/OUT/DIR/ALT registers which mux to different 32-bit ports. I could add two separate registers for PMOS and NMOS control which DIR could affect simultaneously, so that code is not always burdened with maintaining both PMOS and NMOS registers.
Sapheia, what is your idea for external memory access?
Chip Gracey said...
I could add two separate registers for PMOS and NMOS control which DIR could affect simultaneously, so that code is not always burdened with maintaining both PMOS and NMOS registers.
That would be great! I assume, then, that when PDIRx <> NDIRx, anything read from DIRx would be meaningless, right? For that matter, would changing PDIRx or NDIRx have any effect at all on values read from DIRx, or would it simply be the last value written, regardless of whether it was currently effective?
Another approach might be to have two registers (PENx and NENx) whose bits get inverted and ANDed with the the bits in DIRx to enable the PMOS and NMOS drivers, respectively. That way, when they're at their default zero values, both the high-side and low-side drivers are enabled whenever the corresponding DIRx bit is a one. Writing a one-bit to either PENx or NENx would disable it's corresponding driver. If both had one-bits in any given position, the DIRx register would have no effect, since the corresponding pin couldn't be driven either high or low.
-Phil
Addendum: I don't know if I explained the alternate approach very well. Here's a diagram:
Wow - this is getting more and more exciting about the Prop II. It slices, it dices and it does texture mapping too!!!! Oh man I am going to have to get myself on the beta tester list as I have several ideas already cooking that the Prop I can't do because of limited memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope www.tdswieter.com
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...
I gather from recent posts that the chip will be able to drive 24-bit RGB directly in full color.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
I can't wait to get the Prop 2. I'm trying to make a Digital Dash for my motorcycle and with all I want it to do I just don't have enough memory to do it on the Prop 1
Also, thanks to Andre LaMothe's input, we've got texture mapping, pixel lighting, and alpha blending with auto-incrementing pointers·-- all in one instruction. So, we should be able to do neat 3D polygon rendering.
This sounds awesome, could you share a little more detail on this instruction?
3D graphics engines for games is what I do for a living. I'd love to get a Prop2 3d renderer running!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I now realize that the circuit I presented for separating high and low output enables is glitchy. In the Prop I, enable and output state changes are two separate operations, so output glitches cannot occur. But in the proposed circuit, enable can be changed when the output changes. Somehow the timing has to be corrected so that disables get gated to the final tri-state buffer before state changes, and enables get gated after. Is it possible to choreograph this in the few nanoseconds available, especially given the additional gate delays to derive the enable signal?
I now realize that the circuit I presented for separating high and low output enables is glitchy. In the Prop I, enable and output state changes are two separate operations, so output glitches cannot occur. But in the proposed circuit, enable can be changed when the output changes. Somehow the timing has to be corrected so that disables get gated to the final tri-state buffer before state changes, and enables get gated after. Is it possible to choreograph this in the few nanoseconds available, especially given the additional gate delays to derive the enable signal?
-Phil
Phil,
I was thinking the same thing when I woke up this morning. Must be careful about glitches. I think the small amount of gate circuitry can be made tightly and characterized well so that this won't be an issue.
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...
I gather from recent posts that the chip will be able to drive 24-bit RGB directly in full color.
It will only do 15-bit RGB (5:5:5). 15 RGB bits + HSYNC fit nicely into 16-bits (a CLUT value), and the memory requirements are much more modest than a full blown 8:8:8 implementation would be.
Comments
(1) a way to execute assembler language directly from shared memory.· I'm very new to the Propeller, though very experienced in assembler on other machines from building-fillers to pinhead-size.· Having to copy a program to a Cog's private memory in order to execute it (as seems necessary for Assembler in the Propeller) seems simply a waste.· But perhaps my understanding of the Propeller·is not yet perfect.
(2) a way to write reentrant code in assembler.· In any multiprocessing (or even merely multiprogramming) environment, reentrancy is essential -- especially if memory is limited.· Why make it necessary to have a separate copy of any subroutine one wishes to use?· Instead, it should be possible (as it is on almost any other multiprogramming system) to write a subroutine in such a way that multiple threads can use it with true simultaneity, without either making a separate copy or queueing up for sequential reuse of the code.· Currently this is precluded by (among other things) the way CALL stores a return address.· In the general world of computing, that method was wisely abandoned many decades ago.
If (1) and (2) were both possible, the Spin interpreter could be made reentrant and could be executed directly from ROM;·perhaps there wouldn't be any reason for Cog memory at all.· Memory could be flat, and assembler·programs could be much larger.· Also, of course, this would eliminate the waste from putting small programs in fixed-size memories per Cog.·
(3) a more versatile locking/queueing mechanism.· Right now, as I understand·it,·there are eight locks.··There ought to be many more.· ·Also it should be possible to request several in a single request.· If, for example, ·Cog0 needs locks 3 and 4, and Cog1 needs locks 4 and 5, and Cog2 needs locks 3 and 5,·it takes very meticulous programming, and a lot of extra code, to avoid deadlocks.· The ability to make a conditional request for multiple locks in a single request would make things easier.· As in Oklahoma, the Cogs should sing, if you can't give me all, give me nothin'.
Also, of course, interrupts.· These could be optional; use'em or not.· I read the defense, not having interrupts makes timing determinate among Cogs.· This is untrue, because there exist Hub instructions that take varying time and because there exist what should be called queued resources but are called mutually exclusive resources.· But even if it were strictly true, and timing were strictly determinate, so what?· I have thought long and hard, and I haven't thought of even the weakest reason why one would care whether timing is determinate or not.· To be useful, computers of all sizes must interact with an indeterminate universe of objects, from humans to servos and beyond.
That's my input.· Two cents, please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
The cogs vs. ram discussion is long past.
1) Executing assembly directly from shared memory isn't going to happen. You really have to think of the shared memory as an I/O device. You have to use special instructions to access it, there's a large speed differential between local memory and shared memory, and the shared memory is a different size from local memory (byte addressable vs. long addressable).
2) The native instruction set doesn't need to provide reentrancy because there's no multiprocessing going on within any single cog. There are no interrupts, so the code doesn't get interrupted and possibly reentered.
3) The current locking mechanism really is adequate for the task. Most interprocessor communications, particularly in the case of I/O, can be done without locks anyway since it fits the single producer/consumer case where locks (other than the atomic nature of shared memory access) are not necessary.
4) Interrupts ... The Propeller, certainly the Prop I, is a microcontroller. It was designed to be able to do "bit-banged" type I/O for all sorts of devices like video generation (TV and VGA), asynchronous serial (UART-like), and synchronous serial (SPI/I2C) transfers where deterministic timing is absolutely necessary.
Ostrich, n.
A large bird to which (for its sins, doubtless) nature has denied that hinder toe in which so many pious naturalists have seen a conspicuous evidence of design. The absence of a good working pair of wings is no defect, for, as has been ingeniously pointed out, the ostrich does not fly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
It is often hardest for those with the most experience in programming to come to grips with the unique and marvelous architecture that ithe Propeller presents. Everything that Mike says is well-founded, logical, and not the punchline of a "just so" story, as you seem to suggest (albeit with genteel eloquence). I would encourage you to dive in and immerse yourself in the Propeller. Only then will the benefits of its elegant design become manifest. Until then, one can't possibly know that eight locks are more than enough, or that interrupts and reentrancy are unnecessary. Once it soaks in, what may have appeared initially to be throwbacks or mere iconoclasms will reveal themselves as essential elements of a consistent vision. Moreover, you will rediscover just how much fun programming can be!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
I reject, though, the idea that callowness and inexperience enhance understanding. That's what teenagers think. Later they find out their parents weren't so dumb after all.
But it's time for a friendly grin and a hearty "Merry Christmas".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
This is where a kernel runs in the COG, fetching instructions from the HUB, to be executed in COG space. There are then three options. SPIN, PASM native ASM running in COG space, and LMM where the larger program lives in the HUB.
IMHO, the LMM code could very easily be reentrant, as the Kernel would be capable of providing those facilities as "opcodes" leveraging gaps in the current instruction set. This is a supervisor kind of model, unlike either SPIN or PASM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
OTOH, aspects of it take me back to my first assembly programming, on the IBM 1130/1800, which had a similar architecture for subroutine calls (i.e. no native stacks or reentrancy; return address inserted into code on a CALL). It's still a pleasant memory, which programming the Propeller has helped to recall. (Only now, I know it's not reentrant and don't care. Back then, I'd never heard of reentrancy, so I couldn't care.
Cheers!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
The call mechanism in 1800s was a little easier to use, since it stored the return address at the entry point rather than at the exit point, and the return was an indirect branch through the entry.· Thus you didn't need a special kind of label, or any label, for the return-branch instruction; and you could return from anywhere.· Notwithstanding that, Propeller assembly is light-years better, easier,·and more advanced.· Gee,·I wish it had macros though.
I still have, somewhere around here, many thousands of lines of 1800 assembler.· It's the pack-rat in me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
When you have a system with nondeterministic timing, the only way to guarantee you don't miss the timing window is to plan for the worst-case situation; if there is a large spread between the best case and the worst case timing, then in a sense you're wasting CPU power during the times when the CPU hasn't been interrupted.
Your point that hub instructions are nondeterministic is incorrect. Hub instructions can take between 7 to 22 clock cycles, but they ARE deterministic. Yes there is a range of timings they can take, but that timing isn't random, and it also doesn't depend on any interaction with anything else any other cog is doing. The window for hub access goes around and around at a constant rate regardless of whether other cogs use their windows or not, and as long as you hit the hub access at the same time as the last loop iteration, you will wait the exact same number of clocks as you did the last iteration. Which means that as long as the rest of your loop is deterministic, the timing of your hub instruction is EFFECTIVELY deterministic because it will only have to wait exactly the same number of clocks as the last time you went through the loop before, and it never changes as long as the code executed doesn't change.
I think the point about interrupts is that with interrupts your code can be interrupted by other, unrelated code, but with cogs & no interrupts the cog run without being interfered with by other programs. You can't equate hub instructions or queued resources to interrupts because the design of the Propeller allocates hub resources in a deterministic round robin fashion to all 8 cogs in turn specifically to avoid that kind of nondeterminancy. The hub doesn't immediately "jump" to the next cog that needs the access, so you don't get any difference whatsoever in timing between 8 cogs accessing a resource, or just one accessing it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
TJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
It was long time ago!
I have one idea to ad External memory Controler to COGs.
That is not so much hardware and only few extra instructions
Can write more only if You are interested
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I think you confuse quantization with determinacy.· As I understand it, in the Propeller, your times are quantized.· You might get access at this· instant, or at that instant or another instant, but not in between.· That's quantization.· But unless you always hit at the same instant, it's indeterminacy.
All this is meaningless anyway.· Experience shows that, even with slow processors, time-critical service to peripheral devices is easy with interrupts, and also easy with dedicated processors.· No particular advantage for either scheme, and no real need for defensiveness when brainstorming is being done.
Again, I hope your Xmas (or whatever you choose to celebrate -- I celebrate them all) is filled with cheer, happiness, and Propeller goodies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
It's a shame the Prop II will not have more cogs (even a restricted set) but that is sealed. Hey, what about a Prop I as a separate section of the chip sharing just I/O???? Would be great for compatability too!!
Chip just revealed an·extra 128 longs in each cog - how much do you want to bet we will find even more uses for this???
@Chip: Is it possible to have an instruction to block swap it to main cog memory? I presume it does not have the 4-way access as main cog ram, so a way to quickly swap (yes swap, not copy) it to cog (fixed location ok) would be nice (128 clock cycles?? or maybe less (32 cycles)·if the swap could be 4 longs wide (as I gather the hub transfer may be).
Chip -· any info on the improved counters per cog ?? (pretty please)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
We used to marvel at Maxwell Smart·having a phone in his shoe. Now we just say what a stupid place to put a phone!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
That FIFO sounds great! Does it work for input as well as output?
BTW, I had an idea for the direction registers, which is probably too late to bring up — but who knows? How much trouble would it be to split each of DIRA and DIRB into two: one for the upper (PMOS) driver, and the other for the lower (NMOS) driver? I've had a couple instances lately where this would be handy. One was emulating an ideal diode op-amp circuit using a counter (for a clamp); the other involved driving video for an overlay. Both had workarounds requiring external circuitry; but being able to select the drive direction(s), instead of just "both" or "none" would be handy — especially when the output is coming from a counter or the video circuitry, which can't be intermediated in real time by programming. As an alternative, being able to output to DIRx from a counter instead of OUTx would also work. But this is less satisfactory for the video circuitry, since you'd have to choose between DIRx and OUTx for all the pins it's driving.
While I'm at it, how hard would it be to add positive outputs (ina') to the negative outputs (!ina') that the counters are capable of? This would make it possible to create inputs with programmable (via resistors) hysteresis.
I'm constantly amazed at what those counters can do! They're really great for replacing external analog circuitry.
Thanks,
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 12/16/2008 3:45:10 AM GMT
As Chip explained to me, the Dual Port RAM is capable of simultaneous Reads and Writes to two totally different addresses.· As it currently is in Layout you could potentially Write to two locations at the same time however I think that there will be logic guards·against this·scenario to prevent a collision of any kind.· Especially since each side of the RAM port could potentially be clocked at different rates. You can Read from any two addresses, or you can Write to one while you’re Reading from another, but never Write to both at the same time.
·
As far as the other request, couldn't you set the I/O so that it would default as an output to HIGH or LOW depending on the high side or low side that you wanted to drive, and then just modulate the I/O·as an input or an output to effectively get what you want.
·
Along similar lines, I think (I'm not positive) that you will be able to configure the counters·to a register other than the·I/O register... This means that you could direct the output to control the pin direction rather than its Output state.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
The counters are going to undergo some·changes yet to accomodate the FIFO modes, while the video CLUT usage is all done. There are going to be not just 1- and 2-bit pixel modes, but 4- and 8-bit modes, also, which require the color lookup table (CLUT) SRAM (same as FIFO, different mode). All video is maintained internally as 5:5:5 RGB and there is hardware colorspace conversion for PAL/NTSC. Also, thanks to Andre LaMothe's input, we've got texture mapping, pixel lighting, and alpha blending with auto-incrementing pointers·-- all in one instruction. So, we should be able to do neat 3D polygon rendering.
Phil, we could split the DIR bits for PMOS and NMOS control, no problem. There is now a single set of IN/OUT/DIR/ALT registers which mux to different 32-bit ports. I could add two separate registers for PMOS and NMOS control which DIR could affect simultaneously, so that code is not always burdened with maintaining both PMOS and NMOS registers.
Sapheia, what is your idea for external memory access?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Another approach might be to have two registers (PENx and NENx) whose bits get inverted and ANDed with the the bits in DIRx to enable the PMOS and NMOS drivers, respectively. That way, when they're at their default zero values, both the high-side and low-side drivers are enabled whenever the corresponding DIRx bit is a one. Writing a one-bit to either PENx or NENx would disable it's corresponding driver. If both had one-bits in any given position, the DIRx register would have no effect, since the corresponding pin couldn't be driven either high or low.
-Phil
Addendum: I don't know if I explained the alternate approach very well. Here's a diagram:
________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 12/16/2008 8:46:05 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
I gather from recent posts that the chip will be able to drive 24-bit RGB directly in full color.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
3D graphics engines for games is what I do for a living. I'd love to get a Prop2 3d renderer running!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I now realize that the circuit I presented for separating high and low output enables is glitchy. In the Prop I, enable and output state changes are two separate operations, so output glitches cannot occur. But in the proposed circuit, enable can be changed when the output changes. Somehow the timing has to be corrected so that disables get gated to the final tri-state buffer before state changes, and enables get gated after. Is it possible to choreograph this in the few nanoseconds available, especially given the additional gate delays to derive the enable signal?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
I was thinking the same thing when I woke up this morning. Must be careful about glitches. I think the small amount of gate circuitry can be made tightly and characterized well so that this won't be an issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.