🚀 go-pugleaf

In article <1992Nov18.112407.2518@doug.cae.wisc.edu> keiths@cae.wisc.edu  
(Keith Scidmore) writes:
> 1. The DEC Alpha includes a conditional move instruction that they claim
>    can be used to avoid using branches and the associated branch  
penalties.
>    I'm trying to evaluate the usefulness of this feature.  Can someone  
tell
>    me where I might find articles that discuss this or raw data that can  
be
>    used to calculate the advantages of such an instruction.  I'm not into
>    compilers, and I need to know what kinds of situations an optimizing
>    compiler could make use of this instruction.  Is it even practical?   
Are
>    there any compiler writers out there with opinions on this?

I don't have a good answer to your question, but conditional moves do seem  
to be a win. SPARC version 9 includes them. The HP precision architecture  
already has features that do much the same thing. And rumour has it some  
MIPS architecture types like them too...

While on the subject, would it be a win to use a dummy memory location and  
conditional move to optimize stores through pointers? For example, "if  
(result != NULL) *result = 0" could be compiled into:
	; result in r4
	; dummy is in r5
	cmoveq	r4, r5, r4	; if (r4 == 0) r4 = r5
	stl	r31, 0(r4)	; *r4 = 0 (r31 is wired zero)

The dummy location could be allocated at the bottom of the stack frame or at  
the global pointer location to save calculation of the pointer into a  
register.

> 2. The Alpha architecture also includes a feature they call PALcode that
>    allows the chip to have a sort of rom-bios.  Why is it useful to have
>    this feature?  Supposedly Operating systems can make use of this for
>    the implementation of certain system calls.

From the user visible instruction set architecture level, PALcode looks like  
any other system call trap. The difference is in usage, and in an unwritten  
promise to make PALcall fast enough to emulate certain operations. Usage  
wise, DEC specifies a set of bindings from PALcall numbers to functions  
which are supposed to be provided "by the hardware." That is they are below  
the OS. These bindings a different for VMS and OSF/1. This is supposed to  
allow hardware design flexibility while running the exact same OS binary.

I note two things about PALcode. First, you could do this with most other  
architectures and application programs would be totally unaffected. (And in  
fact there are prior examples of doing so. E.g. The cache flush system calls  
on MIPS platforms.) Secondly the idea that PALcode comes with the hardware  
is dubious. Its fine so long as the hardware builder and the OS vendor are  
nice and cozy. If not, the OS vendor has to supply their own PALcode. When  
new hardware comes out the OS will not run without new PALcode which will  
have to be written by the OS vendor. No different than current OS  
technology, but no better. The abstraction PALcode supports is good, but it  
does not require as much hardware support..

> 3. Cray has annouced intention to build a 300 Teraflop machine based on  
the
>    alpha.  What is the word for 1000 teraflops?

The prefix for 10^15 is "Peta" hence it is a petaflop machine. The prefix  
for 10^18 is "Exa" which you will need to know to describe the maximum  
virtual address space of a 64 bit machine (16 or 18 exa bytes depending on  
whether you think exabyte means 2^60 or 10^18).

--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson