Is NT on DEC's Alpha AXP 32- or 64-bit?
Bruce Ediger
[please note follow-ups: they're probably more appropriate for the
[inevitable misinformed, poorly spelled flamage]
The issue of whether Windows NT as ported to the DEC Alpha AXP CPU
is "32 bit" or "64 bit" is a fairly instructive argument. First,
you have to decide what "32 bit" and "64 bit" mean, which is complicated
by the ugly 80x86 Intel instruction set. Then, you have to scrounge for
the information that will allow you to decide based on the definitions
you decided on for "32 bit" and "64 bit".
I present some information I found on the topic.
First, an article on how DEC ported VMS from VAX to Alpha AXP. This is
relevant because NT on the x86 and Mips CPUs uses exactly the same memory
layout as VMS on the VAX. DEC programmers also did the NT port to Alpha
AXP. Perhaps some insight can be gleaned by comparing the docs describing
the two ports.
Digital Technical Journal Vol. 4 No. 4 Special Issue 1992
"Porting OpenVMS From VAX to Alpha AXP"
Nancy P. Kronenberg, Thomas R. Benson, Wayne M. Cardoza,
Ravindran Jagannathan, and Benjamin J. Thomas III
<URL:http://www.digital.com:80/.i/info/DTJ807/DTJ807SC.TXT>
The first two paragraphs of this article are very instructive:
The VAX architecture is 32-bit; it has 32 bits of virtual address space,
16 32-bit registers, and a comprehensive set of byte, word (16-bit), and
longword (32-bit) instructions. The Alpha AXP architecture is 64-bit,
with 64 bits of virtual address space, 64-bit registers (32 integer and 32
floating-point), and instructions that load, store, and operate on 64-bit
quantities. There are also longword load, store, and operate instructions,
and a canonical sign-extended form for a longword in a 64-bit register.
The OpenVMS AXP system has anticipated evolution from 32-bit address
space size to 64-bit address space by changing to a page table format that
supports large address space. However, the OpenVMS software assumes that
an address is the same size as a longword integer. The same assumption
can exist in applications. Therefore, the first version of the OpenVMS AXP
system supports 32-bit address space only.
Immediately, the authors sum up the architectural differences between the
VAX and Alpha AXP instruction sets that will have an impact on the port of
VMS. The final sentence of the second paragraph gives the effect of these
differences on the VMS port to the Alpha AXP. This is clear, concise
writing. It also gives you the answer to the question of how DEC ported
its flagship OS to its new CPU.
Note that there is no quibbling, no prevarication, no waffling about the
issue of the meanings of "32 bit" and "64 bit". This is probably due to
the fact that both VAX and Alpha AXP instruction sets DO NOT use segmentation
to describe an address. My contention that this article is relevant
is confirmed by the fact that the VAX has the same 16-bit word, 32-bit
doubleword sort of orientation that the x86 architecture has.
Next, the only article I could find that seemed to address the real question,
"Is NT on the Alpha 32- or 64-bit?"
DECUS Journal, Fall 1994
"Porting Windows NT to the Alpha AXP Architecture"
Steven M. Jenness, Benn L. Schreiber, Thomas Van Baak
<URL:http://www.decus.org/decus/pubs/decusf94/window.html>
Here are the first two paragraphs of the DECUS Journal article:
Porting and Developing - Working Concurrently
Porting an operating system is usually done against a reasonably stable
code base. Developers take a snapshot of the code and move it to the
new platform or architecture. Then support for the platform is
integrated directly into the source code. Digital and Microsoft took a
different approach to porting Windows NT onto the Alpha AXP
architecture. The port was done while the initial release of Windows NT
was still being developed. Under these circumstances, Digital and
Microsoft had to cooperate very closely to minimize the impact of the
ongoing change. The technical and project-management challenges were
tremendous, but the result was complete Windows NT support for the
Alpha AXP architecture.
Windows NT Port Project Goals
The goals of porting to the Alpha AXP architecture were
straightforward: Provide complete integration of Alpha AXP support into
hardware-independent components of the operating system, as well as
applications, across all Alpha AXP platforms Include the support for
Alpha AXP on the first release of the Microsoft Windows NT CD-ROM
Great. Discussion of management issues and marketing goals. The rest of
the article carries through with this sort of propagandistic puffery.
To be sure, there are some paragraphs about portability issues, ones
that were encountered and ones that weren't, but even those discussions
are clouded with non-issue items like how byte order issues weren't a
portability problem.
Naturally one wouldn't expect byte order issues in a port of a little-endian
program to a little-endian processor. If they'd ported NT to a big-endian
CPU and not encountered a byte-ordering problem, that would be something to
crow about. As it is, items like "no byte order problems" are the purest
form of space filling.
The writers of the DECUS Journal article assert that porting an x86 NT
app to Alpha AXP NT is just a matter of recompiling, even for things as
complicated by device drivers. This is immediately refuted by the direct
experience of others, as illustrated in
<URL:http://www.byte.com/art/9404/sec8/art6.htm>
Note that BYTE is still so hung up on MS-DOS stuff that they continue to use
3-letter extensions even in 1994.
All-in-all, the Digital Tech Journal article is a good paper, the DECUS
Journal article isn't, and it doesn't resolve the 32 vs 64 bit issue at
all. Why the heck not? Because the DECUS Journal article is a piece of
propaganda that allows only a few facts to peek through. The Digital
Tech Journal article is an article about engineering, not about sales
and marketing.
Old-Fashioned Staffordshire Plate...
In article <5310su$9...@teal.csn.net>, bed...@csn.net (Bruce Ediger) writes...
>The issue of whether Windows NT as ported to the DEC Alpha AXP CPU
>is "32 bit" or "64 bit" is a fairly instructive argument. First,
>you have to decide what "32 bit" and "64 bit" mean, which is complicated
>by the ugly 80x86 Intel instruction set.
Heh, It never was complicated before the 'technological revolution' of the
intel pc. When you have a flat addressing model it's quite clear: how much
virtual address space can you directly access?
> can exist in applications. Therefore, the first version of the OpenVMS AXP
> system supports 32-bit address space only.
>
>Immediately, the authors sum up the architectural differences between the
>VAX and Alpha AXP instruction sets that will have an impact on the port of
>VMS. The final sentence of the second paragraph gives the effect of these
>differences on the VMS port to the Alpha AXP. This is clear, concise
>writing. It also gives you the answer to the question of how DEC ported
>its flagship OS to its new CPU.
FYI, VMS now (V 7.0) IS 64 bit capable, that is, the system service interfaces
support memory regions virtually addressed by a 64 bit quantity, but I think
the lower level memory management can really physically (not sure on this)
address only what the current alpha processors have implemented, which I
believe is 43 bits (which is still a hell of a lot of physical memory).
>Next, the only article I could find that seemed to address the real question,
>"Is NT on the Alpha 32- or 64-bit?"
>Great. Discussion of management issues and marketing goals. The rest of
>the article carries through with this sort of propagandistic puffery.
Maybe this is because the two article's target audiences were different (nudge
nudge, wink wink).
>Naturally one wouldn't expect byte order issues in a port of a little-endian
>program to a little-endian processor. If they'd ported NT to a big-endian
>CPU and not encountered a byte-ordering problem, that would be something to
>crow about. As it is, items like "no byte order problems" are the purest
>form of space filling.
The AXP chip can do both byte orderings.
><URL:http://www.byte.com/art/9404/sec8/art6.htm>
>
>Note that BYTE is still so hung up on MS-DOS stuff that they continue to use
>3-letter extensions even in 1994.
JA! Whenever I see .htm it makes me think of that 'would you please pass the
jelly' commercial. Why don't they get just get an 'I love bill gates' valentine
tatooed on their virtual forehead? That article could have come right out of
computerworld! The people they talked to (e.g. George Krucik) were obvious bill
gates apologists who were 'praising bill gates with faint damnation', if you
ask me. They were bummed any problems happened because they wanted to use bill
gates so bad and stop doing those pesky unix ports. Fucking running yellow dogs
of the monopoly. Willing dupes of bg.
[64 v 32 not answered...]
>Why the heck not? Because the DECUS Journal article is a piece of
>propaganda that allows only a few facts to peek through. The Digital
>Tech Journal article is an article about engineering, not about sales
>and marketing.
Aye.
Tom O'Toole - ecf_...@jhuvms.hcf.jhu.edu - tom.o...@jhu.edu
JHUVMS system programmer - http://jhuvms.hcf.jhu.edu/~ecf_stbo/
This message has been brought to you by bill gates, inventor of the internet
What monopoly do you want to flip the bird at today?