| Date: | August 1, 2007 / year-entry #280 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070801-00/?p=25763 |
| Comments: | 37 |
| Summary: | A long-forgotten footnote in Win32 history is the set of functions known as "VLM" for "Very large Memory". To understand VLM, you first need to understand the Alpha AXP. The Alpha AXP was a wonderful architecture and I was sad to see it go. Partly because it meant that the years I spent learning the... |
A long-forgotten footnote in Win32 history is the set of functions known as "VLM" for "Very large Memory". To understand VLM, you first need to understand the Alpha AXP. The Alpha AXP was a wonderful architecture and I was sad to see it go. Partly because it meant that the years I spent learning the ins and outs of the processor were now just wasted space in my brain, good only for muttering incoherently during meetings and blog entries. Hang on a second... The Alpha AXP was a 64-bit processor. None of this "64-bit mode" versus "32-bit mode" that we have with the AMD64 and EM64T (and early versions of the Itanium). It was 64-bit all the time. Now, the instruction set did provide a few arithmetic instructions which operated on 32-bit values, but the results were always sign-extended back up to 64 bits. This one concession to 32-bit code meant that you could run code that was conceptually 32-bit on this 64-bit CPU: All the operating system has to do is treat the 32-bit addresses 0x00000000 through 0x7FFFFFFF as 64-bit addresses 0x00000000`00000000 through 0x00000000`7FFFFFFF, and treat 32-bit addresses 0x80000000 through 0xFFFFFFFF as 64-bit addresses 0xFFFFFFFF`80000000 through 0xFFFFFFFF`FFFFFFFF, The processor's natural sign extension did the rest. (And now you can see another reason why there is a no-man's land around the 2GB boundary. If objects were allowed to cross the 2GB boundary, they would end up being split up when converted to the Alpha AXP's 64-bit address space.) This is sort of analogous to running 16-bit Windows programs on an 80386 processor. Your 16-bit program could still use those 32-bit registers if it only knew they were there. This clever design of the Alpha AXP meant that you could read through quite a bit of Alpha AXP assembly language without being able to tell whether the code was designed as 32-bit or 64-bit code since it all looked the same. The only giveaway would be when the code loaded a pointer from memory. Anyway, back to VLM. Windows NT on an Alpha AXP was a 32-bit operating system on a 64-bit processor. The 32-bit address space was only a tiny fraction of the full 64-bit address space available to the processor. And VLM gave you access to that space that would otherwise go wasted. You allocated memory in the 64-bit address space with functions like In addition to allocating memory, there were special functions for memory-mapping a file into the 64-bit address space and performing disk I/O into and out of these 64-bit addresses. But that's about it. The rest of Win32 still used 32-bit pointers, so you couldn't pass these 64-bit addresses to functions like These functions were designed for high-end database programs which required enormous quantities of memory and (more importantly) address space. The memory wasn't pageable because high-end database programs invariably perform their own highly specialized memory management, and paging just gets in the way. With the death of the Alpha AXP also came the death of VLM, since the Alpha AXP was the only architecture that supported 64-bit addresses in 32-bit code. This model of programming is not dead, however. It was seen in Windows 3.1 with the |
Comments (37)
Comments are closed. |
Ah, the good old days. Many years ago even before Alpha VMS was released, I was tasked with converting our SCADA system from VAX/VMS to the Alpha. This included some assembly and even some system level code. I think I used a pre-release DEC 5100. Compiled very fast but the link times where horrible.
I really enjoyed that processor. Dealing with the 32bit to 64bit and back conversions were a LOT simpler than people might think.
Awesome post, Raymond. Thanks. :)
and despite the death of Alpha, at least 1/3 of academic papers in computer architecture still use a really old version of an Alpha simulator for their research. Another 1/3 use MIPS. It makes you wonder.
If you still have any old Alpha hardware kicking around you can run modern versions of Linux on it. I have an Alpha around running the newest version of debian-unstable. Fully 64 bits too, none of this "32 bit OS on a 64-bit architecture" nonsense.
"at least 1/3 of academic papers in computer architecture still use a really old version of an Alpha simulator"
Probably for the same reasons that medieval scholars of sundry native tongues communicated in Latin.
(.) Both are fully specified and accessable to serious students.
(.) Neither is in living, daily use, so there are no natural forces operating to evolve them.
(.) Both arose from powerful traditions, developed by races famous for practicality.
(.) Both are robust, rich, complete, and tested by extensive use.
(.) Both possess a certain austere beauty for those who can appreciate such things.
Of course, the analogy must fail at some point. For example, middle school pupils are not commonly tortured with irregular Alpha noun declensions.
-Wang-Lo.
As I’m not that familiar with 64-bit architectures and related things, I’m wondering why the AXP doesn’t map 32-bit space completely to 0x00000000
00000000 through 0x00000000FFFFFFFF ? Anyone can explain that to me?It was already explained:
"Now, the instruction set did provide a few arithmetic instructions which operated on 32-bit values, but the results were always sign-extended back up to 64 bits"
Raymond, I’m so proud of you! You made it through an entire technical post without kowtowing to the nitpickers.
Interesting post, thanks Raymond!
Does anybody know of an app that used VLM (besides SQL Server or Oracle)?
Great post Raymond.
What a coincidence, I was just looking back at some alpha papers. I remember extending Excel on Alpha having some problems with parameters on the stack, it was a beast on net I/O too.. Heck was it Citrix that ran on it too so some serious precursor to terminal services must have been developed too.
And those VLM extensions now the total flashback occured, back then I was under impression those were meant for other architectures not only alpha. Despite it being immediatelly usable I guess and those boxes looked mean (both 300Mhz and 500Mhz version), they had some serious backplanes, some weird silver alien s*t inside :-), I am interested whether Itanium was around at that time (1998?)?
Mmm, alpha…
We coded our kernel on alphas in our OS class at Comp. science. Good times. :)
Very nice architecture indeed.
Itanium wasnt around at that time, IIRC it is a loose descendant of Alpha created after DEC disappeared and Intel ended up with some of DEC’s processor IP.
I studied Alpha AXP a little, a long time ago. I remember being impressed by the clean architecture, fixed-width instructions, integrated FPU (hey, I’m a PC man), and especially the fact it had exactly *one* privileged opcode (call_pal, which would call into the firmware, itself written in PALcode, a privileged form of AXP binary code) – this makes the AXP almost trivial to virtualize/emulate. It should not come as a surprise that so much innovative academic work, e.g. binary-to-binary compilers, was based on the AXP
Oliver: The problem with that is then you end up with negative 32 bit numbers mapping to positive 64 bit ones. By sign-extending it instead, all the positive/negative, addition/subtraction and overflow operations operate as expected. It also stops any genuine 64 bit apps getting upset about having a kernel 2Gb into their address space, instead of at the top in its own half. Why complicate the address map by having two distinct userspace areas with the kernel in between, when you could have a single dividing line instead?
I never owned one myself, but did like the idea of an Alpha; I remember the Multia being quite popular for hobbyists at one time (including being the original platform for Slashdot!), but Ebay doesn’t have any at the moment AFAICS.
"This is sort of analogous to running 16-bit Windows programs on an 80386 processor. Your 16-bit program could still use those 32-bit registers if it only knew they were there."
Closer still, in fact: the "16 bit" registers we see on 386 and later systems (AX/BX/CX etc) are the bottom half of the 32 bit variants, (EAX/EBX/ECX…) – it *is* using them, just ignoring the top half thereof, just as you do on AXP with the bottom 32 of the 64 bits. Or you get get into a whole world of pain mixing x87 floating point operations with MMX, since Intel’s implementation ‘recycled’ the same physical registers for both functions…
There’s also "unreal mode" (32 bit memory access from 16 bit code) – which sounds superficially similar to WINMEM32, but I can’t find any information on the latter at the moment.
I wonder why Microsoft didn’t release a 64 bit Windows on Alpha or Mips? You can see they had it running internally for ages. Look at the machine types in PE executable files – IMAGE_FILE_MACHINE_ALPHA64 has been around in various SDKs and DDKs for ages.
It seems like if you’re going to port a medium size application to a Risc platform it’s not that much harder to go from 32 bit to 64 bit. In a twisted sort of way, the sort of people that port to Risc would probably like the challenge of porting to 64 bit.
And even if no one bought it seems like it would be good as scalability demonstration, which was all the 32 bit Risc ports of NT 4.0 or Windows XP x64 for that matter ended up being.
What if Win2000 was actually released for the Alpha? Because by the time the Alpha was dropped, Win2000 was close to release.
@Wang-Lo
"developed by races famous for practicality."
Latin = Italians, Alpha = Americans?
FYI Americans get antsy when people talk about race. Especially bloody foreigners ;-)
@Jonathan Wilson
"Itanium wasnt around at that time, IIRC it is a loose descendant of Alpha created after DEC disappeared and Intel ended up with some of DEC’s processor IP."
More like the red headed illegitimate child.
In fact, how about trying to build the final version of Windows 2000 for the DEC Alpha?
IIRC, the reason that Windows 2000/Alpha64 was never released was simply that Compaq (who’d bought out DEC) decided not to support it. With only a single OEM customer, and that customer deciding to drop support, it wasn’t economical to continue.
64-bit Windows on Alpha continued to be developed and used internally as a ‘mule’ (to use the car maker term) to validate the 64-bit concepts while Intel got working Itanium silicon going (IA-64 having been in the works as a joint venture with HP since 1994). I seem to remember they were still used as build machines inside Microsoft until quite recently (still outperforming x86s!)
The first commercially-released 64-bit version of Windows was "Windows Advanced Server, Limited Edition" in 2001 (for Itanium). It couldn’t really be called either Windows 2000 nor Windows Server 2003 – it landed in an awkward time frame around about the Windows XP launch, before the Windows Server 2003 security push that delayed that product a further year. There was also an Itanium version of Windows XP intended for use on workstations, but the hardware ended up being too expensive for most people.
Itanium still has a performance-per-clock lead, particularly in floating-point, even over Core 2/Xeon, but clock rates have never even approached x86, which regained the integer lead a while back (actually AMD Opterons rather than Intels). The Itanium 2 currently tops out at 1.6GHz on 533MHz FSB, while the fastest Core 2-based Xeon, model 5160, runs at 3.0GHz on a 1333MHz FSB. The Itanium is more efficient than the Xeon, in performance per clock, but it’s not twice as efficient. Itaniums do have more on-board cache, though, at 12MB rather than the Xeon’s 4MB (2x4MB in the case of the quad-core 53xx series – this is basically two Core 2 Duo cores in the same package) which might be beneficial in some applications.
… the WINMEM32 library … even let you create 32-bit code segments!
I read somewhere that Windows 3.11 GDI just turned its own code segments from 16-bit to 32-bit. As I recall, it used xor ax, ax; mov ah, 0x80; add ax, ax; to test whether it was still in 16 bit mode (the carry flag would be set).
Nothing quite like entrenching doing things the wrong way.
Also: technically, 64-bit pointers are still supported (see PVOID64), but they are just an artificial compiler construct to define data structures that are binary-compatible between 32 and 64 bit. Similarly, PVOID32 is a pointer that’s always 32 bits in width, regardless of architecture
It’s moments like this that make me sick to my stomach that I skipped all those days in my assembly language class.
Sigh.
Great post, Mr. Chen, thank you!!
JamesNT
James: "unreal" mode, if I remember correctly, is a *bug* in the x86 that was exploited, among others, by Ultima 7. The trick is that segment descriptors and selectors are just shadows of internal MMU registers – unless the corresponding selector registers are overwritten explicitely, the internal registers they map to will remain unchanged. The official documentation states that you need to reload segments before returning to real mode, but it turns out it’s not necessary in practice
In fact the last Win2k Alpha build was 2128:
http://www.alphant.com/articles/windows2000.html
In fact, how about building the final build 2195 of Win2k for Alpha to show how much Alpha is remaining in that build and for running on the remaining Alpha systems and to try out VLM?
Raymond, is that the reason why Windows still uses SIGNED pointers today?
By the way Raymond, he didn’t mean you should personally build it, but that the Microsoft should do it, (probably as a gesture of a good will and for historical reasons) and without support obligation since even Windows 2000 is on the verge of being an unsupported OS.
Indeed, I am not asking MS to build XP or later for Alpha, which would make no sense.
I don’t have an Alpha, BTW, but there are those who have them.
BTW, it is quite sad that the Alpha was dropped that close to RTM.
I can see where that comment is coming from having heard that Cutler did provide a 64bit port very early in the days and that 5.0 was a primary target around that timeframe.
So either Itanium was around or Alpha was very close to a 5.0 build. I would guess the latter just because of historical links, and hey how far could a 5.1 build be from it :-)
However, I agree it is pointless, better to put a Linux piece on it and have fun.
Anyway, does anyone know the details of that DEC IP that got shifted to Intel for Itanium? Would appreciated any links too, reason being I have heard stories that some of it is relevant to their competition with AMD but nothing concrete on it.
Cheers.
And while on rumours, don’t know where to verify this, someone else reminded me the other day again that Vista aka 6.0 was dropped after a two year work on old 5.1 trunk, one of the reasons being first ever?? adoption of C++ for the implementation.
Pitty there is still no thin equivalent or answer to Linux and who knows it might be screwed up with 2008 Core Server attempt. For one there is not enough samples and very little on new/old cryptography and I/O. Without more of it, the open source will be an alternative for all architectures until 2012 at least.
Apologies to Raymond if this is an inappropriate place or topic but any details/pointers on the above greatly appreciated.
Many people don’t realize that the non x86 versions of Windows NT 4.0 (Alpha and MIPS) would run x86 code in an emulator (in this case a virtualized i486). To improve performance, DEC released their own Intel-to-Alpha emulator & translator called FX!32 which would attempt to convert as much code x86 as possible to native Alpha. What’s really interesting is that it would optimize itself each time the user would run an executable. So the first time a program was run, it would mostly be emulated but every subsequent run would convert more of the code. After several runs, the majority of the program would be native code. I wonder if this approach would be viable under WoW64?
Full article (about half-way down) here: http://www.windowsitlibrary.com/Content/435/06/4.html
R.I.P. DEC. Yet another innovative company brought down by inept management and the wish of a competitor to buy out and dismember a rival.
I seem to recall that one, it was a service no?, and seeing that Slashdot and Don is pushing for women in IT topic, I believe it was a woman behind it (from a team of two) behind FX.