The board is real, the price is real and the company also . Those chips deliver 1600 MIPS at 30 $ each. Of course a x86 will be cheaper but it is something else.
Not bad. XMP-64 looks good too. The issue would be worse for the rookie programmers, since Propeller chips are made for even the insane as it's easier to program. What CPU can I think of that's difficult to program? PowerPC won the award for that. (I have written few softwares for that. I can tell you from experiences. I still like PowerPC, anyways, as I have handful of PowerPC microcontrollers too. Yes, that MPC555!)
BTW, I am glad I still can program Propeller from Ubuntu on Macintosh PowerBook. I needed that. -______- (I'm using Windows XP on different computer. However, I may use that Mac sometimes. Can you tell me any problems I need to know, with the PowerPC Ubuntu before "I pick up and swing my pickax"? Thanks. That will save me some troubles.)
Get this, for that chip you could write your normal integer assembler instructions in a column down the left hand side. Then you could write instructions for floating point ops in a column down the right hand side. These instructions would execute in parallel.
The i860 was big on pipelining but the pieplines were exposed to the programmer and you had to take care of them yourself. So for example when you write something like:
add result, op1, op2
The result you get there would actually be the result of an instruction 4 or 6 steps earlier. The result of that add would come out in whatever instruction was 4 or 6 steps later !!!
All this was so hard to code by hand that even Intel did not know how to extract maximum speed when using hand crafted assembler. Others worked it out later.
Compiler writers had a very hard time getting performance out of the i860 so the general performance was mediocre.
Oh, yea... I forgot about the VLIW processor, i960...
Even though it's tough to program, I am surprised that they got uCLinux to work on it just fine. PowerPC also handles VLIW floating point in one way or another (via AltiVec - similar to SSE2 - SSE4 structures itself), so you're pretty much on your own when it comes to writing couple floating point that involves 3D. if you love x86 but is stuck with PowerPC? Try Bochs, or VirtualBox (wondering if VirtualBox comes in powerPC favor - allowing me to run Windows 7 on my PowerBook G4 laptop... On Ubuntu.)
Itanium got so much bad kind of attention already, but it's fine for something like DSP floating point. (which SSE5 will outshine itanium in term of VLIW length in FPU - Phenom III Orochi can handle 256-bit floating point, compared to itanium's 128-bit FPU...)
Humanoido: The board is real, the price is real and the company also . Those chips deliver 1600 MIPS at 30 $ each. Of course a x86 will be cheaper but it is something else.
Ale, yes, yes, I know..and indeed a good point. Of course the price reflects an increased speed, memory and some other useful configs. My point is, from a hobby perspective, the prop would cost less. And as I remember, Chip Gracey pointed out you can program more flexibly from the architecture viewpoint all the way through to the pins with a quantity of props.
Itanium got so much bad kind of attention already, but it's fine for something like DSP floating point. (which SSE5 will outshine itanium in term of VLIW length in FPU - Phenom III Orochi can handle 256-bit floating point, compared to itanium's 128-bit FPU...)
Dr. Mario, are your apps for a super computing integer machine or FP? Even if it is FP, it would be interesting to see what programs result.
Of course there are many other factors to take into account other than the price of these parts. Which is why I'm a devout Prop user and supporter.
But for building an array of processors economically and having an easier time programming experiments in parallel algorithms/fault tolerant systems on the finished machine I would go the unmentionable route.
I programmed the i860 a little in the early 90's. I had the source code for Intel Graphics Language and I noticed even their programmers hadn't tried to use the pipelined multiply/accumulate instruction. I remember using an artist's pad and creating all these diagrams to figure what was in the pipeline at what stage and finally giving up. Just using pipelined multiplies wasn't so bad. I think the six pipeline stages were only for the multiply/accumulate instruction. The floating point unit also had z-buffer instructions that allowed you to process several pixels at a time. They were more specialized than, for instance, MMX instructions, but were a bit faster. As you mentioned, if you interleaved integer unit and FPU instructions and set a status bit, it would execute them in parallel. I thought it was cleverly designed, for the transistor budget at that time they got the most out of it, but it came out at a time when everybody and his brother was marketing a RISC and it really had an expiration date because all the gimmicks they used would be pointless in a couple generations.
While on the subject of little supercomputers, can we give an honorary mention to the Tile chip? I have no idea what they go for, but I think they're up to 100 cores on a chip.
I am aiming for Integer computing for now - if I want to do floating point on Propeller II chip, I should develop PropSIMD first, it's so that way they don't choke doing gnarly stuff.
Oh, there are something everyone have been overlooking one thing - some people said PowerPC can't and never will do x86. Here is one memento from 1995: powerPC 615.
It did run Pentium instructions fine - it simply switch from PPC to x86 in 5 cycles. I wouldn't be surprised if there are still 615 varieties out there - I suspected AMD Athlon 64 X2 (starting with AM2 variety) contains the PowerPC 615 variety, only on steroids (it's 64-bit....) - MSR binary could only provide me tiniest clues, regarding the IBM PPC programmer's manual. If it really contain PPC64 engines, I would say "Not bad", since it runs games superb. PPC core would be one reason I like AMD CPUs. (If I wanna switch to PPC64 mode, I should try and find easter eggs in it to enable it.)
Okay, Propeller IS really cheap only in limited quanities - like 2 or so. BUT - "Lotta" always means "expensive", period. Reconsider the last time you did your DIY projects - did you really sit down and think how much those components cost, and when combined, do you really think of that at all? Therefore, our hobbies are expensive... =P
Is the unmentionable chip a lot easier than the Propeller to program? And does it come with free software and as much simplified tutorial information, i.e. PEK, like the Propeller? Does it have as many languages written for it? Does it have as many hobby suitable projects as the Prop has? With as many good natured respectable supporters on their forum as there is on the Propeller forum?
Okay, Propeller IS really cheap only in limited quanities - like 2 or so. BUT - "Lotta" always means "expensive", period. Reconsider the last time you did your DIY projects - did you really sit down and think how much those components cost, and when combined, do you really think of that at all? Therefore, our hobbies are expensive...=P
Dr. Mario, it does add up, especially for a hobby supercomputer and that's why I'm an advocate of starting small and gradually expanding. I started with a single prop and then started adding on more in progressions that grew to 2, 4, 5, 6, 8, 10, 12, 15, 20, 25, and the current one with 40. You can view this thread for multiple prop projects and see how others have also expanded on their projects.
I see a lot of hobby supercomputers using that "other" chip, built from a small handful or less of chips on a board with many more unpopulated sockets, claiming the power and speed of the machine as if it were fully populated. Should we all do this? We could built really big machines like this. :roll:
...there are many other factors to take into account other than the price of these parts. Which is why I'm a devout Prop user and supporter.
We should not go here but:
Is the unmentionable chip a lot easier than the Propeller to program?
Probably depends what you want to do and what your previous experience is.
And does it come with free software...
Yes.
...and as much simplified tutorial information, i.e. PEK
Probably not. I have never seen the PEK.
Does it have as many languages written for it?
Absolutely not. There are those working on that sort of thing though. Like the Prop it's the users who make the whole out of the chip.
Does it have as many hobby suitable projects as the Prop has?
No. I don' believe it is hobbyist friendly at the level of the Prop. Again that's a lot down to the user community, like the Prop and Arduino environments. Perhaps it will come, perhaps not.
With as many good natured respectable supporters on their forum as there is on the Propeller forum?
Absolutely yes. In fact many of them are Propeller forumistas as well. They just have the good sense not to mention it here:)
So, it's horses for courses as usual and I'm here with the Prop. and anxiously awaiting the Prop II.
Yep, the reason I was drawn to Propeller like a moth was its price, and ease of programmablity (C++ and SPINs), and its adaptive to many type of projects...
However for very serious project, I use PowerPC microcontroller instead (since they just carefully execute their own codes without as much as an IU stall) - like MPC555 I am using in my pulsed X-ray laser (even though I am pretty sure Propeller can do the same thing, only two times faster - 80MHz vs MPC555's 40MHz core speed, and being able to generate the PWM in the same way only it won't consume as much ROM space as the PPC machine codes do)...
However, the microcontroller you guys mentioned, why do it get so much supports? Of course, Linux is the main reason. Linux is also designed to be easier to program. Heck, you can really put Linux on MPC555's 512KB flash and have the PPC 601 core inside it execute the Linux. I am not kidding, there's a gist of that on uCLinux page. (I also have uCLinux just in case I need a easy way out. -________________- )
Yea. Although Heater, you said that it would not work on PowerPC microcontroller, right? That's the reason why Linux was made to be tried and true OS for embedded hardware. (BTW, you guys running Windows, will want to try compiling Linux kernel on Code:Block IDE software as I have done, it will really help alleviate the headaches later on.)
Although, I really doubt the microcontroller version of Linux will work on Propeller I.
Propeller II? Um, it's possible. But for now, I really have to say NO, because of unfinished structures in ZOG software.
It's 83% done, although I could be wrong, but it's best to wait until they can re-port that in Propeller II chip's native machine code formats (keeping it in native ASM codes would help speed things up, considerably more than in SPIN codes)...
Why not? The point is, the COG RAM is still tethered to 2KB (Man, I hoped that beau or Chip would have expanded it to 8KB... Talk about disappointments down the road... Oh well, gotta learn to live with it.), rather than what everyone have been waiting for the larger COG RAM, and it's enough to upset the Linux kernel. And, even though HUB can, in theory, be expanded to 4MB during foundry fabrication, it's still too slow to handle the Linux kernel, so I would pretty much forget about running Linux on it...
FreeRTOS? Yikes, even though it worked fine with 2KB RAMs, it's still considered a minefield, because again
(I have had to say it... -____-), ZOG is still not done yet, it still need to be cooked a bit longer...
BTW, I would love to have a nice and close look at the ZOG source codes...
Although Heater, you said that it would not work on PowerPC microcontroller, right?
You have to remind my old brain. What did I say would not work on the PowerPC micro-controller? It's just that I don't remember making any statements about Power PC.
Are you saying you have compiled the Linux kernel on Windows using Code::Blocks under Windows. If so have you documented the process anywhere? Many would be interested. Was a cross compile for a non PC target machine?
Although, I really doubt the micro-controller version of Linux will work on Propeller I.
Real Linux no, due to the lack of memory management hardware on the Prop.
If you mean uCLinux, well why not ? As far as I know it only needs a processor with enough RAM, a console port, a timer interrupt a suitable compiler and a boot loader. Perhaps a block I/O device to actually make it worth while. On jazzed board with 32MByte RAM it starts to look possible.
That of course is "in theory" as I'm sure there is a lot of details to worry about. More than I am prepared to contemplate tackling.
I really have to say NO, because of unfinished structures in ZOG software.
Admittedly I don't consider the Zog interpreter to be finished yet. I would be interested if you would say what structures are un-finished. Then I can think about if they are essential to have on the Prop and whether I should try and get them finished. All input is welcome.
...but it's best to wait until they can re-port that in Propeller II chip's native machine code formats
Who is "they" and re-port what?
Zog is taking advantage of GCC compiling to ZPU byte codes using a GCC target created by ZyLin Inc. I'm sure they have no interest in targeting the Propeller I or II.
On this scale, targeting Prop native asm is never going to happen. As you say 2K code space is too small. Perhaps a target of GCC to LMM would be nice, but who would do such a thing?
FreeRTOS....ZOG is still not done yet, it still need to be cooked a bit longe
FreeRTOS has indeed been run under ZPU processors compiled with zpu-gcc. So if Zog is a good emulation of ZPU the FreeRTOS will run on the Prop as well.
Again I have to ask as which parts of ZOG need more cooking? Source code for Zog is all on the Zog thread. Source code for the zpu-gcc compiler (and FreeRTOS) is all available from Zylin Inc.
Okay, I'm starting to see in this the makings of a real personal supercomputer. You write your supercomputer applications with the ZPU as a target. Or really a network of ZPU's. I'm thinking you could get a feel for this with one of the multi-prop boards. Then you have to recruit some FPGA person into this. I know there are people using FPGA's for extended memory and multiprop communication. You need to shoehorn a ZPU onto an FPGA, probably sharing extended memory with a Prop. With the near gigabit/s com speed and bushel baskets of MAC's on an FPGA you could get some serious work done. Then add FPGA's to mirror the arrangement of the mult-prop boards.
You write your supercomputer applications with the ZPU as a target.
This is not recommended, the ZPU architecture is designed to occupy the minimal amount of space on an FPGA for a 32 bit CPU. It is not designed for speed.
Also no one today targets big application codes to a particular CPU. That would imply writing it in assembler. Then you have to rewrite it all for the next CPU to come around.
I have adopted the ZPU architecture as a project for the Prop because it is so small, the instruction interpreter for it can easily fit in a COG. Then we get to play with GCC on the Prop:) It as no pretentions towards being speedy.
You need to shoehorn a ZPU onto an FPGA,
It does not need a shoehorn. As I say it is designed to fit FPGAs easily with room to spare for whatever other logic your FPGA is supposed to be handling.
I did not mean targeting it in the sense of object code. I meant in the sense that I think the ZPU is intended for, a minamilist 32 bit CPU that acts as an interface to some hardware design implemented on the FPGA. So for Dr. Mario, his integer AI application, for a gamer, perhaps a vector multiplier for doing transforms. But perhaps this is an obsolete methodology, I'm thinking of it in the way I used assembly language 25 years ago, write an application in a high level language, then recode the critical sections in assembler. Only in this case it would be an fpga design in place of assembler. Of course you could do this with any 32 bit open core design, but my understanding is that they would be about 5 times the size of the ZPU. That was the origin of my shoehorning comment also, that another CPU might not fit on a small fpga alongside the Prop extended memory controller and communicatons unit. But I suppose it would make sense for someone who did not want to optimize for a particular application to use another, faster CPU core if it fit.
My own interest in this was prompted by the Prop ][ texture mapping instruction that was discussed a while back. But I suppose this is something that might not even make it into the final design of the Prop ][. I think I've lobbied for this before, sticking a vector coprocessor on an fpga for the Prop ][ to really make it fly, but I don't think anyone is interested yet. If they do include the texture mapping instruction on the Prop ][ and gamers start playing with it, we may revisit this topic.
for you old timers, I put 12 i860s through their paces on an SGI Onyx computer,
Together the GeometryEngine10(with 12 i860 processors) RasterManager4 and DisplayGenerator2 generated 430000 fully environmentally mapped, antialiased, pixels per second flipping a model of a chrome Bell Ranger helicopter at 30frames/sec....not bad for 1993
We had several SGI machines, including a top of the range Iris, in our lab at BAe Brough, around then. We used two smaller Irises to deliver stereo images - one for each eye - with the big one generating the outside world image on a dome.
I learned to fly a fighter on that simulator, and didn't have any problems doing aerobatics when one of our test pilots took me up in a PC9 military trainer, although I'd never flown a plane before. I managed a couple of loops and a barrel roll without any problems!
True. ZPU would choke once the longer run-time codes run, since the ALU logics inside ZPU has very limited tag request table - in other word, it was meant for peak computing, not sustaining computing (like the x86 or PPC, and yes, Propeller is a sustained computer, only with a pipeline like in 80386. In other word, it's like a 386 on steroids.)
And, I thought you meant the ZOG or ZiCOG in C++ nativity in Propeller chips... -____-"
I'm confused, but it's my fault too.
And, if you want ZPU in FPGA to have monster horsepower, consider it to be out-of-order execution engine (by adding extra integer units), since there are something down the road that will kick IU pipelines in you-know-where (like it said on paper, admittedly). Pentium processor's FPU was and is an excellent example (FDIV bugs), although I was talking about integer, not floating point, but still it's a good evidence, anyways.
uCLinux on Propeller is always possible, but then it's not easy. BTW, Code:Block already contain GCC built-in, so you should be able to do that. I would have to say that it's considering cross-compiling, since I would be compiling Linux kernel in Windows FOR this chip.
Pharseid, good point. Some peoples DO really want to put Propeller II on steroids, like I asked for (out-of-order execution - although I am sure they already did put in multi-ALU structures in Propeller II's COGs, to really bulldoze through SPIN rapidly), while majority doesn't really understand the finer detail of what's inside the COGs. Leaving off the horsepower was and is always a trade-off. (Majority have control over that... T____T )
Here's my report - it may reflect the future of Dendou Oni supercomputer I am planning to construct in the future. Anything questions after reading it - go ahead and fire away. I would try to answer it as fast as I can (due to limited internet access, anyways - hopefully it will change soon...)
Yea. I am pleasantly surprised, as it's my first report of construction of Dendou Oni. I am delving into detail of software right now, for few methods into the scripts to be written for this supercomputer, as the moment I am writing, the Propeller II's on-die circuitry is being finalized.
The first Propeller II chip sample I am proposing on buying would probably be in the Spring of 2011, or Falls of 2011, depending on whatever/whichever comes first, to test the software and the GO-JET scripts (as well as the need of constantly fiddling) before I could order more to be soldered onto the first few hypercube boards - then installed into the frame, to see if I would be missing something.
And, as for the electric checks on finalized PCB masks, and the firmware being fine-tuned, I would probably not declare the official first boot-up until two years from now, to be on the safe side.
However, about the Dendou Oni hardwares, I pretty much decided to use run-of-the-mill computer parts such as an ATX power supply, and hard drives - that way it's pretty easy to replace, should that particular part decide to die a slow death (or fast one - whichever comes first) - hard drive death (*click, thud - screech*) would be a definite bad luck, though. O____O
I gave a quick skim of your document, and it is clear that you want to accomplish something impressive.
I want to encourage you to build the supercomputer of your dreams, but before you do, you need to learn more about what you are trying to accomplish.
Respecfully, I suggest you research pipelining, VLIW, floating point etc. a lot more in order to avoid a lot of future confusion and wasted implementation time based on your current flawed understanding of how the Propeller works, and how the Propeller 2 will work.
I do not wish to sound negative, and I do wish you success.
Here's my report - it may reflect the future of Dendou Oni supercomputer I am planning to construct in the future. Anything questions after reading it - go ahead and fire away. I would try to answer it as fast as I can (due to limited internet access, anyways - hopefully it will change soon...)
Comments
The board is real, the price is real and the company also
BTW, I am glad I still can program Propeller from Ubuntu on Macintosh PowerBook. I needed that. -______- (I'm using Windows XP on different computer. However, I may use that Mac sometimes. Can you tell me any problems I need to know, with the PowerPC Ubuntu before "I pick up and swing my pickax"? Thanks. That will save me some troubles.)
The assembler of the PPC seems complicated enough but it may not be that bad... nothing can be worst than x86 !
Oh yes it can, the Intel i860 for example. http://en.wikipedia.org/wiki/Intel_i860
Get this, for that chip you could write your normal integer assembler instructions in a column down the left hand side. Then you could write instructions for floating point ops in a column down the right hand side. These instructions would execute in parallel.
The i860 was big on pipelining but the pieplines were exposed to the programmer and you had to take care of them yourself. So for example when you write something like:
The result you get there would actually be the result of an instruction 4 or 6 steps earlier. The result of that add would come out in whatever instruction was 4 or 6 steps later !!!
All this was so hard to code by hand that even Intel did not know how to extract maximum speed when using hand crafted assembler. Others worked it out later.
Compiler writers had a very hard time getting performance out of the i860 so the general performance was mediocre.
Even though it's tough to program, I am surprised that they got uCLinux to work on it just fine. PowerPC also handles VLIW floating point in one way or another (via AltiVec - similar to SSE2 - SSE4 structures itself), so you're pretty much on your own when it comes to writing couple floating point that involves 3D. if you love x86 but is stuck with PowerPC? Try Bochs, or VirtualBox (wondering if VirtualBox comes in powerPC favor - allowing me to run Windows 7 on my PowerBook G4 laptop... On Ubuntu.)
Itanium got so much bad kind of attention already, but it's fine for something like DSP floating point. (which SSE5 will outshine itanium in term of VLIW length in FPU - Phenom III Orochi can handle 256-bit floating point, compared to itanium's 128-bit FPU...)
"My point is, from a hobby perspective, the prop would cost less."
Not so, from where I'm sitting:
Naked chips:
Propeller: 8 * 20 MIPS for 12.00 Euro
Unmentionable chip: 8 * 50 MIPS for 6.35 Euro.
Chips on a boards:
Unmentionable XK1 dev board + programmer: 84.00 Euro.
Propeller Demo Board: 85.70 Euro.
Of course there are many other factors to take into account other than the price of these parts. Which is why I'm a devout Prop user and supporter.
But for building an array of processors economically and having an easier time programming experiments in parallel algorithms/fault tolerant systems on the finished machine I would go the unmentionable route.
I programmed the i860 a little in the early 90's. I had the source code for Intel Graphics Language and I noticed even their programmers hadn't tried to use the pipelined multiply/accumulate instruction. I remember using an artist's pad and creating all these diagrams to figure what was in the pipeline at what stage and finally giving up. Just using pipelined multiplies wasn't so bad. I think the six pipeline stages were only for the multiply/accumulate instruction. The floating point unit also had z-buffer instructions that allowed you to process several pixels at a time. They were more specialized than, for instance, MMX instructions, but were a bit faster. As you mentioned, if you interleaved integer unit and FPU instructions and set a status bit, it would execute them in parallel. I thought it was cleverly designed, for the transistor budget at that time they got the most out of it, but it came out at a time when everybody and his brother was marketing a RISC and it really had an expiration date because all the gimmicks they used would be pointless in a couple generations.
While on the subject of little supercomputers, can we give an honorary mention to the Tile chip? I have no idea what they go for, but I think they're up to 100 cores on a chip.
-phar
I am aiming for Integer computing for now - if I want to do floating point on Propeller II chip, I should develop PropSIMD first, it's so that way they don't choke doing gnarly stuff.
Oh, there are something everyone have been overlooking one thing - some people said PowerPC can't and never will do x86. Here is one memento from 1995: powerPC 615.
It did run Pentium instructions fine - it simply switch from PPC to x86 in 5 cycles. I wouldn't be surprised if there are still 615 varieties out there - I suspected AMD Athlon 64 X2 (starting with AM2 variety) contains the PowerPC 615 variety, only on steroids (it's 64-bit....) - MSR binary could only provide me tiniest clues, regarding the IBM PPC programmer's manual. If it really contain PPC64 engines, I would say "Not bad", since it runs games superb. PPC core would be one reason I like AMD CPUs. (If I wanna switch to PPC64 mode, I should try and find easter eggs in it to enable it.)
Okay, Propeller IS really cheap only in limited quanities - like 2 or so. BUT - "Lotta" always means "expensive", period. Reconsider the last time you did your DIY projects - did you really sit down and think how much those components cost, and when combined, do you really think of that at all? Therefore, our hobbies are expensive... =P
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=472019
I see a lot of hobby supercomputers using that "other" chip, built from a small handful or less of chips on a board with many more unpopulated sockets, claiming the power and speed of the machine as if it were fully populated. Should we all do this? We could built really big machines like this. :roll:
Don't forget I did say:
We should not go here but:
Probably depends what you want to do and what your previous experience is.
Yes.
Probably not. I have never seen the PEK.
Absolutely not. There are those working on that sort of thing though. Like the Prop it's the users who make the whole out of the chip.
No. I don' believe it is hobbyist friendly at the level of the Prop. Again that's a lot down to the user community, like the Prop and Arduino environments. Perhaps it will come, perhaps not.
Absolutely yes. In fact many of them are Propeller forumistas as well. They just have the good sense not to mention it here:)
So, it's horses for courses as usual and I'm here with the Prop. and anxiously awaiting the Prop II.
However for very serious project, I use PowerPC microcontroller instead (since they just carefully execute their own codes without as much as an IU stall) - like MPC555 I am using in my pulsed X-ray laser (even though I am pretty sure Propeller can do the same thing, only two times faster - 80MHz vs MPC555's 40MHz core speed, and being able to generate the PWM in the same way only it won't consume as much ROM space as the PPC machine codes do)...
However, the microcontroller you guys mentioned, why do it get so much supports? Of course, Linux is the main reason. Linux is also designed to be easier to program. Heck, you can really put Linux on MPC555's 512KB flash and have the PPC 601 core inside it execute the Linux. I am not kidding, there's a gist of that on uCLinux page. (I also have uCLinux just in case I need a easy way out. -________________- )
Currently C++ is only an option on the Propeller if you are prepared to roll your sleeves up and help with ZOG.
Linux does not run on said micro-controller. You can develop software for said micro-controller under Windows or whatever.
Edit: Removed redundant and overly aggressive phrases.
Although, I really doubt the microcontroller version of Linux will work on Propeller I.
Propeller II? Um, it's possible. But for now, I really have to say NO, because of unfinished structures in ZOG software.
It's 83% done, although I could be wrong, but it's best to wait until they can re-port that in Propeller II chip's native machine code formats (keeping it in native ASM codes would help speed things up, considerably more than in SPIN codes)...
Why not? The point is, the COG RAM is still tethered to 2KB (Man, I hoped that beau or Chip would have expanded it to 8KB... Talk about disappointments down the road... Oh well, gotta learn to live with it.), rather than what everyone have been waiting for the larger COG RAM, and it's enough to upset the Linux kernel. And, even though HUB can, in theory, be expanded to 4MB during foundry fabrication, it's still too slow to handle the Linux kernel, so I would pretty much forget about running Linux on it...
FreeRTOS? Yikes, even though it worked fine with 2KB RAMs, it's still considered a minefield, because again
(I have had to say it... -____-), ZOG is still not done yet, it still need to be cooked a bit longer...
BTW, I would love to have a nice and close look at the ZOG source codes...
We've already said uClinux is not possible on the Propeller and that's just enough motivation to fill someone's long, cold, northern European nights
You have to remind my old brain. What did I say would not work on the PowerPC micro-controller? It's just that I don't remember making any statements about Power PC.
Are you saying you have compiled the Linux kernel on Windows using Code::Blocks under Windows. If so have you documented the process anywhere? Many would be interested. Was a cross compile for a non PC target machine?
Real Linux no, due to the lack of memory management hardware on the Prop.
If you mean uCLinux, well why not ? As far as I know it only needs a processor with enough RAM, a console port, a timer interrupt a suitable compiler and a boot loader. Perhaps a block I/O device to actually make it worth while. On jazzed board with 32MByte RAM it starts to look possible.
That of course is "in theory" as I'm sure there is a lot of details to worry about. More than I am prepared to contemplate tackling.
Admittedly I don't consider the Zog interpreter to be finished yet. I would be interested if you would say what structures are un-finished. Then I can think about if they are essential to have on the Prop and whether I should try and get them finished. All input is welcome.
Who is "they" and re-port what?
Zog is taking advantage of GCC compiling to ZPU byte codes using a GCC target created by ZyLin Inc. I'm sure they have no interest in targeting the Propeller I or II.
On this scale, targeting Prop native asm is never going to happen. As you say 2K code space is too small. Perhaps a target of GCC to LMM would be nice, but who would do such a thing?
FreeRTOS has indeed been run under ZPU processors compiled with zpu-gcc. So if Zog is a good emulation of ZPU the FreeRTOS will run on the Prop as well.
Again I have to ask as which parts of ZOG need more cooking? Source code for Zog is all on the Zog thread. Source code for the zpu-gcc compiler (and FreeRTOS) is all available from Zylin Inc.
-phar
This is not recommended, the ZPU architecture is designed to occupy the minimal amount of space on an FPGA for a 32 bit CPU. It is not designed for speed.
Also no one today targets big application codes to a particular CPU. That would imply writing it in assembler. Then you have to rewrite it all for the next CPU to come around.
I have adopted the ZPU architecture as a project for the Prop because it is so small, the instruction interpreter for it can easily fit in a COG. Then we get to play with GCC on the Prop:) It as no pretentions towards being speedy.
It does not need a shoehorn. As I say it is designed to fit FPGAs easily with room to spare for whatever other logic your FPGA is supposed to be handling.
Do check the Zylin Inc web pages to see what the ZPU is all about.
http://opensource.zylin.com/zpu.htm
I did not mean targeting it in the sense of object code. I meant in the sense that I think the ZPU is intended for, a minamilist 32 bit CPU that acts as an interface to some hardware design implemented on the FPGA. So for Dr. Mario, his integer AI application, for a gamer, perhaps a vector multiplier for doing transforms. But perhaps this is an obsolete methodology, I'm thinking of it in the way I used assembly language 25 years ago, write an application in a high level language, then recode the critical sections in assembler. Only in this case it would be an fpga design in place of assembler. Of course you could do this with any 32 bit open core design, but my understanding is that they would be about 5 times the size of the ZPU. That was the origin of my shoehorning comment also, that another CPU might not fit on a small fpga alongside the Prop extended memory controller and communicatons unit. But I suppose it would make sense for someone who did not want to optimize for a particular application to use another, faster CPU core if it fit.
My own interest in this was prompted by the Prop ][ texture mapping instruction that was discussed a while back. But I suppose this is something that might not even make it into the final design of the Prop ][. I think I've lobbied for this before, sticking a vector coprocessor on an fpga for the Prop ][ to really make it fly, but I don't think anyone is interested yet. If they do include the texture mapping instruction on the Prop ][ and gamers start playing with it, we may revisit this topic.
-phar
Together the GeometryEngine10(with 12 i860 processors) RasterManager4 and DisplayGenerator2 generated 430000 fully environmentally mapped, antialiased, pixels per second flipping a model of a chrome Bell Ranger helicopter at 30frames/sec....not bad for 1993
Take care,
Doug
I learned to fly a fighter on that simulator, and didn't have any problems doing aerobatics when one of our test pilots took me up in a PC9 military trainer, although I'd never flown a plane before. I managed a couple of loops and a barrel roll without any problems!
And, I thought you meant the ZOG or ZiCOG in C++ nativity in Propeller chips... -____-"
I'm confused, but it's my fault too.
And, if you want ZPU in FPGA to have monster horsepower, consider it to be out-of-order execution engine (by adding extra integer units), since there are something down the road that will kick IU pipelines in you-know-where (like it said on paper, admittedly). Pentium processor's FPU was and is an excellent example (FDIV bugs), although I was talking about integer, not floating point, but still it's a good evidence, anyways.
uCLinux on Propeller is always possible, but then it's not easy. BTW, Code:Block already contain GCC built-in, so you should be able to do that. I would have to say that it's considering cross-compiling, since I would be compiling Linux kernel in Windows FOR this chip.
Pharseid, good point. Some peoples DO really want to put Propeller II on steroids, like I asked for (out-of-order execution - although I am sure they already did put in multi-ALU structures in Propeller II's COGs, to really bulldoze through SPIN rapidly), while majority doesn't really understand the finer detail of what's inside the COGs. Leaving off the horsepower was and is always a trade-off. (Majority have control over that... T____T )
The first Propeller II chip sample I am proposing on buying would probably be in the Spring of 2011, or Falls of 2011, depending on whatever/whichever comes first, to test the software and the GO-JET scripts (as well as the need of constantly fiddling) before I could order more to be soldered onto the first few hypercube boards - then installed into the frame, to see if I would be missing something.
And, as for the electric checks on finalized PCB masks, and the firmware being fine-tuned, I would probably not declare the official first boot-up until two years from now, to be on the safe side.
However, about the Dendou Oni hardwares, I pretty much decided to use run-of-the-mill computer parts such as an ATX power supply, and hard drives - that way it's pretty easy to replace, should that particular part decide to die a slow death (or fast one - whichever comes first) - hard drive death (*click, thud - screech*) would be a definite bad luck, though. O____O
I gave a quick skim of your document, and it is clear that you want to accomplish something impressive.
I want to encourage you to build the supercomputer of your dreams, but before you do, you need to learn more about what you are trying to accomplish.
Respecfully, I suggest you research pipelining, VLIW, floating point etc. a lot more in order to avoid a lot of future confusion and wasted implementation time based on your current flawed understanding of how the Propeller works, and how the Propeller 2 will work.
I do not wish to sound negative, and I do wish you success.
Regards,
Bill