Yeah, I was looking at it too. Didn't realize the memory was not shared among the cores. Probably has to keep timing precise for max streaming between them to make best use of the display buffer too.
Ah adding nops - that's the tricks you do on PICs and AVRs to get timings almost.
I have to go with the camp and say that the propeller definitely beats anything else in determinacy. Also, multi-threaded, whether pre-emptive or cooperative, is not the same as multi or parallel processing. You are still only executing one context, there are clever mechanisms to save state for each context and to make fetching instructions quicker, but you are still only fetching and executing instructions through one pipeline.
The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?
XMOS uses true MIMD parallel processing - the four cores are completely independent. Two or more threads might be running on the same core but they behave like separate processors.
I think you are confusing the hardware threads used by XMOS with conventional software threading systems.
[noparse][[/noparse]quote]The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?
I don't understand what you mean.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Seems to me those "video generators" that are not "professional" would have come in damn handy for that task. Kind of nice to just set the PLL, then build pixels off of that, but that's just me! LOL!! Change the clock, and probably that won't run. Change clock on the Prop, and it likely will, given the overall compute speed is still capable of the pixel feed rate.
I switch boards all the time, and just run the same video code I'm focused on, only having to just state what clock I'm actually running. It's really easy.
And he basically used the entire core too. Gotta put the display buffer somewhere, meaning that core is mostly not available to then run threads. (no real program space remaining) Graphical data, existing elsewhere, or on external RAM must then be streamed in to the display buffer, as the other cores cannot write it directly. This has fill rate limits too. If the one core is managing the display and moving data, then the other cores, cannot be used in combination to actually draw the display. One pipe = one fill rate. More pipes then = more threads = non deterministic behavior = more complexity.
My point there is despite having a "proper compiler", it's down and dirty in assembly language for the good tricks anyway, isn't it Leon?
I'll stick with the Prop. Thanks for the XMOS discussion though! Always nice to learn some new stuff about new hardware.
Leon, also, iirc it's not single cycle it's 4 per instruction, which is why it runs at 100mips per 4 threads, as 100mips is the maximum it can run a single thread at, which is why it runs up to 4 at 100mips, then the 5th thread disrupts the whole thing and makes it go to 80mips cos it needs 5*4 clocks [noparse]:D[/noparse]
and thus all threads don't run in parallel, as there's a clock latency on all threads.
Prop is also much nicer to code, and doesn't get RED HOT as soon as you turn the thing on, or at all, I've had PropGFX running full tilt with all cogs blazing and it still doesn't get mildly warm after a couple of days, whereas the XMOS will burn your fingers after a few seconds [noparse]:([/noparse]
Prop also has better intercog coms, as each cog has access to ALL available memory, not 4 seperate 64K chunks, ( PropII will have access to ALL 256K with any cog and run at 160mips per cog making it faster, better, stronger, able to leap buildings in a single bound, oh sorry, wrong script lol and that's before you add the 3D textured gouraud shading ability :P )
you can tell which microcontroller I have on my desk, and which is gathering dust in a deep cupboard corner, well, actually I have 7 prop setups on my desk [noparse]:D[/noparse]
To both, let me explain my choices with the VGA drivers:
There are two drivers:
1/4 bpp drivers. These were written in assembler because:
- I wanted exact timing, at 12.5 MHz pixel clock eight instructions are needed. With C (XC) I was not sure if I could squeeze the needed timing because I was using the ports asynchronously. Asynchronicity of the ports is the reason here. (And I wanted to give assembler a go!).
8 bpp driver. This was written in XC because I used synchronous port access (buffered and synchronized to a clock). This way I could afford the uncertainty that C (XC) gives because port access will be delayed till the right time comes. This is an evolution of the other method. I couldn't have done it before because I had not found the Ports document.
This driver still uses an assembler helper (vgabuf_sender) that reads the pixel data from memory. It was done in assembler just to fit it in the tight spot left by a 64000 byte frame buffer.
Now: The 1 bpp driver is going to be merged with a new 1bpp driver based on the 8bpp driver model and the resolution will be cranked up to 640x480. I think I can get 800x600 1bpp (64000 bytes).
The 4bpp driver is going to use a similar technique.
I also developed a text driver. I only got so far as to display chars with foreground colors. Background colors other than black are missing, using similar techniques as the 8bpp and 1bpp (new driver).
I hope it clarifies things.
As ports have many more modes of operation than the propeller, determinism is less of a concern. Threads either 4 or 8 have a total maximum of 100 or 50 MIPS respectively. They cannot get beyond that. No matter what. Waits are measured to the 400 MHz clock so a wait for 1 cycle can happen. That means a thread that was starting at a clock mod 4 = 0 may start at clock %4 = 1 after the delay. That may or may not affect things.
Thanks for the extra info. [noparse]:)[/noparse] No worries here. Looks like you are having a good time of it! I didn't mean to imply anything bad about your project!
Is it that binary? 3 threads = 100 MIPS @ standard clock, 5 threads = 50 MIPS? ...or a smooth degrade as Baggars was saying?
IMHO both chips have their place, but the Propeller appears to me to be MUCH simpler for the hobbyist in many ways (DIP; objects 'slot in'; price; etc.). And just because it's simpler for the hobbyist should be no reason for it not to be suitable for the professional.
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
For 1 to 4 thread all of them get 100 MIPS each. For 5 to 8 all of them get 50 MIPS each. That is due to pipeline and some clever shared use of resources.
I know you did not mean any detriment for the code , the 1bpp and 4bpp where not-so-quick-but-quite-dirty approach . The second one is a proper one using the resources at hand. As I said, that ports document was not available till the end of November of beginning of Dec.
Leon: I'm the same and only Ale here (and there I'm called Ale500). Well, there are some Alex and Alexanders here, too. My real name is Alejandro, the spanish version.
One of the things I find really good is how they crammed in 16 bits opcodes with 3 arguments. As only 12 registers are available for these instructions a 11 bit field is used for all combinations. Some instructions are also in the not used combinations, very clever. I really miss some instructions, like compare and and with immediate, but you cannot have everything. Channel communication, thread creation and join are all in the assembler. That makes it quite fast to boot several threads.
For the time being the XMOS dev boards (XC-1) are slaves of a PC or a Mac. I hope some not-so-enslaved-boards are going to show up soon (Leon, are you there ?) and we can use those XS1s fore more things than testing code and limits.
I looked at the XMOS assembler instruction set and found it a mess, not regular like the prop. I gave it a miss before I got to the point that it was threads. Glad I didn't bother any further.
Cluso99: You need to experience more x86 assembler! Then anything else is a joy! After a little while you see the orthogonality of it. It is not like MIPS but it is also shorter.
One of the things I find really good is how they crammed in 16 bits opcodes with 3 arguments. As only 12 registers are available for these instructions a 11 bit field is used for all combinations. Some instructions are also in the not used combinations, very clever. I really miss some instructions, like compare and and with immediate, but you cannot have everything. Channel communication, thread creation and join are all in the assembler. That makes it quite fast to boot several threads.
For the time being the XMOS dev boards (XC-1) are slaves of a PC or a Mac. I hope some not-so-enslaved-boards are going to show up soon (Leon, are you there ?) and we can use those XS1s fore more things than testing code and limits.
David May did a good job. He's an FRS, BTW, that's the highest scientific qualification in the UK.
I'm waiting for the 144BGA chips, although I could go ahead with one of my 512BGA designs.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Ale said...
Cluso99: You need to experience more x86 assembler! Then anything else is a joy! After a little while you see the orthogonality of it. It is not like MIPS but it is also shorter.
I have, and no thanks.
In addition to minicomputers, I've coded 6800, 6805, 6502, 6511, 68020, 88100, Z80, Z8681, 8080, 80486 (a complete ICL minicomputer emulation specifically targeting the faster 486 instructions and commercially verified), and now the Prop. Just because the XMOS is better than the x86 doesn't make it easy, and the x86 is arguably the worst instruction set out.
I think·determinism is highly overrated. Do I have your attention now ??
For most micros, determinism is impossible unless you disable interrupts.·Previously, it has not been really necessary, as long as you·know that your routines and interrupt routines can co-exist.
The Prop has changed this. Why, you ask. Well because the Prop doesn't have·embedded peripherals like other modern day micros. It has 8 cogs that can control very flexible counters (or whatever you want to call these building blocks). There is only one Prop, not hundreds of variants·like other micros such as the PIC. So, in order to build·internal peripherals, cog(s) are used. For some of these, deterministic code is often required. With interrupts this simply could not be the case. And neither could it be if the cogs were merely threads. For example, if one thread's code was dependant on an external event, and this·thread affected another·threads performance depending on what it was doing, determinism goes out the window - period! Your VGA may suffer jitter. It does not matter how complex a simulator is, it cannot cater for variable external events to simulate timing.
So the Prop has independant cogs that can function as peripherals to the other cogs via shared memory (hub memory). We all build these peripherals. Some of these are in the Object Exchange. Peripherals such as FullDuplexSerial, VGA, SPI, I2C, SDcard, etc. Now we have one chip that is so flexible that it can replace many variants that other chips·require. More of these variants are being discovered daily, by enthusiasts such as yourselves.
Once again, I thank Chip for the courage to create a micro which does not conform to the norm. It is truly a directional change that has yet to be understood by many - for it's simplicity and flexibility. The PropII will be another leap forward.
I did a lot of hand-assembly in the early days with the 6800 and 8086 (I couldn't afford an assembler), and didn't have any problems with the 8086. I wrote and hand-assembled a comprehensive monitor/debugger for it - once I got the basic debugger working I used that to debug the rest of the code. I remember hand-assembling transputer code when I built my first system, it was similar to XMOS assembler in many ways. I usually do some hand-assembly when learning a new chip, and check it against the assembler, it's a good way to learn how it works.
All XMOS peripherals are implemented in software, also, and run on their own thread. There aren't any interrupts, either.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
That 30 million dollars that have been invested in XMOS worries me. Those investors will want a return on their investment and that's a lot of chips to shift. I worry that this will all go the same way as the Transputer. Don't get me wrong I love the XMOS ideas, software as silicon, parallel processing, communication links etc.
Conversely I have confidence that Parallax will still have Props to sell me a long time from now.
As for engineers defending their position with the use of arcane esoteric knowledge, that can work for a while or even a long while. But I have seen it also become career suicide as what ever technology it is you are the "keeper" of suddenly gets blown away very quickly the day that some one high up realises what it's costing them.
Better to keep moving on and share what you know. That way people will always come to you because you "know" and you are always one step ahead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The transputer wasn't exactly a failure, the core was used in set top boxes for many years. It didn't survive as a parallel processing chip mainly because the second generation device was just on the limit of what could be achieved at the time. XMOS already has several design wins, although the chip has only been available for a few months. They targeted likely customers by giving away XDKs that sell for $999 each, it seems to have worked. Here are some nice YouTube clips of the XDK in action:
One thing that I find really intriguing about the XMOS chip is its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!) - then the sky's the limit [noparse]:yay:[/noparse] (Just imagine; 1 x Prop for hi-res colour VGA, fed from another that deals with all the I/O, etc - you get the picture).
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
simonl said...
One thing that I find really intriguing about the XMOS chip is its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!) - then the sky's the limit [noparse]:yay:[/noparse] (Just imagine; 1 x Prop for hi-res colour VGA, fed from another that deals with all the I/O, etc - you get the picture).
The five-wire Xlink gives a 3.2 Gb/s transfer rate (full duplex). It uses 5 wires so that 32 bits can be transferred in one clock. The two-wire Xlinks are a lot slower, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
simonl said...
...its inter-core/-chip communications capability. If PropII gives us something similar - as I think was mentioned in another thread (Are you reading this, Chip?!)
Yep, I bring this up every time there is a Prop II discussion. There must be a fairly simple way to do this by allowing the video shifters to shift in as well as out plus some synch logic. Just following the Prop philosophy of having relatively simple but adaptable general purpose logic.
Never do get any feed back on this from Parallax but there are already a bunch of multi Prop projects out there that would benefit from high speed links.
Next up is a means to access a pile of external RAM at speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Okay, for video the propeller really just needs a speed boost. Mainly because you simply can't do all the things you need to do at 20 MIPS.
For example:
With more speed it will be possible to have higher resolutions running on one cog. Right now 640x480 is the absolute limit for one cogs display capabilities.
With more speed it will be possible to use higher resolution character sets and graphics on one cog with a large display. As if the procesor is running a display at 640x480 its minimum amount of pixles per waitvid is 16 which allows the cog just enough time to fetch more.
With more speed it will be possible to do more complex overlays. For example I'm working on a mouse cusor for my vga driver that actually draws on the display by forcing the color lines to certaint states while a waitvid is shifting pixles out in the back ground. My goal is to have the same cog generating video do this.
And with more speed it will possilbe to work with more colors.
External ram and a large video buffer aren't really needed if you adopt the use of tiled bit mapped graphics and simply make the display buffer a buffer full of pointers.
Leon said...
All XMOS peripherals are implemented in software, also, and run on their own thread. There aren't any interrupts, either.
'Odd, then, that there are so many instructions that deal with interrupts. Also, from the manual, XMOS XS1 Instruction Set Architecture (8.7.1) (p. 207):
"4 Exceptions
Exceptions change the normal flow of control on an XS1-G4; they may be caused by interrupts, errors arising during instruction execution and by system calls. On an exception, the processor will save the pc and sr in spc and ssr , disable events and interrupts, and start executing an exception handler. The program counter that is saved normally points to the instruction that raised the exception. Two registers are also set. The exception-data (ed) and exceptiontype (et ) will be set to reflect the cause of the exception. The exception handler can choose how to deal with the exception."
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/12/2009 6:06:00 PM GMT
What I don't understand is why folks are comparing the Prop to the Xmos chip. To me they look to be targeted at different markets. XMOS seems to have target high end embedded stuff and compute farms, etc. The Prop OTOH looks to be marketed as a low cost, multicore embedded micro.
Apples and oranges IMO.
OTOH I do see the ARM variants as the chips to beat if the Prop wants to be a player in either the consumer electronics market or some other field say like medical electronics.
Comments
Yeah, I was looking at it too. Didn't realize the memory was not shared among the cores. Probably has to keep timing precise for max streaming between them to make best use of the display buffer too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
It's a classic MIMD architecture, like the Inmos transputer that David May also designed. He doesn't like shared memory.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 9:03:07 AM GMT
I have to go with the camp and say that the propeller definitely beats anything else in determinacy. Also, multi-threaded, whether pre-emptive or cooperative, is not the same as multi or parallel processing. You are still only executing one context, there are clever mechanisms to save state for each context and to make fetching instructions quicker, but you are still only fetching and executing instructions through one pipeline.
The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?
I think you are confusing the hardware threads used by XMOS with conventional software threading systems.
[noparse][[/noparse]quote]The propeller is true parallel processing, however, as each cog can execute instructions independently. Also, correct me if I'm wrong, but I believe each cog can run at a different speed with full determinacy - tell me how you will do that with nops?
I don't understand what you mean.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 9:16:42 AM GMT
Seems to me those "video generators" that are not "professional" would have come in damn handy for that task. Kind of nice to just set the PLL, then build pixels off of that, but that's just me! LOL!! Change the clock, and probably that won't run. Change clock on the Prop, and it likely will, given the overall compute speed is still capable of the pixel feed rate.
I switch boards all the time, and just run the same video code I'm focused on, only having to just state what clock I'm actually running. It's really easy.
And he basically used the entire core too. Gotta put the display buffer somewhere, meaning that core is mostly not available to then run threads. (no real program space remaining) Graphical data, existing elsewhere, or on external RAM must then be streamed in to the display buffer, as the other cores cannot write it directly. This has fill rate limits too. If the one core is managing the display and moving data, then the other cores, cannot be used in combination to actually draw the display. One pipe = one fill rate. More pipes then = more threads = non deterministic behavior = more complexity.
My point there is despite having a "proper compiler", it's down and dirty in assembly language for the good tricks anyway, isn't it Leon?
I'll stick with the Prop. Thanks for the XMOS discussion though! Always nice to learn some new stuff about new hardware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
Post Edited (potatohead) : 1/12/2009 9:28:53 AM GMT
and thus all threads don't run in parallel, as there's a clock latency on all threads.
Prop is also much nicer to code, and doesn't get RED HOT as soon as you turn the thing on, or at all, I've had PropGFX running full tilt with all cogs blazing and it still doesn't get mildly warm after a couple of days, whereas the XMOS will burn your fingers after a few seconds [noparse]:([/noparse]
Prop also has better intercog coms, as each cog has access to ALL available memory, not 4 seperate 64K chunks, ( PropII will have access to ALL 256K with any cog and run at 160mips per cog making it faster, better, stronger, able to leap buildings in a single bound, oh sorry, wrong script lol and that's before you add the 3D textured gouraud shading ability :P )
you can tell which microcontroller I have on my desk, and which is gathering dust in a deep cupboard corner, well, actually I have 7 prop setups on my desk [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
There are two drivers:
1/4 bpp drivers. These were written in assembler because:
- I wanted exact timing, at 12.5 MHz pixel clock eight instructions are needed. With C (XC) I was not sure if I could squeeze the needed timing because I was using the ports asynchronously. Asynchronicity of the ports is the reason here. (And I wanted to give assembler a go!).
8 bpp driver. This was written in XC because I used synchronous port access (buffered and synchronized to a clock). This way I could afford the uncertainty that C (XC) gives because port access will be delayed till the right time comes. This is an evolution of the other method. I couldn't have done it before because I had not found the Ports document.
This driver still uses an assembler helper (vgabuf_sender) that reads the pixel data from memory. It was done in assembler just to fit it in the tight spot left by a 64000 byte frame buffer.
Now: The 1 bpp driver is going to be merged with a new 1bpp driver based on the 8bpp driver model and the resolution will be cranked up to 640x480. I think I can get 800x600 1bpp (64000 bytes).
The 4bpp driver is going to use a similar technique.
I also developed a text driver. I only got so far as to display chars with foreground colors. Background colors other than black are missing, using similar techniques as the 8bpp and 1bpp (new driver).
I hope it clarifies things.
As ports have many more modes of operation than the propeller, determinism is less of a concern. Threads either 4 or 8 have a total maximum of 100 or 50 MIPS respectively. They cannot get beyond that. No matter what. Waits are measured to the 400 MHz clock so a wait for 1 cycle can happen. That means a thread that was starting at a clock mod 4 = 0 may start at clock %4 = 1 after the delay. That may or may not affect things.
Ale,
I've been wondering if you were the same Ale who wrote that VGA code for the XMOS. Alles klahr!
It looks like external RAM could be interesting. How about dual-porting it between two cores?
Which do you prefer?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 9:41:34 AM GMT
Thanks for the extra info. [noparse]:)[/noparse] No worries here. Looks like you are having a good time of it! I didn't mean to imply anything bad about your project!
Is it that binary? 3 threads = 100 MIPS @ standard clock, 5 threads = 50 MIPS? ...or a smooth degrade as Baggars was saying?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
For 1 to 4 thread all of them get 100 MIPS each. For 5 to 8 all of them get 50 MIPS each. That is due to pipeline and some clever shared use of resources.
I know you did not mean any detriment for the code
Leon: I'm the same and only Ale here (and there I'm called Ale500). Well, there are some Alex and Alexanders here, too. My real name is Alejandro, the spanish version.
One of the things I find really good is how they crammed in 16 bits opcodes with 3 arguments. As only 12 registers are available for these instructions a 11 bit field is used for all combinations. Some instructions are also in the not used combinations, very clever. I really miss some instructions, like compare and and with immediate, but you cannot have everything. Channel communication, thread creation and join are all in the assembler. That makes it quite fast to boot several threads.
For the time being the XMOS dev boards (XC-1) are slaves of a PC or a Mac. I hope some not-so-enslaved-boards are going to show up soon (Leon, are you there ?) and we can use those XS1s fore more things than testing code and limits.
Post Edited (Ale) : 1/12/2009 10:12:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
David May did a good job. He's an FRS, BTW, that's the highest scientific qualification in the UK.
I'm waiting for the 144BGA chips, although I could go ahead with one of my 512BGA designs.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 11:21:53 AM GMT
In addition to minicomputers, I've coded 6800, 6805, 6502, 6511, 68020, 88100, Z80, Z8681, 8080, 80486 (a complete ICL minicomputer emulation specifically targeting the faster 486 instructions and commercially verified), and now the Prop. Just because the XMOS is better than the x86 doesn't make it easy, and the x86 is arguably the worst instruction set out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Post Edited (Cluso99) : 1/12/2009 11:49:21 AM GMT
I think·determinism is highly overrated. Do I have your attention now ??
For most micros, determinism is impossible unless you disable interrupts.·Previously, it has not been really necessary, as long as you·know that your routines and interrupt routines can co-exist.
The Prop has changed this. Why, you ask. Well because the Prop doesn't have·embedded peripherals like other modern day micros. It has 8 cogs that can control very flexible counters (or whatever you want to call these building blocks). There is only one Prop, not hundreds of variants·like other micros such as the PIC. So, in order to build·internal peripherals, cog(s) are used. For some of these, deterministic code is often required. With interrupts this simply could not be the case. And neither could it be if the cogs were merely threads. For example, if one thread's code was dependant on an external event, and this·thread affected another·threads performance depending on what it was doing, determinism goes out the window - period! Your VGA may suffer jitter. It does not matter how complex a simulator is, it cannot cater for variable external events to simulate timing.
So the Prop has independant cogs that can function as peripherals to the other cogs via shared memory (hub memory). We all build these peripherals. Some of these are in the Object Exchange. Peripherals such as FullDuplexSerial, VGA, SPI, I2C, SDcard, etc. Now we have one chip that is so flexible that it can replace many variants that other chips·require. More of these variants are being discovered daily, by enthusiasts such as yourselves.
Once again, I thank Chip for the courage to create a micro which does not conform to the norm. It is truly a directional change that has yet to be understood by many - for it's simplicity and flexibility. The PropII will be another leap forward.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
All XMOS peripherals are implemented in software, also, and run on their own thread. There aren't any interrupts, either.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 11:58:08 AM GMT
Conversely I have confidence that Parallax will still have Props to sell me a long time from now.
As for engineers defending their position with the use of arcane esoteric knowledge, that can work for a while or even a long while. But I have seen it also become career suicide as what ever technology it is you are the "keeper" of suddenly gets blown away very quickly the day that some one high up realises what it's costing them.
Better to keep moving on and share what you know. That way people will always come to you because you "know" and you are always one step ahead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
uk.youtube.com/user/theamazingxmoose
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
tonyroberts09
Can't a Prop rotate a star on a screen for one tenth the price ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
Perhaps failure is to hard but my point was really where can I get a Transputer now or for the past umpteen years? It was rather a flash in the pan.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There's much more than that in it, like a codec, Ethernet, etc.
XMOS is running high-end audio applications on it this week at NAMM 2009:
http://forums.parallaxinc.com/www.xmos.com/company/news/22-dec-2008/xmos-demonstrate-complete-suite-audio-reference-designs-namm-2009
I can't see a Propeller doing that sort of stuff.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2009 1:34:24 PM GMT
The five-wire Xlink gives a 3.2 Gb/s transfer rate (full duplex). It uses 5 wires so that 32 bits can be transferred in one clock. The two-wire Xlinks are a lot slower, of course.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Yep, I bring this up every time there is a Prop II discussion. There must be a fairly simple way to do this by allowing the video shifters to shift in as well as out plus some synch logic. Just following the Prop philosophy of having relatively simple but adaptable general purpose logic.
Never do get any feed back on this from Parallax but there are already a bunch of multi Prop projects out there that would benefit from high speed links.
Next up is a means to access a pile of external RAM at speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For example:
With more speed it will be possible to have higher resolutions running on one cog. Right now 640x480 is the absolute limit for one cogs display capabilities.
With more speed it will be possible to use higher resolution character sets and graphics on one cog with a large display. As if the procesor is running a display at 640x480 its minimum amount of pixles per waitvid is 16 which allows the cog just enough time to fetch more.
With more speed it will be possible to do more complex overlays. For example I'm working on a mouse cusor for my vga driver that actually draws on the display by forcing the color lines to certaint states while a waitvid is shifting pixles out in the back ground. My goal is to have the same cog generating video do this.
And with more speed it will possilbe to work with more colors.
External ram and a large video buffer aren't really needed if you adopt the use of tiled bit mapped graphics and simply make the display buffer a buffer full of pointers.
And yes, this was off topic.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
"4 Exceptions
Exceptions change the normal flow of control on an XS1-G4; they may be caused by interrupts, errors arising during instruction execution and by system calls. On an exception, the processor will save the pc and sr in spc and ssr , disable events and interrupts, and start executing an exception handler. The program counter that is saved normally points to the instruction that raised the exception. Two registers are also set. The exception-data (ed) and exceptiontype (et ) will be set to reflect the cause of the exception. The exception handler can choose how to deal with the exception."
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/12/2009 6:06:00 PM GMT
Apples and oranges IMO.
OTOH I do see the ARM variants as the chips to beat if the Prop wants to be a player in either the consumer electronics market or some other field say like medical electronics.
FWIW