(Rumour) XB2 CPU @ 65nm

[DeanoC]

Re: ...

Because CELL is a BlueGene/L derivative.

No its not, It MAY share some research. Any major flaws in BlueGene/L (like your claim that it will only run 128K programs efficiently) would have been corrected by the time its hits the real world. Each APU may have limits on program size but the entire unit as a whole won't. Otherwise it won't even run most Sony demos, let alone games and network applications.

BTW Linux won't run in 128K either (not even close), so it looks like Deadmeat's CELL will have to run MSDOS v1

 

[notAFanB]

Re: ...

Windows NT/2000/XP can run on a quad Xeon SMP system, so why should it not run, albeit modified here and there, on a quad PE SMP system ?

A ported NT kernel will run on dual PPC cores inside CELL. But NT does not support the kind of "fork and exec into an alien kernel" mechanism without a massive modificatin.

why is this lack of "fork and exec" a problem. What's the required modification?

Quote:
fair enough, any programming solutions to minimise or attack this problem in the industry? how about academia?

None that I heard of.

so there are none, no-one has considered this? researched it? dismissemed after due diligence?

I'm interested in the problem, but I'd like to se what you think of as solutions or approaches to solutions if you would kindly share with us.

 

[Deadmeat]

...

Problem solved, OS support isn't even an minor consideration in CPU for Xbox2.

Xbox Next still relies on DirectX and Win32 API support, doesn't it?? NT kernel support is a requisit.

 

[Panajev2001a]

Re: ...

Windows NT/2000/XP can run on a quad Xeon SMP system, so why should it not run, albeit modified here and there, on a quad PE SMP system ?

A ported NT kernel will run on dual PPC cores inside CELL. But NT does not support the kind of "fork and exec into an alien kernel" mechanism without a massive modificatin.

Oh come on that massive modification is really something both IBM or MS could do: you are blowing it out of proportion.

MS did not go for stock Windows kernel on the Xbox, so why are you worried about CELL having to run stock Windows anyways ?

Either that or you can always add a layer that interfaces between native CELL "fork and exec" and the Win32 Kernel.

 

[maskrider]

Re: ...

Windows NT/2000/XP can run on a quad Xeon SMP system, so why should it not run, albeit modified here and there, on a quad PE SMP system ?

A ported NT kernel will run on dual PPC cores inside CELL. But NT does not support the kind of "fork and exec into an alien kernel" mechanism without a massive modificatin.

I stared to get confused.

Are you implying MS is using CELL or Sony is using NT on CELL ?

I can't see how one thing is related to another.

Sony using CELL and an OS that fit it.

MS is using a derivative of NT on one of the IBM's processor architecture.

What is exactly the problem with that ? MS will fail using IBM's processor architecture or if Sony will fail if Sony use NT on CELL ?

 

[Panajev2001a]

Re: ...

Problem solved, OS support isn't even an minor consideration in CPU for Xbox2.

Xbox Next still relies on DirectX and Win32 API support, doesn't it?? NT kernel support is a requisit.

That si the beauty of doing things in separate layers.

Xbox 1 did not even rely on DirectX if we want to say the truth as you could bypass the OS and the graphics API as all the code ran in Ring 0 ( mistake that MS will not repeat with Xbox 2 ).

 

[DeanoC]

DeanoC, that hypotetical OS CPU is already there... it is called the PU ( it directs the OS and manages the APU ).

I thought so, but just in case I'd read/remembered wrong I'd though I'd show how easy it would be to fix the issue. I personally have more faith in MS/Sony/IBM designing a CPU then me

 

[Deadmeat]

...

No its not, It MAY share some research.

Looks too similar not to be a derivative.

Any major flaws in BlueGene/L (like your claim that it will only run 128K programs efficiently)

That's CELL APU's flaw, not BlueGene/L's. SCEI could not afford to put 4 MB of eDRAM per application processors like IBM did with its BlueGene/L, so SCEI restricted it to 128 KB onchip access and unlimited offchip access, except that you take a hugh performance hit when you go offchip.

Each APU may have limits on program size but the entire unit as a whole won't.

An NT kernel image cannot be fit into a 128 KB space.

BTW Linux won't run in 128K either (not even close), so it looks like Deadmeat's CELL will have to run MSDOS v1

