Originally posted by wizard69
The 400 series is available as a core. You take your design automation tools, tack on a few functional units, compile and send to the foundry. It no real mystery and those functional units can be derived from a library or a few of your own. I would not be surprised at this moment in time to hear that AltVec exist as source code some place.
I'm not saying it can't be done. I'm saying it doesn't make sense to do it. The 440 was expressly designed to be extensible. A good SoC solution needs to be extensible because in the embedded market, one size rarely fits all plus an extensible design will have longer legs as far as product family lifecycle goes. (You don't have to retool for every new fad in communications technology.)
So yes, you can add VMX and 440 FPU2 units to the 440 quite handily.
Actually I thought we started out with 2 core processors but that doesn't really matter. The only thing that bothers me about the MCM is that they where expensive, but maybe that is not a problem at the volumns that Apple would use.
Well he said two MCMs with two 440s each. Which is nonsensical at the outset, since an MCM describes the Power4 and Power5 packaging and IBM does not use the terminology elsewhere, to my knowledge. But leaving that aside, there is the issue that what an MCM provides is interchip communications busses. It's purpose is to allow the cores to communicate, so separating them into pairs with only two per MCM is counterproductive if you know you'll need four cores. So I assumed that all four would be on one MCM.
In any event I would suspect that the 440 was used for prototype work. There is a good chance that a follow on to the 400 series may actually make it into the design.
Well, if you want to create imaginary architectures to make Nr9's scenario more plausible, go right ahead.
Well that may be his answer but what would happen if a MMU that supports SMP where tacked onto the core.
There would also have to be support in the core for thread locking, etc. (Means more silicon, more heat.)
This is unix, there is support for communications between processes already. I don't think you would see a major retooling of the operating system. In any event I'm leaning to a more traditional SMP system on a chip.
This is actually a self contradictory two part objection. Please rest assured that (as Nr9 points out) a distributed architecture would require an entirely new programmatic model despite Mac OS X's unix foundations. It would mean rewritting the OS from the ground up. You would not be able to use the Mach kernel, for instance.
As to the second part of your objection, yes an SMP implementation is possible, just not with the 440 core.
Frankly I can't ever recall Nr9 saying that a single thread would run acroos several processors. I'm reasonable sure that was someone else because I responded to that specific post.
Whether he said it or not, it becomes a fundamental requirement as the only alternative is to run it on a slow core effectively undoing any expected perfromance benefit.
My position is that it would be easiest for Apple to go the SMP route on the new chip implementation due to the leveraging of existing software. It would certainly give you the best bang for the buck in the short term. But and it is a big but SMP does not scale forever and not all programs can really make use of it. At some point multiple independant processing units that communicate amongst themselves may be a better idea.
Well, in some applications, the advantages of distributed architectures are overwhelming. But that is not to say that this is true in all cases. Yes, it may be true that there are limits to SMP systems but can you tell me what those limits might be? IBM is heavily invested in the Power5 architecture which is carrying SMP down to the thread level (SMT).
In effect a cluster of SMP units on one motherboard or MCM or SOC.
Sigh. You really can't just jumble up terms like MCM, SoC, SMP and "cluster". Each has a specific meaning in the context of this discussion so you can't posit the integration of seemingly anti-podal or contrasting technologies without a great deal more explanation as to how it would be achieved.
This is not a spooky goverment project. It has the potential to solve a number of issue related to low power operation and high performance.
You miss my point. Right now, the only kinds of applications (software) that use the kind of cellular programming model described are high end, highly parallel, high performance applications such as climatological modeling software run by government agencies and academic institutions.
Why you believe that a bunch of portin will need to be done is beyond me. Sure some system level stuff will have to be done, but there is no reason at all that all traditional programming models could not be supported. What you would be doing is evolving the machine not building a new one.
You'd think so, wouldn't you? But then, you'd be wrong. It would be extremely difficult for any number of reasons, not the least of which is that "ain't no one been there yet".
That is like saying if the 970 comes out with a larger cache its not the 970 anymore.
No, it's more like taking the APU of the PPC 970 and replacing it with a 440 core. Then repeat with the FPUs. And so on.
Ok explain what multithread has to do with SMP. Further do you need SMP to support multithreading. <<<<Trick question>>>>.
You got me. I have no clue what you are talking about.
Please, go here for info you might need.
Again explain no applications for a laptop.
As described, the architecture of the laptop in question is as foreign to Mac OS X applications as the P4 is. (Actually, the P4 is a kissing cousin compared to the implementation described.) So, if Apple were to ship this next week, there would be no software for it.
These are rumors and wild ass geusses you know
That, of course, is the thrust of my argument.
Please give up on the seperate code base thought would you. It shows a complete lack of understanding on what is possible. Believe me many things are possible.
Nope, sorry. Not buying it.
Even worst what is this talk about a new instruction set!!! we have been talking PPC since the begining of this thread.
No, at least some of us have been discussing the cell architecture under development by the STI group. Whether it is implemented starting from PPC or x86 designs won't matter that much. You could begin with transmeta's architecture, but in the end you will have a bunch of instructions that make no sense to any other architecture. The problem space is too divergent. Hence, a new instruction set.
Now, you might be able to convince me it could be done as an extension to an existing ISA, but you'd have to work pretty hard at it.