a dozen cpu's on a chip

Since your proposition is wrong, everything that come from it is suspect even if the logic is flawless, which it isn't.

Wrong again. I can tell you're not a computer architect.

If your application is that limited you're not likely to be using a general purpose processor, so the discussion is moot.

ONLY if the CPUs have tasks assigned when the system is designed. IOW, this may work for embedded processors but not general purpose computing.

No, it's really not new, rather rejected.

Now you sound like Dimbulb. ;-) Note that the Cell processor is essentially an embedded processor. The tasks it has been designed for are quite limited.

No, you have it backwards. Intel has been driven by hardware for the past thirty years. As many processors as we're likely to see, there will always be more tasks/threads.

Well, we can certainly agree there, though not likely on what. ;-)

On May 10, 10:50 am, Phil Hobbs wrote: [.....]

I think in many cases the illusion of a single large shared memory is not needed to implement the needed operations. If we can remove the need for it, we don't need the huge bandwidth on the interconnect.

If we assume a Harvard like processor where the code space is never written to, the code space of each CPU can be independant during most of the run time. This means that no transactions of the slave CPU can ever require that the code space be brought back into sync.

The stack space and local variables of the routines running on the slave CPUs are private to the task. Only the defined inputs and outputs of the task really need to be shared with others. If we assume that memory is reasonably low cost, we can have a block of memory passed between processes to carry the information from task to task. This makes resyncing the caches a lot easier. The source CPU's cashe's "dirty" flags can be used to indicate what needs to be copied over.

If the source CPU is forbidden from overwritting the output data, then the transfer logic is reasonably simple. The source CPU's dirty flags just copy into the recieving CPU's "out of date" flags.

This sort of processor would mean that programmers would draw data flow diagrams and not flow charts. It would also push towards thinking like you are coding in APL or octave and not like fortran or C. Lots of things would be done to arrays.

I said it "trends in that direction", not that it was the ultimate architecture. But why is one PPC plus six simpler integer processors "quite limited"? It's obviously more general than the PPC alone.

I believe that's just what I said. They have just pushed an 8008 architecture - a dog when it was new - into nanometer silicon. Their attempts at cutting over to more modern architectures - iapx32, Arm, Itanic - have been expensive failures.

As many processors as we're likely to see,

Why? What would a desktop PC need with 1024 threads?

Something more like Cobol, where programmers are forced to deal with the application, rather than using the application as a platform to show off how tricky they can be. Something without pointers. Something that is impossible to crash.

John

But the problem does exist. I suggest that different hardware, and an accompanying OS and set of rules, would make most of the nightmarish problems of modern pc's impossible. The Mac OS demonstrates that good programmers in a closed, disciplined environment *can* do a decent job using traditional CPU architectures, but the fact that they are an exception suggests that a more-hardware/less-software approach to managing resources would be better for everyone.

Engineers are, on average, better thinkers than programmers. Perhaps because engineers generally admire simplicity, whereas programmers admire complexity.

Intel and Microsoft still haven't come up with a way to keep from executing data and stacks!

John

The nightmarish problems of modern PCs are an artefact of the "ship it and be damned" management culture in some software shops. And the very openness of the PC architecture which allows zillions of permutations of imperfectly written drivers.

It might be at least for thread management.

And they are so modest with it...

I count myself as an engineer in that respect. I don't think there are many programmers who admire unnecessary complexity. There are far too many that do not know enough about classical algorithms though.

Oh yes they have! Hardware assist and software to go with it. An implementation was included in XP(SP2) the Data Execution Prevention using the NOEX page exception mechanism. It isn't perfect - nothing ever is, but it is a big step forward. See

Regards, Martin Brown

It wasn't bus bandwidth that bogged down most timeshare systems, it was cpu cycles but more often it was disk thrashing, caused by task swapping. Thrashing disappears as an issue when a single-user system has gigabytes of ram and doesn't need to swap/page code or data to disk (unless the ram is virtual and the apps are bloated, ie most Windows systems.)

I get occasional messages from Windows informing me that it has to increase my virtual buffer filesize on disk. And I have 2G of ram. Insane!

John

Vista uses >1G out of 2G just sitting there.

Best regards, Spehro Pefhany

Bleh, I hate it already! Here's a perfect example from my own experience:

OPCODE_INC = 40h ; INC AX OPCODE_DEC = 48h ; DEC AX

SET_X_INC textequ SET_X_DEC textequ (and for Y)

The code for the inner loop (containing label incdecx) is identical for all four directions (+/-X, +/-Y) except for this one opcode. So I have it change, instead of quadrupling the entire routine, or putting conditionals inside the loop (gack!).

I don't know just how often this is done, although I recall MS is fond of it for some purposes (obfuscated, self-modifying code appears in a few shady places, like for testing compatibility). Compressed executables, I would suppose, have to do this. Situations like this example are definitely an efficient place to use Von Neumann architecture.

Funny, it also occurs to me that, in protected mode x86 (the above runs in real mode 808x, BTW), you could put the code in a read-only segment, so writing to it would throw a page fault, thereby having the same effect.

Tim

-- Deep Fryer: A very philosophical monk. Website @

Java? Well, it crashes, but it doesn't take down the entire computer.

Eww, Java...

Tim

-- Deep Fryer: A very philosophical monk. Website @

The memory bandwidth isn't fixed--the more cores you have, the more front-side busses you put in, till you run out of space for solder bumps. Memory controllers (e.g. Northbridge) are easier to make than CPUs.

That's where we on-chip optics folk are aiming--getting _lots_ more off-chip bandwidth with much lower power.

Cheers,

Phil Hobbs

The new XMOS chip, developed by David May who designed the Inmos transputer, has just been announced:

They've told me that working chips have been supplied to some customers, and that they will be available from Digi-Key in a few weeks. Development software will be available from Amazon.

Leon

Given my recent experience with PLC software it seems reasonable to project that future revisions will need 1023 threads and the first TB for the drivers and copy protection.

Maybe ADA? Ducks.

Robert

The IBM360/IBM370 had an easy solution for this. You could exec and instruction that was held in a register.

You can also simply have N copies of the routine. Since memory is cheap and the results would be a faster machine, I see it as worth the extra copies.

When stupidity will serve as an explanation, you need look no further.

Those are decompressed once at load time. This could be done in the load process. I know that MS does it by building in the code to do the decompress (eg: format.com) but that would serve as evidence that it is a bad idea.

No, it really isn't. You are better off to have a Harvard that sees the code space of another processor as its data space. That way the decompress process can go much faster since you keep the advantages of the Harvard.

Except that this means that the data and code transactions still go on the same bus.

Except on Windoz 98.

On May 12, 8:12 am, John Larkin wrote: [....]

No nontrivial language can ever be proven to be imposible to crash.

Intel came up with the 8051.

But...but...but The 8051 is perfect, you can't execute data nor the contents of the stack.

I think it is far simpler than that.

IMNSHO the problem is due to softaware being licensed, rather than sold. The converse is (almost always) tru for hardware.

So the SW licenses all include lenghty "we neither know nor care if it works, screw you" clauses.

whereas hardware, being sold, has to abide by all of the relevant commercial law - you know, if it dont work, I get my money back kinda thing.

the "FU2" nature of sw license agreements has then promulgated the "ship without consequence" mentality (or, more correcly, the lack thereof)

Cheers Terry