OSDev.org

maakera wrote:There are TONS of articles about this, you cant just ignore them.

http://en.wikipedia.org/wiki/Bulldozer_(processor) read a lil more.

LoL. That ain't 128bit . That's just 128bit FPU. And "Support for Intel's Advanced Vector Extensions (AVX) instruction set, which supports 256-Bit floating point operations".

To clarify: it's just another CPU that has two 128bit FPUs that can be used as a 256bit FPU. While that's interesting, it's definitely NOT a 128bit CPU (NOR a 256bit one).

Depends what you consider a 32-bit, 64-bit or 128-bit computer.

Till the popularization of using addressing space for 32-bit verses 64-bit comparisons. Most higher end computers (ie mainframes) used their largest register supported as a means to say what is their "bit" number irregardless of addressing abilities. Considering, all the data in the world can be addressed with a single 128-bit address space and leave us room to expand greatly our collective data storage needs.

128-bit processors could become prevalent as a method of addressing over 2^64 bits of information. Up to 2^128 could be directly addressed with 128 bits. That amount greatly exceeds the total data stored on Earth today (2010), which has been estimated to be around 1.2 zettabytes (over 270 bytes).

The IBM S/370 was a 128 bit computer in that regard. IBMs current Series i runs everything in 128-bits and then converts down to what ever the hardware being used is. So the move from 32-bit to 64-bit required no change in the software as it wont require a change into 128-bit addressable hardware.

Your graphics card runs a GPU that is 128-bit or 256-bit and even 512-bit in processing while calling up values from its RAM, instead of 64-bit wide values your CPU calls up, but the need for it to address that amount of memory does not exist hence why its not being further developed.

Dimitri

Erm... The architecture addressing size transitions for zArchitecture have been quite ugly ones. It started off with a 24-bit address space, so apps used the upper 8 bits as flag storage*. They expanded to 31-bit, by using the upper bit to select between the legacy 24-bit and new 31-bit addressing modes, and allowing a reasonable degree of interoperation between old code (which just had to be modified to not use the upper bit) and new code, at least when the old code is in charge.

The 31-bit to 64-bit transition has been much the same as for other transitions: 31-bit apps link to 31-bit libraries (and I include 24-bit legacy apps in this category), and 64-bit apps link to 64-bit libraries. Software still has to be ported.

There is no magic bullet here for address size changes.

People should just have added a bus error of sorts for misuse of unimplemented bits. AMD has apparently learnt that lesson when they designed x86-64...

I note I forgot my asterisk. So here it is:

* Evidently the Macintosh' developers were taking a leaf out of their book. Though the person who designed their memory manager later wished to hit himself for being stupid by not putting his flags in unused bits in a different field...

The AS/400 virtual instruction set defines all pointers as 128-bit. This gets translated to the hardware's real instruction set as required, allowing the underlying hardware to change without needing to recompile the software. Past hardware was 32-bit CISC, while current hardware is 64-bit PowerPC. Because pointers are defined to be 128-bit, future hardware may be 128-bit without software incompatibility.

That is what I was mentioning.

Dimitri

The Transmetta Crusoe and Efficieon processors were already 128bit and 256bit VLIW processors anyway... so its been done not quite what you meant but they acutally do exist