Slashdot Mirror

Or get an XMOS microcontroller . Multiple CPUs. Also, each CPU has hardware support for multi-tasking, so each of four to eight processes gets a guaranteed portion of the system clock.

The system programming model is based on Communicating Sequential Processes (CSP). The I/O lines have hardware support so you can do FPGA-like timing and control, but using a nice, high-level language. Lightning fast. Rather popular for audio-processing systems.

Actually, I was thinking more about that new XMOS chip. 8 core. 32bit. Looks like a super parallax propeller. A fellow Slashdotter turned me onto them. I now have one of their StartKit promos and am anxious to wrap up a current project so I can start exploring what I can do with this thingie. I wonder how it stacks up against a NetBurner. I do not know that much about it yet; I was hoping I would find a book like Labrosse wrote for the uC/OS II.

Things are so half-cooked right now its hard to find anything I feel good about holding onto for good. I liked the stability and simplicity of DOS, and have been sorely frustrated that every implementation of a GUI based multitasker I have seen has rapidly bloated into a unwieldy monster. I simply can see no reason things have to be so complex. 16GB for an OS? That's the base install of WIN7 on my Walmart laptop. Somehow it seems to me that even 1MB of code to manage the core functionality would be severe overkill.

Say there was some way the OS got one core and ROM space. Once flashed, all changes locked out until a hardware jumper is installed.

Maybe OS gets several cores - managing the VGA alone is a heck of a lot of busywork. The OS does most of the heavy lifting anyway.

Would not surprise me to have multiple XMOS chips so that each app gets its own core to play in, with the OS chip running the show.

But whatever we do, never, never, never let the OS take instructions from the net. An app can, but not the OS. The OS has to motherhen the apps and cannot be persuaded by clever code the way the way Microsoft or the US Congress gets persuaded by special interests. I do not have my hammer phoning home for permission to drive a nail. I do not need my OS doing it either. If some author wants to code his app to be a pain in the ass, let them. It can be gotten rid of as fast as an annoying fly. I just need this hardware configured so the fly cannot leave its maggots all over the other apps; he can only mess up his own jar.

The Parallax Propeller looks very cool.

However, I'm a big fan of the XMOS chips, which also provide multiple cores and logical cores that provide guaranteed timing. Really great performance. They've recently made two announcements that are worth mentioning to slashdotters that have read this far into the thread:

A $15 development board (startKIT) that has a Raspberry PI interface built in (or can be used standalone), and

A new SOC (xCORE-XA) that marries an ARM processor to an XMOS processor.

In both of these products, you would have a high-level component controlling the very slick, very powerful, I/O processing of the XMOS chips.

I am not associated with XMOS (despite sounding like a shill). I just use their chips in several research projects.

The Parallax Propeller looks very cool.

However, I'm a big fan of the XMOS chips, which also provide multiple cores and logical cores that provide guaranteed timing. Really great performance. They've recently made two announcements that are worth mentioning to slashdotters that have read this far into the thread:

A $15 development board (startKIT) that has a Raspberry PI interface built in (or can be used standalone), and

A new SOC (xCORE-XA) that marries an ARM processor to an XMOS processor.

In both of these products, you would have a high-level component controlling the very slick, very powerful, I/O processing of the XMOS chips.

I am not associated with XMOS (despite sounding like a shill). I just use their chips in several research projects.

So, the transputer is going to get a comeback? :) But seriously, transputers are alive and well. I'd salivate ever so slightly given an XMOS slice running at 1THz.

Yep, thought of XMOS immediately when I saw the title. 16 quad-core CPUs linked together in a 4D hypercube: https://www.xmos.com/products/development-kits/xmp-64

Alive and well as XMOS products. I love those chips.

The ideas from inmos are alive and well at XMOS. I use their two core chip and I'm fairly happy -- it's plenty fast for what I use it for (industrial data collection). If only they documented the darn thing better.

These days, you don't even need an FPGA. Take any fast multicore chip like Parallax Propeller or fast multithreaded chip like XMOS XC-1 and you can emulate pretty much any retro 4 or 8 bit CPU at native or faster speed. With video output. All pretty much single chip -- all you need is a clock crystal and some voltage regulators. The propeller has 8 completely independent cores called cogs, each with 4 kbytes of dedicated RAM, and 32 kbytes of shared RAM in so-called hub. XC-1 has hardware multithreading with zero-overhead thread switching: it can run 8 threads in parallel, and thread switch is done after each single instruction, and those usually each take 1 cycle so you have true 400/500 MIPS performance, with 32 bit transfers.

There is a single cog Z80 implementation for Propeller, called ZiCOG, and it runs at about the speed of a Z80. Not cycle accurate, though. On XMOS, you can trivially run an order of magnitude faster, or more, and be cycle accurate at native speed. Both Propeller and XC-1 enable you to have a single-chip emulation of pretty much any 8 bit computer -- that is the CPU and everything else, with sound and video output. It's somewhat less work on XC-1 to keep it cycle accurate.