Actually, BlueGene/L application processors run a custom kernel that's probably simplier than MSDOS.

 

[Gubbi]

Win NT would actually be better suited to run on CELL than Linux would given its micro-kernel architecture (big-ass microkernel, but microkernel nevertheless), with the executive running on one PU, the IO-subsystem on another and the DirectX subsystem on a third. Whereas Linux being the monolithic OS that it is, only runs on one PU.

How much (traditional) cache is associated with each PU?

If it's none (but I doubt that, can't be arsed to go and look at the patent now), then one can argue that non-streaming (OS) software will run suboptimal simply because of the increased latency going to and from the central DRAM store.

Cheers
Gubbi

 

[Panajev2001a]

Win NT would actually be better suited to run on CELL than Linux would given its micro-kernel architecture (big-ass microkernel, but microkernel nevertheless), with the executive running on one PU, the IO-subsystem on another and the DirectX subsystem on a third. Whereas Linux being the monolithic OS that it is, only runs on one PU.

How much (traditional) cache is associated with each PU?

If it's none (but I doubt that, can't be arsed to go and look at the patent now), then one can argue that non-streaming (OS) software will run suboptimal simply because of the increased latency going to and from the central DRAM store.

Cheers
Gubbi

The amount of PU's cache was not defined in the patent IIRC ( this does not mean the PUs will not have any L1 cache, but just that I do not know how much hey are planning to have in them ).

 

[Gubbi]

Re: ...

Each APU may have limits on program size but the entire unit as a whole won't.

An NT kernel image cannot be fit into a 128 KB space.

It doesn't have to. The OS software runs on the PUs, not the APUs. It has to in order to control what process is running on the APUs.

Cheers
Gubbi

 

[Deadmeat]

...

I stared to get confused.
Are you implying MS is using CELL or Sony is using NT on CELL ?

SCEI(Not Sony, as Sony Electronics and SCEI have different Linux plans)
is using a custom OS derived from Blue Gene/L OSes(I say OSes because there are two)

MS is porting NT kernel to Power5.

MS will fail using IBM's processor architecture or if Sony will fail if Sony use NT on CELL ?

1. NT cannot run on a CELL-style APU.
2. Sony is not interested in NT.

What you have said is correct, I wish others "get" it.

 

[notAFanB]

Looks too similar not to be a derivative.

your opinion, and how does it 'look' anyway?

An NT kernel image cannot be fit into a 128 KB space.

why not? come on you've dodged this for around a page and half done. Even if the current 'build' of NT has a larrge kernal which doesn't, what exactly is stopping them from finding an approach which works AND keeps the NT kernal of sorts? If you think it's redevelopment costs then just say so.

Actually, BlueGene/L application processors run a custom kernel that's probably simplier than MSDOS.

I've checked and your right, so what is the problem of moving an NT kernal across to an MMP as you have described?

1. NT cannot run on a CELL-style APU.
2. Sony is not interested in NT.

pretty much, still answer my question if you may, why can't an NT kernal right on an MMP? Forget CELL (doesn't exist yet) for a minute and answer the question please.

 

[Gubbi]

How much (traditional) cache is associated with each PU?

If it's none (but I doubt that, can't be arsed to go and look at the patent now), then one can argue that non-streaming (OS) software will run suboptimal simply because of the increased latency going to and from the central DRAM store.

Cheers
Gubbi

The amount of PU's cache was not defined in the patent IIRC.[/quote]

I'll bet that it won't be less than 256KB (512 is more likely) with a traditional cache structure (LRU replacement, automatic fill on miss etc..)

Cheers
Gubbi

 

[maskrider]

Win NT would actually be better suited to run on CELL than Linux would given its micro-kernel architecture (big-ass microkernel, but microkernel nevertheless), with the executive running on one PU, the IO-subsystem on another and the DirectX subsystem on a third. Whereas Linux being the monolithic OS that it is, only runs on one PU.

How much (traditional) cache is associated with each PU?

If it's none (but I doubt that, can't be arsed to go and look at the patent now), then one can argue that non-streaming (OS) software will run suboptimal simply because of the increased latency going to and from the central DRAM store.

Cheers
Gubbi

