henry@utzoo.UUCP (Henry Spencer) (03/14/86)
The latest "Hewlett-Packard Journal" (Jan 1986 issue) has an article on
their new RISCish machine, which sounds moderately interesting. It has
a relatively simple instruction set with pipelining at least semi-visible.
It does not have overlapping register windows, but its compilers make a
considerable effort to exploit its registers effectively; it sounds like
they have put a lot of work into optimization. The most interesting part
of the article is a section entitled "Addressing RISC Myths", which spends
some time knocking down some of the standard objections. A summary follows;
note that I'm summarizing HP's views rather than my own, although I agree
with most of it.
"An architected [i.e. microprogrammed] procedure call instruction is
necessary for efficient procedure calls."
Nope. Intelligent compilation on a RISC architecture can do better, by
exploiting knowledge about register usage to produce non-worst-case code
customized to the particular situation. One thing HP's compilers do is
to identify "leaf" procedures which don't call anything else, and use a
drastically streamlined calling convention for them. Things like register
usage patterns of non-leaf procedures are also tailored for call speed.
"The simple instructions available in RISC result in significant
code expansion."
Nope. Complex operations can be implemented in "millicode" (procedures
with extremely streamlined calling conventions). Since this is normal
executable code, it can be written using normal tools, stored in ordinary
memory, and upgraded easily. Also, since it's not bound by most of the
restrictions commonly found in microcode, it's much more practical to
use customized millicode to exploit detailed knowledge of specific
situations. E.g., a bulk-move operation can exist in a number of different
versions so that the compiler can exploit knowledge of things like overlap,
alignment, size, etc., rather than forcing microcode to rediscover this
information at run time.
Also, complex instructions are seldom used; millicode costs only when
it is actually used.
"RISC machines must implement integer multiplication as successive additions."
Most integer multiplications in real programs are by small constants. A
carefully-designed RISC machine with a good compiler can execute such
multiplications *faster* than a CISC which has only a fully-general multiply
instruction. HP's new machine has a few specialized instructions to help,
notably "add" instructions which first shift one operand by 1-3 bits. Given
these, "...multiplications by most constants with absolute values less than
1040 can be accomplished in fewer than five cycles". The millicode routines
that handle more general cases still make an attempt to detect small
operands, resulting in an average multiplication time of 20 cycles,
comparable to a CISC iterative implementation.
"RISC machines cannot support commercial applications languages."
They mean COBOL, in particular. Nope. Most of the peculiar COBOL-oriented
instructions in, say, the 370 are very seldom executed even by COBOL code.
COBOL programs spend most of their time inside the operating system and
other subsystems. Millicode is used for most low-level COBOL-oriented
operations, again with the compiler working hard to exploit knowledge of
the operands to pick the most streamlined millicode. HP has also provided
some instructions to help the millicode. The result is compact and fast.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrykludge@gitpyr.UUCP (Scott Dorsey) (03/16/86)
If anyone out there has seen the HP spectrum and looked carefully at
it, I'd like to hear your comments. From a cursory inspection it looks
like an HP3000 (which has an interesting, albeit slow, stack architecture),
with a mode bit, which, when set, puts the user into some sort of RISC mode.
With the mode bit off, it runs HP3000 software at about the same speed as a
3000, and with it on, it runs some nonstandard kind of RISC software.
It looks possible to run both modes at the same time for different
processes, but I haven't seen the software support yet. MPE, maybe? I'd
also like to see if they kept the 'privileged segments' concept on the RISC
half... it was interesting to set one of the bits in your program header
(usually using the disk editor), so that when the loader picked it up, it
gave it privileged mode. Worst security I've seen lately.
--
-------
Disclaimer: Everything I say is probably a trademark of someone. But
don't worry, I probably don't know what I'm talking about.
Scott Dorsey " If value corrupts
Kaptain_kludge then absolute value corrupts absolutely"
ICS Programming Lab (Where old terminals go to die), Rich 110,
Georgia Institute of Technology, Atlanta, Georgia 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
USnail: Box 36681, Atlanta GA. 30332daver@hp-pcd.UUCP (daver) (03/19/86)
> If anyone out there has seen the HP spectrum and looked carefully at >it, I'd like to hear your comments. From a cursory inspection it looks >like an HP3000 (which has an interesting, albeit slow, stack architecture), Dave Patterson, of Berkeley, wrote the first paper proposing a RISC architecture after spending some time working at HP, and, except for the register windows, which resemble a feature of the TI 9900 processor, his proposed machine closely resembled the micro-machine in the old HP3000s, even to the names of the fields in an instruction. In effect, his RISC machine had user programs written in microcode. It shouldn't be surprising if a RISC machine resembles the HP3000. Dave Rabinowitz hplabs!ho-pcd!daver
hansen@mips.UUCP (Craig Hansen) (03/21/86)
> > If anyone out there has seen the HP spectrum and looked carefully at > >it, I'd like to hear your comments. From a cursory inspection it looks > >like an HP3000 (which has an interesting, albeit slow, stack architecture), > > Dave Patterson, of Berkeley, wrote the first paper proposing a RISC > architecture after spending some time working at HP, and, except for the > register windows, which resemble a feature of the TI 9900 processor, his > proposed machine closely resembled the micro-machine in the old HP3000s, even > to the names of the fields in an instruction. In effect, his RISC machine > had user programs written in microcode. It shouldn't be surprising if a RISC > machine resembles the HP3000. > > Dave Rabinowitz > hplabs!ho-pcd!daver Spectrum (ahem, "Precision") isn't a stack architecture, and doesn't have an instruction set that resembles the HP3000. I won't comment on how Spectrum executes HP3000 code except to say that Spectrum doesn't have a mode bit (In "Soul of a New Machine" parlance, a bag on the side of the machine). Craig Hansen | "Evahthun' tastes MIPS Computer Systems | bettah when it ...decwrl!glacier!mips!hansen | sits on a RISC"
faunt@spar.UUCP (Doug Faunt) (03/21/86)
The HP-Spectrum has no HP3000 stack architecture mode. It is a register-to-register architecture with no support whatsoever for HP3000 emulation. Nevertheless, using one of three strategies involving different amounts of work on the part of the user, HP can get either comparable, or 2 times, or 5 times the performance of the fastest HP3000 (simulate, smart 'simulate', or recompile respectively).
kludge@gitpyr.UUCP (Scott Dorsey) (03/22/86)
In article <410@mips.UUCP> hansen@mips.UUCP (Craig Hansen) writes: >Spectrum (ahem, "Precision") isn't a stack architecture, and doesn't >have an instruction set that resembles the HP3000. >I won't comment on how Spectrum executes HP3000 code except to say >that Spectrum doesn't have a mode bit (In "Soul of a New Machine" >parlance, a bag on the side of the machine). Hmmm... the box runs code for a machine utterly unlike itself, without a mode bit. Sounds like software emulation to me, which is precisely what the HP rep screamed about it not using. I'm not even going to ask about this one... -- ------- Disclaimer: Everything I say is probably a trademark of someone. But don't worry, I probably don't know what I'm talking about. Scott Dorsey " If value corrupts kaptain_kludge then absolute value corrupts absolutely" ICS Programming Lab (Where old terminals go to die), Rich 110, Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
cdshaw@watdragon.UUCP (Chris Shaw) (03/23/86)
After reading the article in March 3, Electronics, the HP people make much of the millicode concept.. i.e. small bursts of RISC instructions that do some higher-level task. In 3000 emulation, millicode would emulate individual instructions. I don't know exactly how 3000 emulation is done, but this seems to be the missing clue. All that's required is a small interpreter underneath the "3000 interface" to translate 3000 instructions to millicode lookup. Details were rather lacking in the Electronics article, but a little intuition leads to the conclusion above. Can anyone at HP comment? Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath University of Waterloo Bogus as HELL !!!