I've recently looked at Android API documentation, and it seems to be a rather clean and understandable design. I've dabbled a bit with the SDK and running my code on one of those cheap Augen Android-based tablets from Kmart, and going past "hello world" was quite painless. Then, for reasons I can't quite understand, I seem to puke a little bit every time I see Objective C code. It just looks so darn ugly. For whatever reason I just can't stand some of Apple's APIs. Never mind that they plainly don't document some -- you'd think -- pretty basic parts of their API, at least on the desktop. Case in point: just try to find out how to open up a raw socket on a selected network interface and you'll see what I mean. One shouldn't need to google for that. By "selected" network interface I mean you know the name like en0, but the interface has no IP or anything else.

And that comes from a guy who doesn't mind seeing legacy LISP code (like Maxima sources that I used to browse quite a bit), who doesn't mind various more- and less-pure functional languages (OCaml, Haskell) and functional "hacks" like LINQ, and who can wholeheartedly embrace "customizations" like xmos's XC parallellizable variant of C. I can even stand most of IEC 61131-3 languages. I guess beauty is in the eye of the beholder...

There's a difference between what amounts to a dumb D/A converter with a bunch of support logic for video timing, and a card that's a whole computer in and of itself. Realtime video rendering on par with a dumb graphics card can easily be done 100% in software these days, even on rather lowball hardware -- just look at what's possible with a single chip Parallax Propeller microcontroller. A slightly more powerful hardware would be the XMOS XS1 platform. Both of those platforms let you have 1024x768 VGA or HDMI output, defined completely in software.

As for the "standardised" registers on Matrox/S3/Tseng: you obviously have no idea what you're talking about. All those cards were emulating the legacy IBM register set, but this was only a looked-down-upon legacy compatibility mode for low-resolution modes -- maybe up to 16 color 800x600. All of the cards you listed had mutually incompatible register sets that you had to access for native operation at full resolution, and for access to blitter and other acceleration primitives. The best you could hope for was that the VESA BIOS didn't have bugs and that the flat framebuffer native video modes would work, but that was without you knowing anything about registers. You just made a mode switch call into the BIOS, and then inquired about where the framebuffer was; from thereon you were on your own.

The fast pace of progress in graphic cards pretty much makes it impossible to have any sort of a consortium-driven standard for access to hardware. Whatever would be publicly available would lag a generation or two behind shipping hardware. Making solid, interoperable standards is hard. If you want it done quickly, especially in parallel with hardware development, you need to hire a lot of extra, very experienced (not cheap) talent. Of course ATI and NVidia have their in-house spec/documentation teams, but they only have to worry about making something that will keep their own divisions in sync. It doesn't have to be understandable outside of their doors. Don't underestimate the information content of corporate culture: there's plenty of documents that I've seen that are next to useless simply because one would need to be "then and there" to get the context necessary for understanding.

XMOS (http://xmos.com/) has developed a mostly-C language with a few Occam-like extensions, which might also be worth considering. It's called XC (http://www.xmos.com/system/files/xcuser_en.pdf/).

XMOS (http://xmos.com/) has developed a mostly-C language with a few Occam-like extensions, which might also be worth considering. It's called XC (http://www.xmos.com/system/files/xcuser_en.pdf/).

You should take a look at XMOS. Several of the design team worked on the Transputer at Inmos. Aimed at the embedded electronics market it is a micro-controller with multiple cores, and the same threading model and HW links from the original Transputer. They also have a range of simulators and other dev toys for free download.

PaulBu <: reply

I always end up plugging this (I know a guy who works there), but if you didn't know about it, David May has a new outfit. It's very much in the same vein as the Transputer, and it's still based on CSP. You may want to check it out!

Exactly! Nothing new under the sun. For a better approach of this architecture, and something modern look at :
http://www.xmos.com/technology/xcore/
8 to 32 thread on a chip with speedy "serial" connexions.

I think most concurrent languages have been derived at least in part from CSP, so they'll probably all 'feel' like occam; it's just occam got there first. Incidentally, if you already knew about occam, you might want to check out David May's (the guy behind Occam) new startup XMOS.
I'm not affiliated, but I do own their dev kit :-)

Very lucid description. The other problem with the design is that you don't get what you expect; using a simple 4-way grid should give predictable latency costs between nodes. Unfortunately their routing algorithm is non-predictable so you can't statically schedule threads at compile-time to feed each other, it all has to use dynamic control-flow. Shame really.

If you liked the transputer then you should look at its other descendant that is in the process of coming to market. There isn't a wealth of public information yet although they are in the process of releasing dev-tools and simulators. The largest chip only has 4 tiles, instead of the Tilera's 64, but it is aimed at the low power market. They should scale it up to similar levels without the silly amount of power the Tilera draws.