jfjr@mbunix.mitre.org (Freedman) (10/12/90)
I just learned about the HPE spectrum (64 bits address)
in class. It apparently can run its proprietary operating
system or unix. Is anybody out there really exercising
that memory? what for? how does it perform? As far as that
machine running unix how much of the paging stuff was redone?
How does it handle pointers? How about them Red Sox?
Jerry Freedman,Jr
renglish@hplabsz.HPL.HP.COM (Bob English) (10/13/90)
In article <123093@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes: >I just learned about the HPE spectrum (64 bits address) >in class. It apparently can run its proprietary operating >system or unix. Yes. HP-PA (PA-RISC, or whatever the marketing folks are calling it these days) supports a 64-bit virtual address space composed of 32-bits worth of 32-bit segments. My personal view is that the only real difference between this segmented architecture and a flat 64-bit address space is the size of the registers needed to support it. In any case, HP-PA has two types of addressing, short pointer and long pointer. In the long pointer case, the instruction specifies explicitly which space register it wants to reference through. In the short pointer case, the space register choice is implicit on the high-order bits in the source address. > Is anybody out there really exercising that memory? what for? Yes, in two ways. In the proprietary OS (MPE-XL) all I/O is done through the virtual memory system. The long pointer space is used to allow large amounts of secondary storage to be accessed. One thing worth keeping in mind is that this 64-bit address space is global: A single 64-bit address is the same in all contexts. The machines also support short (32-bit) pointer space. In short pointer space, each 32-bit space is split into 4 quadrants, indexed by the 2 high-order bits in the short pointer. There are four space registers available, and they can point to sequence of four spaces. This gives the OS the freedom to run a process in four different spaces, some shared and some private, without any modification to the user process. This is used a great deal by HP-UX. Other work has been done using long pointers to support mapped files in hp-ux similar to those used in MPE-XL. > how does it perform? Pretty well. The latest processor is about 50 MIPs and over 30 SPECs. HP-PA processors have done better in the minicomputer range than the workstation range because the processor, cache, and chassis designs have all been driven by that market, where the cost of the processor board was small compared to the total system cost. As workstation performance begins to eat in to the commercial market, I expect that focus to change or HP to become uncompetitive. > As far as that machine running unix how much of the paging stuff was > redone? The main changes had to do with the global virtual address space. Since each program sees its address space as 32-bits, the part of the VM system that manages the program's virtual address space isn't very different. Larger changes were required to deal with HP-PA's virtual cache structure, which makes virtual address aliasing difficult to do well. The Mach port done at the University of Utah, for example, ran about 20% slower than hp-ux because of Mach's penchant for VM aliasing. --bob-- renglish@hplabs HP's mouth is far too big to be filled my puny little foot.
henry@zoo.toronto.edu (Henry Spencer) (10/14/90)
In article <123093@linus.mitre.org> jfjr@mbunix.mitre.org (Freedman) writes: >I just learned about the HPE spectrum (64 bits address) >in class... Well, "64 bits address" after a fashion, in the same sense that the 8086 has 20-bit addresses or the pdp11/44 has 22-bit addresses (both of these are normally considered 16-bit machines) or the RT has 40-bit addresses. That is, you can change segment registers to map your *real* address space to semi-arbitrary parts of a bigger space. The trouble with this is that if you start seriously exploiting it, it becomes a programming nightmare, as any IBMPC programmer will tell you: remapping is costly enough that it cannot be made invisible, and so you run into abominations like having two different kinds of pointers. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
renglish@hplabsz.HPL.HP.COM (Bob English) (10/16/90)
In article <6058@hplabsz.HPL.HP.COM> renglish@hplabsz.UUCP (Bob English) writes: >The Mach port done at the University of Utah, for example, ran >about 20% slower than hp-ux because of Mach's penchant for VM aliasing. Just a clarification here: Mach is not inherently 20% slower on PA-RISC, but some changes are necessary to eliminate the 20% performance penalty. I chose the example merely to illustrate the difference that supporting the PA-RISC architecture properly could mean to performance. The changes needed to the machine-independent portion of the Mach VM system are minor tweaks, but they make a big difference in performance. --bob-- renglish@hplabs.hp.com "A foot in the mouth is worth...wait a minute...!?!?"
renglish@hplabsz.HPL.HP.COM (Bob English) (10/18/90)
In article <6067@hplabsz.HPL.HP.COM> renglish@hplabsz.UUCP (Bob English) writes: >>The Mach port done at the University of Utah, for example, ran >>about 20% slower than hp-ux because of Mach's penchant for VM aliasing. >Just a clarification here: Mach is not inherently 20% slower on >PA-RISC, but some changes are necessary to eliminate the 20% performance >penalty. I chose the example merely to illustrate the difference that >supporting the PA-RISC architecture properly could mean to performance. >The changes needed to the machine-independent portion of the Mach VM >system are minor tweaks, but they make a big difference in performance. One more clarification: I have been asked to make it clear that the performance numbers I quoted came from the Tut project at HP Labs, not the Mach port at the University of Utah, though the groups had been sharing information on the two projects. I did not mean to imply that the Utah Mach port was slow, nor did I mean to imply that Mach itself was slow. I merely meant to answer the original question about what kinds of changes were necessary to the VM system, and give some insight into the effects those changes have on system performance. >"A foot in the mouth is worth...wait a minute...!?!?" Talk about an understatement :-). --bob-- renglish@hplabs.hp.com
daryl@hpcllla.cup.hp.com (Daryl Odnert) (10/20/90)
This is not a complete list, nor is it completely up to date.
Hope you find it useful.
Daryl Odnert daryl@hpcllla.cup.hp.com
Hewlett-Packard
California Langauge Lab
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HP Precision Architecture Bibliography
Architecture
J. S. Birnbaum and W. S. Worley, Jr., "Beyond RISC: High-
Precision Architecture," Hewlett-Packard Journal, Vol. 36,
No. 8, August 1985.
HP Precision Architecture and Instruction Reference Manual,
Hewlett-Packard Company, Third Edition, April 1989. HP part
number 09740-90014.
M. J. Mahon, et. al., "Hewlett-Packard Precision Architec-
ture: The Processor," Hewlett-Packard Journal, Vol. 37, No.
8, August 1986.
Ruby B. Lee, "Precision Architecture," Computer, Jan. 1989.
Also published in Proceedings of the 22nd Hawaii Int'l Conf.
on System Sciences, Jan. 3 - 6, 1989.
Software
D. S. Coutant, C. L. Hammond, and J. W. Kelly, "Compilers
for the New Generation of Hewlett-Packard Computers,"
Hewlett-Packard Journal, Vol. 37, No. 1, January 1986.
HP Precision Architecture Procedure Calling Conventions
Reference Manual, Hewlett-Packard Company, 1986. HP part
number 09740-90015.
Mark S. Johnson and Terrence C. Miller, "Effectiveness of a
Machine-Level, Global Optimizer," Proc. of the SIGPLAN '86
Symp. on Compiler Construction, ACM SIGPLAN Notices, Vol.
20, No. 7, July 1986.
D. S. Coutant, "Retargetable High-Level Alias Analysis",
Conference Record of the 13th ACM Symposium on Principles of
Programming Languages, January 1986.
P. Gibbons and S. Muchnick, "Efficient Instruction Schedul-
ing for a Pipelined Architecture," Proceedings of the SIG-
PLAN '86 Symposium on Compiler Construction, ACM SIGPLAN
Notices, Vol. 20, No. 7, July 1986.
D. J. Magenheimer, L. Peters, K. Pettis, and D. Zuras,
"Integer Multiplication and Division on the HP Precision
Architecture," Proc. of the Second Intl. Conf. on
Architectural Support for Programming Languages and Operat-
ing Systems (ASPLOS-II), ACM, New York, October 1987.
Alan S. Brown, et. al., "Data Base Management for HP Preci-
sion Architecture Computers," Hewlett-Packard Journal, Vol.
37, No. 12, December 1986.
F. W. Clegg, et. al., "The HP-UX Operating System on HP Pre-
cision Architecture Computers," Hewlett-Packard Journal,
Vol. 37, No. 12, December 1986.
K. W. Pettis and W. B. Buzbee, "Hewlett-Packard Precision
Architecture Compiler Performance," Hewlett-Packard Journal,
Vol. 38, No. 3, March 1987.
J. Busch, et. al., "MPE/XL: The Operating System for HP's
Next Generation of Commercial Computer Systems," Hewlett
Packard Journal, Vol. 38, No. 11, December 1987.
D. Coutant, S. Meloy, and M. Ruscetta, "DOC: A Practical
Approach to Source-Level Debugging of Globally Optimized
Code", Proceedings of the SIGPLAN '88 Conference on Program-
ming Language Design and Implementation, June 1988.
S. Jain and C. Thompson, "An Efficient Approach for Data
Flow Analysis in a Multiple Pass Global Optimizer", Proceed-
ings of the SIGPLAN '88 Conference on Programming Language
Design and Implementation," June 1988.
Karl Pettis and Robert C. Hansen, "Profile Guided Code Posi-
tioning", Proceedings of the ACM SIGPLAN '90 Conference on
Programming Language Design and Implementation, SIGPLAN
Notices, Vol. 25, No. 6, June 1990.
Vatsa Santhanam and Daryl Odnert, "Register Allocation
Across Procedure and Module Boundaries", Proceedings of the
ACM SIGPLAN '90 Conference on Programming Language Design
and Implementation, SIGPLAN Notices, Vol. 25, No. 6, June
1990.
Hardware
D. V. James, et. al., "Hewlett-Packard Precision Architec-
ture: The Input/Output System," Hewlett-Packard Journal,
Vol. 37, No. 8, August 1986.
David A Fotland, et. al., "Hardware Design of the First HP
Precision Architecture Computers," Hewlett-Packard Journal,
Vol. 38, No. 3, March 1987.
Steven T. Mangelsdorf, et. al., "A VLSI Processor for HP
Precision Architecture," Hewlett-Packard Journal, Vol. 38,
No. 9, Sept. 1988.
Jeffry D. Yetter, et. al., "HP Precision Architecture NMOS-
III Single Chip CPU," Hewlett-Packard Journal, Vol. 38, No.
9, Sept. 1988.
Craig S. Robinson, et. al., "A Midrange VLSI Hewlett-Packard
Precison Architecture Computer," Hewlett-Packard Journal,
Vol. 38, No. 9, Sept. 1988.
Gerald R. Gassman, et. al., "VLSI-Based High-Performance HP
Precision Architecture Computers," Hewlett-Packard Journal,
Vol. 38, No. 9, Sept. 1988.