Slashdot Mirror
Microsoft Leaks Details of 128-bit Windows 8
Barence writes "Microsoft is planning to make Windows 8 a 128-bit operating system, according to details leaked from the software giant's Research department. The discovery came to light after Microsoft Research employee Robert Morgan carelessly left details of his work on the social-networking site LinkedIn. His page read: 'Working in high-security department for research and development involving strategic planning for medium and long-term projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM.' It has since been removed."
Who needs 128? I haven't even used all 64 of my current bits yet.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Why, is Google asking that because they're running out of addressable memory space again?
A positive attitude may not solve all your problems, but it will annoy enough people to make it well worth the effort.
Well in *my* OS, the volume goes all the way to 11!
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
has been transferred to another department - the Pit of Despair.
Just because I can hook a shark from a boat, I do no offer to wrestle it in the water.
Sounds fishy to me. Producing a 128 bit operating system before 64 bit is in wide use just seems like a waste of time. Of course this is microsoft so who knows by the time they have that out we may actually have 128bit chips.
We're doing five blades.
With Windows 6.1 being Windows 7, does Windows 8 actually mean Windows 7?
The is no Robert Morgan that works at Microsoft. Not sure who this guy is but if he does work at MS its not his real name.
Well, not anymore, anyway. :-)
Best "String" Ever!
That would make Windows a 128 bit wrapper around a 64 bit implementation of a 32 bit extension for a 16 bit patch to an 8 bit operating system, originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.
here.
/...
Yeah, well I'm working on an OS that'll be 129 bits!
http://alternatives.rzero.com/
Windows 7 isn't even officially released and already nonsense is leaking about the next release with promises they can't keep.
FIrst let them release WinFS.
Pretty good is actually pretty bad.
It refers to a 128 bit filesystem ala ZFS, not the whole OS.
Either we're not reading the same article, or I suspect you didn't read it at all. At no point is a filesystem mentioned.
16.8 million terabytes of RAM should be enough for anyone.
Well, that settles it, then! Why on earth would I buy a paltry 64-bit Windows 7 when a much shinier and newer 128-bit Windows 8 is right around the corner? I'd best hold off until then! Thanks, Microsoft!
Demanding constant attention will only lead to attention.
Noooooo! I want to be able to say I have a 23488102 bit OS if that's the size of my bzImage! And once I have 1TB of porn I can call it a 8.79609302*10^12 bit operating system!
Seriously - it's one thing for some IT marketing types not to know that a 128bit OS would need a 128bit processor (which would be a Big Thing, especially if HP were getting back into the market of CPU design and manufacture), but for the submitter and eds to not point it out makes it look a little daft.
Moderation Total: -1 Troll, +3 Goat
It refers to a 128 bit filesystem ala ZFS, not the whole OS.
Either we're not reading the same article, or I suspect you didn't read it at all. At no point is a filesystem mentioned.
I'm with you, I don't know where he got filesystem from:
The senior researcher's profile said he was: "Working in high security department for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
Clearly says architechture.
I am the lawn!
This has been discussed on OSNews and it is most likely about the filesystem or FPU and not memory addressing.
http://www.osnews.com/story/22301/128-Bit_Support_in_Windows_8_9_
They haven't even got 64-bit mig. done / smooth for their users, and they're looking at 128-bit already? Is this some kind of a joke? Or have they just realised they've missed the 64 bit boat and they're just going to work seriously on the next step up?
Not necessarily, they could skip a step entirely, just like WinXP was followed by Win 7.
`echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
So, that's right on schedule for Windows 8 then.
'Sensible' is a curse word.
Quoth Balmer, "Let's see hackers find our security holes in this address space!"
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
"almost all programming can be viewed as an exercise in caching"
- BSOD now in 4D (3 spatial dimensions and time, more precisely from 1988 to 2015)
- That is what requires Security Essentials to have a string sample in memory of every Windows virus/trojan before 2006
- Bill Gates finally agreed that 640k wasnt enough for everyone.
- Codenamed Windows TNG, where no bit has gone before
- You actually will need all that memory to not require swapping (unless you load more than 3 apps)
The is no Robert Morgan that works at Microsoft. Not sure who this guy is but if he does work at MS its not his real name.
Well, we don't know who you are, either, so why should your input on this be paid any attention?
Just like that other chap who was always making wild statements about what Microsoft was going to do next.
They let him go too. What was his name again? Will? Billy? ...something.
Genesis 1:32 And God typed
In terms of memory, 64 bits can address 18 exabytes. Even Google isn't going to be using that for a decade or so. Assuming Moore's law continues, it will be about half a century before PCs need that much RAM. Dealing with 128 bit numbers for mathematics is of limited use (if you do want to deal with them, you'll probably have a need for 256 byte and 512 byte numbers as well).
And it's not like there's been much perception of a need for 128 bit CPUs. 64 bit processors have been around since the 1960's with fairly mainstream CPUs sine the early 90s. I don't think this is like RAM. I think there's a limit to how many bits we can use.
Yeah right. Gob like the mersey tunnel.
Microsoft has been aiming towards high-performance computing recently, working with companies like Nvidia. If you are going to have racks and racks of CPU's/GPU's, it would make sense to have everything accessible using a single memory space.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
It refers to a 128 bit filesystem ala ZFS, not the whole OS.
Oh. I thought they pulled a Vista again and the 16 exabytes of RAM provided by 64-bit was not enough for their latest crime against humanity.
But I'll tell you how it will end.
The final architecture EVER will be 640-bit. And that WILL be enough for everyone.
Mit der Dummheit kämpfen Götter selbst vergebens
Not only does it say 'architecture', it also says 'architecture compatibility'.
Why is that important? Because it does not mean that Windows 8 will necessarily be 128bit, just capable of being 128bit - for all we know, his entire role is ensuring that the teams code to a set standard which allows ease of porting to 128bit in future.
Clearly says architechture.
Okay, but the question is what does that mean? If it just means 128-bit operations or registers, then that's been around since the original SSE. If it means 128-bit addressing (like it usually does), then who the fuck is making those chips and why? Very few 64-bit chips actually support the full 64-bits of address space (certainly not Intel or AMD), simply because there's no need. You could make every computer on earth part of a huge shared-memory system and have room to spare, not that you'd ever do such a thing. Once systems get far enough apart, shared memory stops making sense as maintaining coherence/consistency becomes too much of an overhead. If you were building a cluster as a shared memory system, and each node had 1 TB of RAM, you could fit ten million nodes in before you started to have address space problems. Even the most wasteful of Stupid Virtual Memory Tricks aren't going to put a lot of pressure on 64-bit addressing any time soon.
I mean I guess I can see the point for the distant future, and hey who the hell knows when Windows 9 is planned for much less will actually arrive, so it can't hurt to make sure it's 'compatible'... I'm just more surprised that any of the partners listed would have 128-bit on even far-reaching roadmaps.
The enemies of Democracy are
long long long?
really long long?
Someone else posted a link to an ArsTechnica article about this. They had more info from the LinkedIn post, which indicated that the work was being done to target the IA-128 instruction set (which is currently only available as a simulator, no actual silicon, *yet*). But, since Intel hasn't abandoned Itanium yet, and they are targetting it at Enterprise and High Performance Computing, I could totally see Intel evolving the Itanium architecture from 64-bits to 128-bits. After all, there are a few servers in the world that handle truly epic amounts of data, and really might be able to use more than 64-bits.
It's probably that they are laying the groundwork now, for release 5 or 10 years down the road.
No, that was Windows XP... back at the beginning of this decade. Next question.
Maybe because he was thinking logically? There are already 128 bit filesystems out there, ala ZFS. Why? Because with huge servers and clustering you can get some insanely huge numbers when it comes to HDD space. But as I'm sure we all know when it comes to a 128 OS, we are usually talking about addressing, ala 16bit, 32bit, 64bit.
As it is now there isn't even any stock machines being built (that I know of) that can support even 1/100th of the amount of RAM that can be addressed in 64bit, let alone any need in at least a decade or two for 128bit addressing. Lets face it-16 exabytes of memory is a whole damned lot in anybodies definition, and I doubt anybody here can think of any reason that we could possibly affordably build a machine that hits that limit in even 20 years. Filesystems on the other hand? Well we already have drives hitting 2TB, so hitting the 64bit limit there, while it will still take awhile, is doable. And let us not forget that MSFT has always been the kings of "me too!" and don't like other groups having features that they themselves don't have, so I have no doubt that when they saw ZFS is 128bit that they said "we need to have 128bit capable servers too!"
So in conclusion it doesn't need to be said, as it is simply common sense. Even at our current rate of RAM size growth it would probably take a good 30 years before we can manufacture RAM sticks that pack enough density that you could hit the 64bit addressing limit without requireing thousands of sticks. With the explosion of hard drive space on the other hand hitting the 64bit limit in large clusters is certainly possible in the near future. Therefor it makes sense that since MSFT does have several server products, and servers are requiring ever increasing amounts of space, that MSFT would have a team working on 128bit file system support for a later version of Winserver. You really don't need to be Colombo to come to that conclusion, as it just makes sense, whereas a full 128bit OS simply does not and will not make sense for most likely several decades. And while we all know MSFT is slow when it comes to releasing OSes, surely they won't be THAT slow when it comes to Win8 and Win9.
ACs don't waste your time replying, your posts are never seen by me.
Microsoft Research does a LOT of this type of investigation and research. However, there is a world of difference between researching compatability and 'planning to add'. Whether or not he really works for Microsoft, the claim that he is in R&D makes the claim that Win8 will provide 128 bit support a major stretch. Very misleading headline.
Yeah, I think I remember him. He thought the Internet was a passing fad, claimed he'd single-handedly defeat spam, promised Microsoft was taking security seriously in 2000, all kinds of nonsense like that. Had a really dorky haircut too.
You are in a maze of twisty little passages, all alike.
I'm still confused.
What's the point of having 128 bit compatibility? 128 bit CPUs don't even exist yet. Heck most of us are still just using 32, and haven't even visited the 64 generation yet.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
PAE doesn't "hide" memory, really. You can only address 4GB (i.e. a 32-bit address space) of virtual memory at once but that can be *anywhere* across the 36-bit physical address space. As long as no individual app needs more than 4GB of memory you're (mostly) OK. The kernel can alter the mappings as it needs to poke at anywhere interesting in all of physical RAM. It's less efficient than mapping it all in at once but you can manage quite well.
How quickly we forget!
The original 8086 processor could address 1 megabyte of memory (20 bits) with a 16 bit processor. It used two registers (one shifted left by four bits) to address memory.
A 64 bit processor could trivially access a 128-bit address space by using the same segment:offset method.
Remember, You are unique...just like everyone else.
I once read that it took us 30 years to figure out 8 bits then about 5 years to exhaust the abilities of 8 bits so we moved to 16bits which we exhausted in 10 years so we moved to 32bits which took us about 20+ years (this post written on a 32 bit machine which has thus far been far more reliable than the wife's 64 bit machines) to exhaust so following this logic it will take us 40+ years to exhaust 64bits. Does this then mean I can expect Windows 8 in about 2050?
Let me guess: you've never written any ring 0 code for x86. PAE doesn't hide the memory. It modifies the page table structure slightly (so does 64-bit, by the way, it makes the page tables deeper which makes every TLB fault slower). You have a 32-bit virtual address space and a 36-bit physical address space. No process can see more than 4GB of RAM, but if you have two processes then they can each see a different 4GB of physical RAM. None of my processes currently uses more than 760MB of address space, but I have 3GB of RAM and 3GB of swap used, so with a PAE system and 8GB of RAM each process would be using physical memory and I'd have 2GB for filesystem cache.
Oh, and when people talk about PAE, they also often mean PAE or PSE. PSE just makes pages bigger (up to 4MB), which can be used to address 64GB of RAM without changing the size of the page tables. This is better in some situations, because it involves smaller page tables and fewer TLB faults, but it means that you are swapping 4MB at a time, which can be very slow if you are swapping a lot.
I am TheRaven on Soylent News
The discovery came to light after FORMER Microsoft Research employee Robert Morgan carelessly left details of his work...
According to Wikipedia
http://en.wikipedia.org/wiki/Glenndale_University
this University isn't even accredited!!
Maybe they mean optimizing windows kernel using SSE2 instructions (xmm registers are 128-bit wide)? It improves performance of many memory transfers, and currently and makes a lot of sense in quite a lot of applications - even the kernel itself.
The original IBM System 38 and its descendants, such as OS/400, OS/500, etc., had a 128-bit address space. In these architectures, the large number of address bits were used to provide an address space that spanned both memory and disks and was used to provide processor-level protection for objects stored there. Using large address spaces to ensure hardware protection of system objects is a good start on a highly secure OS and is probably where this is going.
And Intel is no stranger to hardware object protection, either. The iAPX-432 chipset, although not a commercial success, showed that hardware-level protection of objects is feasible, with more complex access controls than can be provided with reasonable performance than with software implementations of complex access control schemes (note I said complex - one of the reasons that the chip failed commercially is that, besides having a braindead two-chip implementation and instruction lengths that varied at the bit level, it could not support simple protection schemes as quickly as software was able to do). Intel is looking for what to do with the extra transistors that feature shrinks provide - adding better protection at the hardware level might be a win.
That is all.
Not too long ago (15-20 years, maybe?) 64-bit processors would have been unheard of on the desktop. I see 64-bit being stretched as we put more high-definition video into our datasets. And then we'll have the next "ultra high def" format that will stretch it even more. And then you have a small (in terms of units shipped), but very profitable business in supercomputing. Protein folding and subatomic research folks would probably jump at the chance to rerun their simulations with a higher resolution.
Remember, You are unique...just like everyone else.
Even the most wasteful of Stupid Virtual Memory Tricks aren't going to put a lot of pressure on 64-bit addressing any time soon.
You heard it here first, folks: 64-bit ought to be enough for anybody.
I only post comments when someone on the internet is wrong.
Shared memory space among lots of computers, using IP (possibly IPv6) as a protocol.
That's probably what they are referring to if they mean 128 bit address space (not datapath).
You don't need 128 bits for addressing. 2^32 is "only" 4 gigabytes, which was always achievable in theory and actually achieved in practice over a decade ago.
Having a memory — RAM or disk — above 2^64, however, is not achievable in even in theory... 2^64 is only 100 times less, for example, than the estimated number of sand-grains on Earth.
Being able to process as much as 128 bits in one CPU-instruction is nice, and SSE extensions allow that. But neither size_t nor off_t need to exceed 64 bits. Ever... In fact, in the amd64 instruction set, only 48 bits can be used to address memory — the rest are for the CPU instruction, so that both the operation and the operand fit in one 64-bit word. The amd64-architecture is thus "limited" to 256 TB — that's the largest RAM an amd64-machine can have and the largest file and amd64-machine can mmap.
64-bit systems were truly useful, because — by making size_t and off_t the same, they allowed software to be rid of having to segment access to files, which could, potentially, be too large to memory-map in their entirety (many legacy mmap-implementations are still limited to 2- or 4-Gb files). 128-bit systems are not adding that benefit...
(And, of course, most systems — including even the most modern Linux and BSD — still have rather poor mmap-implementations, compared to their highly-optimized read and write calls... But that's another topic...)
In Soviet Washington the swamp drains you.
The senior researcher's profile said he was: "Working in high security department [emphasis mine] for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
My first reaction was that if you can't fix the security problems in the people, you surely can't expect to fix the security problems in the software. But that might be a little hasty.
My guess is that the actual security gaffe here was little or nothing. He mentioned he worked in this department, and that they have future plans that exceed today's capabilities. Meh. So what. If he had posted the details of what he was doing, then it would have been newsworthy. As it is, this barely notable. Any one of us here could probably guess that MS likely has people looking into the progression beyond 64 bit technology.
It is reasonable to believe that at some point in the next several years the hardware companies he mentions will have some plan to start building 128 bit cpus. My guess is that this guy's job is to make sure that MS has input into the design process where it can, and to provide feedback to the MS dev teams so MS can start planning to include compatibility features relatively early on, to hopefully be the OS of choice when this hardware someday becomes available. I'm guessing that Windows 8 probably won't be seen for a long time. The article mentions 2012, but given MS's rush to push out 7 to stem the bleeding caused by Vista they may rely on it for longer than normal, much like they did with XP after the ME debacle. If I were writing an OS that would likely debut in 4 to 8 years, I would probably want a heads up from the hardware vendors about how to write an OS for their next gen proc. Also, if MS were planning a future move to a fully 128-bit OS, they might start by inserting 128-bit code into a 64-bit OS.
I prefer rogues to imbeciles because they sometimes take a rest.
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
Since Win8 / Win9 won't be out for 5/10 years...
Why am I getting flashbacks to a discussion that people had back in the 8 bit days?
"Making the entire os 32-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.) ... Having 32 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines."
I never heard this discussion, but you know it happened. Probably almost verbatim.
I'm still confused.
What's the point of having 128 bit compatibility? 128 bit CPUs don't even exist yet. Heck most of us are still just using 32, and haven't even visited the 64 generation yet.
Maybe because it's easier to include now the ability to extend compatibility to 128-bit processors instead of trying to bolt it on later? Who knows, maybe Microsoft really did learn something from their experience with Windows security.
He's right, there's no Robert Morgan here (well, there's a v-, but no Robert Morgan in R&D).
Not too long ago (15-20 years, maybe?) 64-bit processors would have been unheard of on the desktop. I see 64-bit being stretched as we put more high-definition video into our datasets. And then we'll have the next "ultra high def" format that will stretch it even more. And then you have a small (in terms of units shipped), but very profitable business in supercomputing. Protein folding and subatomic research folks would probably jump at the chance to rerun their simulations with a higher resolution.
Just to put this into perspective, the forthcoming IBM Sequoia supercomputer will have 1.6 petabytes of RAM, and only a very small fraction of this can be accessed by a single compute node. The total amount of RAM in this machine is still 4 orders of magnitude smaller than what can be addressed with a single 64-bit pointer.
Well, 16 Exabytes of RAM (ok, just 8 if you use signed relative jumps) ought to be enough for a quite long time. Long enough to develop another OS, that is for sure.
Rethinking email
How quickly we forget!
Writing code to use 'near' and 'far' pointers was a constant headache, of the same magnitude of C++'s requirement that you be constantly aware of character width when manipulating strings.
FATMOUSE + YOU = FATMOUSE
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Right. There's no widely-used 128-bit-native processor architecture either. And there is no reason to have 128-bit address bus either.
I don't think there are 2^128 bytes of DRAM on the planet, even. Lessee... that's 2^98 GiB. Which is almost 10^20 GiB of RAM for every single person on the planet. I think that I personally can account for 10 GiB or so. Maybe 100 GiB if my parents have a secret DRAM trust fund for me that I don't know about. So yeah, 128-bit memory addresses are waaaaay off. I believe current 64-bit processors are currently limited to 40-bit external address buses... that'd be 1 TiB of RAM.
My bicyles
No, it means a 128-bit architecture will still be able to run Windows 8.
That is, the architecture supports a different mode that the Windows 8 kernel includes.
Knowing the history of teh bits, this simply means Windows 8 will be available in both 32-bit and 64-bit versions, and 128-bit processors will be able to run in 32-bit mode, but not 64-bit mode.
So yet again, we will be stuck without 64-bit drivers or optimization, let alone 128-bit drivers or optimization.
32-bits should be more than enough for anybody.
(I HOPE Windows 8 is 64/128, and 128-bit processors are 32/64/128, but I know better than to expect anything sensible).
Somehow, we all managed to survive from 1984 to 1995 by swapping 64k chunks in Expanded Memory. I remember writing assembly to do it, and I personally do not miss that headache. That being said, old ideas die hard, and if we can get some larger page sizes (how about swapping that 4th GB in address space to point at a 5th, 6th, etc?), almost all reasonable applications (by today's standards) could fit in the expanded memory space.
In these architectures, the large number of address bits were used to provide an address space that spanned both memory and disks and was used to provide processor-level protection for objects stored there. Using large address spaces to ensure hardware protection of system objects is a good start on a highly secure OS and is probably where this is going.
But, even 64 bits is enough for that for a long time.
Since you can address over 17 billion terabytes with 64 bits, that means that even with a doubling of storage density every year (which is much faster than things are really happening), that means we have over 20 years before arrays of a couple thousand disks would start to reach the limit.
By then, there will be 128-bit CPUs. So, unless Windows 8 is targeted for 2020, it really doesn't need any 128-bit features.
For the uninitiated, v- and a- are Microsoft's way of identifying vendors (Microsoft is their client for whatever reason) and CSGs respectively (a fancy acronym for contractors).
You realize that we are at the end of 2009 right? And that Windows 7 is just now being released? MS might just be considering that in 2020 we might still be running Windows 8. I know that only looking 1Q into the future is hip for businesses, but maybe MS is looking farther ahead than that. We are still living with issues created by PC limitations from the 16-bit era. Probably a bunch from the 8-bit era that I am not aware of. I see no problem with planning ahead so that they can get the transition done sooner rather than later, or just make the transition smoother than previous bit size transitions.
Having a memory — RAM or disk — above 2^64, however, is not achievable in even in theory... 2^64 is only 100 times less, for example, than the estimated number of sand-grains on Earth
So? There are more efficient encodings than one byte per sand-grain, you know.
As it turns out, 2^64 is much smaller than Avogadro's Number, the number of molecules in a mole of a chemical compound. If you could find a way to encode information in a 3D hunk of silicon, such that you needed slightly more than 1000 atoms to store each byte, 2^64 bytes of storage would amount to a bit less than one ounce of bulk silicon, occupying less than one cubic inch.
I FULLY expect to see secondary storage approaching this density within the next few decades, and I fully expect that there will be good reasons to support it in a flat address space.
Itanium is not unsuccessful for VMS machines (you cannot put VMS on an x86 based chip, 64bit or no), and VMS is used in mainframe and other ultra-high availability applications. The Itanium just didn't pan out for any sort of windows-based operating systems, because windows is so tied to its x86 legacy.
I believe they also have a successor that will be compatible with Itanium as well, I'm not sure though. I mainly only looked at Itanium from the VMS point of view. They certainly have a future their though, their only competitor is the Alpha by HP, and these tend to be very very very expensive applications they are used for.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
No, IBM never produced an "OS 500". The branding went from OS/400 to i5/OS to today's "IBM i".
No, the system never had a 128-bit address space. The address space of OS400 went from 48-bit to 64-bit when IBM started using 64-bit Power-based processors in those systems.
Yes, the instruction set uses 128-bit pointers, but only the rightmost 64 bits of the pointer are used in the current system.
Yes, The 64-bit address space covers both system memory and disk storage.
This Wikipedia article about IBM System i is a pretty good reference about this kind of stuff.
The x86 line permits chaining of basic binary arithmetic operations to any level of complexity. However, why would we want 128-bit operands? Double precision arithmetic is 64-bits, and there isn't a significant clamor for more precision in scientific circles. (More speed = yes, Vector Operations = yes, More precision = no).
Computer hardware has supported wider data buses than CPU bus widths for some time now. Wide data buses are useful for vector operations, and to quickly fill CPU caches. Nvidia has a 512-bit GPU. I think IBM has at least experimented with 512-bits for the Power Platform. Currently, an external data bus wider than 128 bits remains expensive. However, internal to the CPU, the Core i7 processor uses cache line widths of 128-bits and 256-bits, so someone might argue the Core i7 is a 256-bit processor. In the past, Intel has adopted misleading marketing practices with regarding data bus sizes.
Programmers care about the unit word size for key operations. 64-bits is likely to be sufficient for all practical uses for some time now, particularly for PC usage. Essentially, a 64-bit processor can directly address 18 exa-bytes of hard drive storage to the byte level. Barring massive breakthroughs, for the near future, multi-exabyte supercomputers/compute clusters will be scarce.
Additionally, 1 exa-byte of storage is only useful in a cluster. At a 10 GB/sec (80 Gb/sec), which is faster than pretty much any single storage device currently in existence, it takes 3 years to move 1 Exabyte of data. That's a long time to back up a hard drive. Even DDR-3 2000 RAM requires multiple devices to reach 10 GB/sec transfer rates, and who wants 3 years worth of data sitting in RAM? As such, 64-bit addressing is only useful in the context of supercomputers/compute clusters that have the massive parallelism required to read and write Exabytes of data quickly.
If Microsoft expects serious personal computer uses for 128-bit addressing by the time Windows 9 ships, Microsoft must be planning on Windows 9 shipping sometime next century.
The original 8086 processor could address 1 megabyte of memory (20 bits) with a 16 bit processor. It used two registers (one shifted left by four bits) to address memory.
Have you ever programmed in that model?
Having pointers split into segment:offset pairs meant that you couldn't (easily) have a single array span more than 64kB. Any program that needed to access arrays above that had to split its arrays into arrays of arrays, each of which was smaller. Fun, fun, fun.
A 64 bit processor could trivially access a 128-bit address space by using the same segment:offset method.
I'll let you do the programming, this time. I'll stick to the flat memory model of today's architectures, if that's all right with you.
From Windows IT Pro: "All your rumors are belong to me: Windows 8 to be 128-bit? No. Good God, no. People can be so silly sometimes. Writers at PC World, Ars Technica, Slashdot and many other publications fell for an obviously faked LinkedIn profile from a supposed Microsoft researcher who claimed he was working on a 128-bit kernel for Windows 8. There's just one problem. This guy doesn't exist. No one with his name has ever worked at Microsoft Research. His job title is fake. Microsoft is not working on a 128-bit kernel for Windows 8. And, best of all, the guy's listed university? It's an "online supplier of academic degrees," according to Wikipedia. OK, that's five problems, or four more than those geniuses on the web should have needed to figure out this rumor was fake. Seriously, you guys make me laugh so hard sometimes I could cry. It's just sad." http://windowsitpro.com/Articles/Index.cfm?ArticleID=102939&feed=rss&subj=0