Is there a document describing this SDRAM interface? So I guess you're saying we can run LMM-style code from SDRAM without first loading it into hub memory, right?
The latest Propeller 2 document describes the interface from an instruction standpoint. Chip's had it working on the FPGA for a long time.
I really hope that someday we will have better systems that get created because, finally, the inspiration came to throw off the old shackles that C has subtly placed on computing for the past 30 years. When this happens, I think we will all know it, because computing will suddenly be fresh again and something to get excited about.
I can certainly go along with this! I wonder what that new language will look like?
I share Sapieha's sentiments that C has been an often-misguiding force in the evolution of computing.
I suppose it made fine sense for large-memory, 'academically'-ideal systems of the time, but it has been shoehorned into everything else since, and has been dissuasive to the advent of computing architectures to which it would not be amenable. I suppose an ARM chip is what it is because of C. I understand that there are mountains of C code and many reasons to support C, but C's hegemony does not inspire me, personally, and I really hope that someday we will have better systems that get created because, finally, the inspiration came to throw off the old shackles that C has subtly placed on computing for the past 30 years. When this happens, I think we will all know it, because computing will suddenly be fresh again and something to get excited about.
Thank you, Chip!! C has been the tail that wags the hardware dog for far too long. I'm glad to see an influential voice that not only recognizes that fact but has the wherewithal to do something about it.
Thank you, Chip!! C has been the tail that wags the hardware dog for far too long. I'm glad to see an influential voice that not only recognizes that fact but has the wherewithal to do something about it.
-Phil
I'm still waiting to see what will be done about it. I think Spin is a very useful language for the Propeller but it isn't really a step in a new direction.
External RAM
Each cog now features the ability, with the help of the I/O pins, to quickly stream parallel data in or out of the I/O pins aligned to a clock source. Data is streamed to/from the CLUT or WRQUAD overlay. From there it can be quickly feed to the video generator or to the internal HUB RAM. XFR feeds data 16 Bits or 32 Bits at a time at the system clock speed.
Parallax Semiconductor
Propeller 2 Detailed Preliminary Feature List v2.0 Page 14 of 18
Table 17: External RAM Instruction Machine Code Mnemonic Operand Operation
000011_zcn_1_cccc_dddnnnnnn_011101001
SETXFR
D/#n
Setup the direction of the data stream, the source and destination of the data stream, and the size of
Then there's that ever cryptic image on page 15.
My biggest concern is that 3.3V SDRAM chips may go end of life before P2 ships. They are already hard to find.
I'm a bit to tired to follow this but are we seeing that a Prop II can fetch code into COG from SDRAM as data and then execute that code in COG. Like a current XMM solution but withou going through a cache driver COG and HUB RAM.
This sounds major.
I'm a bit to tired to follow this but are we seeing that a Prop II can fetch code into COG from SDRAM as data and then execute that code in COG. Like a current XMM solution but withou going through a cache driver COG and HUB RAM.
This sounds major.
Yes, it certainly does!! That's why I asked for more details on how that mechanism works.
When does the GCC team get to hear the details of all these goodies?
Sounds like Prop II gestation is comming to an end. Ideally the PropII GCC target should be ready at its birth.
NOT only lazy BUT had not future thinking on it.
Hi write what was good for him NOT what was GOOD for CPU's and its development.
And now we need live with it !!!
You lost me here! As memory serves C was developed as a high level assembler for the PDP-11. Chips like the 8080 didn't exist and certainly the concept of microcontrollers, PICs and propeller wasn't even something that was imaginable!! The fact that a processor like the propeller, SX series chips, etc can even run code written in C is a testament to the forward thinking of K&R!!!
This is due to specifics in prop1, and I hope similar or even more parallel-ability in the prop2.
Booting over 50 prop1's in the same time frame as a single prop, and have it all be reliable, is pretty cool. Using real random object using pll, to break each identical slave into unique slaves.
Usually most microcontroller and chips have communication specifics that halt parallel loading of drones from a master. But not the prop1.
I hope to see identical or even better mass parallel-ability in the prop2.
Fundamentally, the Spin language is a small subset of C++. The syntactical differences of indentation versus braces has no bearing on how well it maps to the hardware. C++ could be compiled to the same bytecodes that Spin is compiled to, and produce identical code. Any arguments against the subset of C++ that matches Spin would also apply to Spin. I don't understand how someone can argue for the advantages of Spin over C/C++ when Spin is just a subset of C/C++.
Fundamentally, the Spin language is a small subset of C++. The syntactical differences of indentation versus braces has no bearing on how well it maps to the hardware. C++ could be compiled to the same bytecodes that Spin is compiled to, and produce identical code. Any arguments against the subset of C++ that matches Spin would also apply to Spin. I don't understand how someone can argue for the advantages of Spin over C/C++ when Spin is just a subset of C/C++.
No but you could argue that both Spin and C++ are a step up from C. I think the biggest feature that Spin is missing is the ability to pass objects as parameters to functions.
I'm still waiting to see what will be done about it. I think Spin is a very useful language for the Propeller but it isn't really a step in a new direction.
You know with the additional memory and performance of the of the P-II, users are necessarily bound to C or it's minions. There is nothing stopping people from doing a Free Pascal/Delphi cross compiler or even a Oberon subset if one is interested in Algol type languages.
Personally I prefer Pascal/Delphi/Oberon over C or at least what passes for C today compared to 20+ years ago.
For fun, I simulated an 11-inverter ring oscillator at the same worst-case conditions which we are designing the Prop II to run at. The oscillator ran at 787MHz.
I ran the simulation again with typical-case conditions and it ran at 1,264MHz. That's 60% faster.
If these differences translate to the real world, the Prop II would run typically at over 256MHz on the bench, though we'll spec it at 160MHz for worst-case conditions.
For more fun, I ran the simulation at ideal-case conditions (which aren't likely to ever happen, as you can't keep the junction temperatures at 0C, but this case must be considered when doing hold-time checks). The ring oscillator ran at 1,776MHz. That would translate to 361MHz!
That is point on my statement. Hi have writ it to theirs NEED's. BUT not say it was build with forward thinking --- AS C and theirs friends have to close architecture.
And are both memory hungry and have problems to implement new CPU's architectures.
As it still are used on new CPU's are -- First as Chip said -- Much code people think them simply can move from one CPU to another. Second "Professional programmer's next religious thinking that it can solve all theirs problems that them have with programing.
BUT no matter what language You use IF You are not good programmer LANGUAGE can't help You fix programming You CPU/System --- With other words IT cant program themselves.
You lost me here! As memory serves C was developed as a high level assembler for the PDP-11. Chips like the 8080 didn't exist and certainly the concept of microcontrollers, PICs and propeller wasn't even something that was imaginable!! The fact that a processor like the propeller, SX series chips, etc can even run code written in C is a testament to the forward thinking of K&R!!!
Oh boy, language wars -- again! Sapieha, you can call cognew just as easily from C as you can Spin. Perhaps the only advantage to Spin for beginners is that you are forced to stay within a limited language, so that novices can master the Spin language in a month or two. Of course, it's possible to create a C++ compiler that limits you to the same subset as Spin, and it could also be mastered in a month or two. Then you can program almost any other device in the world with the same subset of C++. With Spin you can only program the Prop.
To be honest, Spin is harder for novices to learn than the equivalent subset of C++. The reason is that Spin allows novices to get into trouble with pointers and strings, and they have no idea how they got into trouble. A good C++ compiler will prevent novices from passing integers to a function that expects a string pointer, or manipulating two floating point numbers as if they were integers.
Sorry my English. Some people --- Say that threading (time swapping between program parts) on single core CPU's are parallel processing.---
Have little problems what word I need use to it
Sorry my English. Some people --- Say that threading (time swapping between program parts) on single core CPU's are parallel processing.---
Have little problems what word I need use to it
I see what you mean. You're right, of course. Running multiple threads in a single core usually involves time-slicing or just cooperative threading but in either case only one thread is actually running at a time. However, both commonly used C compilers for the Propeller allow threads to run in separate COGs just like Spin does.
Comments
The latest Propeller 2 document describes the interface from an instruction standpoint. Chip's had it working on the FPGA for a long time.
Thank you, Chip!! C has been the tail that wags the hardware dog for far too long. I'm glad to see an influential voice that not only recognizes that fact but has the wherewithal to do something about it.
-Phil
Sorry. Inadequate. Hopefully Chip will have time to give this proper treatment at some point.
This is all that anyone has to work from publicly:
http://www.parallaxsemiconductor.com/Products/propeller2specs Section on memory.
http://www.parallaxsemiconductor.com/sites/default/files/parallax/Propeller2DetailedPreliminaryFeatureList-v2.0.pdf Page 13-14.
Then there's that ever cryptic image on page 15.
My biggest concern is that 3.3V SDRAM chips may go end of life before P2 ships. They are already hard to find.
Chip said once in a presentation that a 3.3v swing is required. Has that changed?
This sounds major.
At 1.8V, things are switching too slowly (50ns, as opposed to 250ps at 3.3V) to be useful for talking to high-tech DDRx memories.
Sounds like Prop II gestation is comming to an end. Ideally the PropII GCC target should be ready at its birth.
You lost me here! As memory serves C was developed as a high level assembler for the PDP-11. Chips like the 8080 didn't exist and certainly the concept of microcontrollers, PICs and propeller wasn't even something that was imaginable!! The fact that a processor like the propeller, SX series chips, etc can even run code written in C is a testament to the forward thinking of K&R!!!
Thanks Chip. Actually, I just checked Mouser and Digikey. There is more SDRAM stock there now than in the spring. Hope it holds up.
At one point I noticed a way to parallel load and clock sink 50+ prop 1 chips, in the same time as a single load for a single prop.
http://forums.parallax.com/showthread.php?127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.
Re: See schematic.
http://forums.parallax.com/attachment.php?attachmentid=76386&d=1292500099
This is due to specifics in prop1, and I hope similar or even more parallel-ability in the prop2.
Booting over 50 prop1's in the same time frame as a single prop, and have it all be reliable, is pretty cool. Using real random object using pll, to break each identical slave into unique slaves.
Usually most microcontroller and chips have communication specifics that halt parallel loading of drones from a master. But not the prop1.
I hope to see identical or even better mass parallel-ability in the prop2.
Wouldn't that be "fifth" then?
Actually, thinking about it, it's odd that the Prop for which every one touts deterministic execution, has this real random property built in.
You can abuse the PLL via the video generator just the same as you could in Prop I to get the truly random WAITVID timing phenomenon.
This is absolutely correct.
BUT it is very good step for beginners and even professionals in Parallel processing. DON't mix my statement with threading on Single core processors.
Personally I prefer Pascal/Delphi/Oberon over C or at least what passes for C today compared to 20+ years ago.
I ran the simulation again with typical-case conditions and it ran at 1,264MHz. That's 60% faster.
If these differences translate to the real world, the Prop II would run typically at over 256MHz on the bench, though we'll spec it at 160MHz for worst-case conditions.
For more fun, I ran the simulation at ideal-case conditions (which aren't likely to ever happen, as you can't keep the junction temperatures at 0C, but this case must be considered when doing hold-time checks). The ring oscillator ran at 1,776MHz. That would translate to 361MHz!
That is point on my statement. Hi have writ it to theirs NEED's. BUT not say it was build with forward thinking --- AS C and theirs friends have to close architecture.
And are both memory hungry and have problems to implement new CPU's architectures.
As it still are used on new CPU's are -- First as Chip said -- Much code people think them simply can move from one CPU to another. Second "Professional programmer's next religious thinking that it can solve all theirs problems that them have with programing.
BUT no matter what language You use IF You are not good programmer LANGUAGE can't help You fix programming You CPU/System --- With other words IT cant program themselves.
To be honest, Spin is harder for novices to learn than the equivalent subset of C++. The reason is that Spin allows novices to get into trouble with pointers and strings, and they have no idea how they got into trouble. A good C++ compiler will prevent novices from passing integers to a function that expects a string pointer, or manipulating two floating point numbers as if they were integers.
Sorry my English. Some people --- Say that threading (time swapping between program parts) on single core CPU's are parallel processing.---
Have little problems what word I need use to it