From what I know, Linux has never been considered a Micro-Kernel, rather evolved from a monolithic kernel to a kernel with a lot of dynamically loaded drivers.

 

[Panajev2001a]

Re: ...

I stared to get confused.
Are you implying MS is using CELL or Sony is using NT on CELL ?

SCEI(Not Sony, as Sony Electronics and SCEI have different Linux plans)
is using a custom OS derived from Blue Gene/L OSes(I say OSes because there are two)

MS is porting NT kernel to Power5.

MS will fail using IBM's processor architecture or if Sony will fail if Sony use NT on CELL ?

1. NT cannot run on a CELL-style APU.
2. Sony is not interested in NT.

What you have said is correct, I wish others "get" it.

I see you still go with your SCE vs Sony Electronics enemies forever thing: unfortunately you seem to take a long time to read all that Transformation 60 stuff.

You still have not accepted that Ken Kutaragi as head of SSNC is the one in charge of Sony Semiconductors R&D and SCE and Sony Electronics lost their independent Semiconductors R&D centers which got consolidated into SSNC.

 

[DeanoC]

Re: ...

Problem solved, OS support isn't even an minor consideration in CPU for Xbox2.

Xbox Next still relies on DirectX and Win32 API support, doesn't it?? NT kernel support is a requisit.

I have no idea what the next generation MS console might require

But considering I've used DirectX on a non NT platform, and that Win32 API exists outside NT slightly damages your theory that either of those two things implies NT.

Just like your incorrect PSX2 name when you mean PS2, your incorrect usage of NT (which refers to a specific kernel family) makes it hard to discuss these things with you.

Win32 is an API, availible (in various amounts) on Windows 3.11, Win9x, WinNT, Win64, Solaris and Mac. DirectX is an set of API's avialible on (at least) Win9x, WinNT, Xbox, WinCE, WinCE Dreamcast, Mac and Linux.

 

[Gubbi]

From what I know, Linux has never been considered a Micro-Kernel, rather evolved from a monolithic kernel to a kernel with a lot of dynamically loaded drivers.

Which was my point. NT will, potentially, run better on CELL than Linux will.

These days, there can be multiple "kernel threads" but the kernel is still considered monolithic. Alot of that has to do with the Un*x API, where most syscalls are considered "atomic" from the outside (hence no concurrent process can fsck things up).

A microkernel can allow high amounts of concurrency in code with loads of syscalls. However, if the API that one uses defines a serializing behaviour (such as Un*x and Win32) the benefit seen is limited.

Microkernel systems with monolithic subsystems:

WinNT: WinNT kernel with Win32 subsystem
Next: Mach kernel with BSD subsystem
MKLinux: Mach kernel with Linux subsystem
OS-X: Mach kernel with BSD (? not sure) subsystem

True microkernel systems:
WinNT with native API
BeOS
(AmigaOS)

AmigaOS is in parenthesis since it didn't offer memory protection and one can argue that it isn't a proper OS without it.

Of course Microsoft fscked Windows NT up when they went from 3.51 -> 4.0, where they moved GDI into the kernel, in part to speed up Win32 execution, causing the kernel to bloat.

Cheers
Gubbi

 

[Gubbi]

ignore

 

[Deadmeat]

...

I see you still go with your SCE vs Siny Electronics enemies forever...

Sony Electronics is trying to consolidate its consumer electronic platform on industry-standard CELF.

CELL architecture is incompatible with CELF and requires its own modifications/extensions. SCEI has no choice but to pursue its own non-standard Linux to drive CELL.

I have no idea what the next generation MS console might require

The beauty of Xbox Next is that developers are already familiar with its development. Same APIs, same compilers, only much faster.

But considering I've used DirectX on a non NT platform, and that Win32 API exists outside NT slightly damages your theory that either of those two things implies NT.

The most upto date DirectX implementations are on NT kernel. Right now MS supports two kernels, NT and CE. CE kernels are not quite as capable and upto date as NT kernels, so I would write it out.

Win32 is an API, availible (in various amounts) on Windows 3.11, Win9x, WinNT, Win64, Solaris and Mac. DirectX is an set of API's avialible on (at least) Win9x, WinNT, Xbox, WinCE, WinCE Dreamcast, Mac and Linux.

With the difference of the most upto date versions available on NT kernel..