IBM 610 workstation computer 3444

are memory cache board. main is a

Sure. But we are viewing the system from differently shaded glbuttes :-). That's where we get into great communication problems. And it doesn't help that I am not good at that guy thing we call hardware.

But I don't see how they can be without being called memory. I'm thinking about a system that has 1000 CPUs in it. What you just said put a picture of 1000 wires coming out of each CPU to touch all the others' L2 cache. They don't make wires that small. Note that a CPU also has to have a wire to itself, thus the 1000 instead of the 999 wire count.

I wasn't having any doubts that his hardware would work; I was having problems with expecting an OS to deal with it beyond a PC-flavored, single-user, single-instruction end system.

I guess what I'm trying to do is make sure you gear designers don't forget about extensibility with respect to delivery of services. Hardware types don't, and aren't supposed to, think at this level. But it has to have some affect on what does get designed.

The contents of any memory location doesn't matter until the CPU needs the bits to be able to execute the next instruction. Now, timesharing OSes group these sets of instructions and data by job. At the job level, the bit sets are further divided in tasks-section of wallclock time; they are usually user commands and the result of them. So the sets of bit flows on a system become more and more smaller there's a word for this but I can't think of it. The only time the results of CPU0 need to be known by CPU1 is when CPU1 is about to take over the task that CPU0 had just completed.

Things are much more complicated and I think I wrote up a garbled explanation of how the bits flow. I do wish I had more background in set theory and category theory because I think this all can be written in math terms.

I think you are not considering the word "data" correctly. Lynn touched upon it. At certain points of time, an OS treats the code it is about to feed to a CPU as data. That's why I think in bit flows; people always misinterpret the word data and think of this as a set of bits exclusive of code. It is not.

Sure. But it can be stale forever, it the bits don't need to be used. There were lots of times when JMF threw away bits because they would never be needed. Why do a write when there's no point in saving it? (I'm talking about the monitor scheduling).

And here you are completely wrong. If you force I-O to be done sequentially in tandem with the software, you have just forced all bits to go single file through a gate.

Caches have to appropriate for I-O if its CPU is the staging area for setting up the transfer directions (we called them IOWD list). In a system, you should be able to designate a CPU to take care of certain business and only that business. IBM was doing this in the 60s already. That's how they got real good at data processing. Scientific instruments needed dedicated CPUs and other gear to work in realtime.

My point is that the bandaid covers everything but the correct spot.

Sure. Do did non-write back work for SMP. What I said is talk to the software guys and find out what kinds of trickery they had to do to get the gear to work.

SIGH!. I have no doubt that systems work quite well. I do have doubts that they work at their best possible.

This is the hardware side. How does the software have to fix thing up when fill in any problem occurs?

Yup. The striped guys do this by only allowing one player to move at a time. The game is based on all players moving independently of the others' movement with the excception of pbutting the ball from one guy to the next.

UP?

I don't believe you (that these are SMP). They are multi-processor. But the scheduler (code) isn't reentrant.

BAH