From: kirk@tallis.enet.dec.com (Matthew B. Kirk)
Newsgroups: comp.os.vms
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Date: 23 Nov 92 20:34:18 GMT
Organization: Digital Equipment Corporation


In article <1992Nov20.200412.5852@ais.com>, bruce@ais.com (Bruce C. Wright) writes...
>In article <1992Nov20.154517.627@nntpd.lkg.dec.com>, kirk@tallis.enet.dec.com (Matthew B. Kirk) writes:
>> 
>> In article <1992Nov19.125053.5849@ais.com>, bruce@ais.com (Bruce C. Wright) writes...
>>>What I don't understand is why the image activator in Alpha doesn't
>>>crank up VEST in interpretive mode in such cases (or possibly only if
>>>a flag is set in the image header, like the debug flag).  It seems to
>>>me that this would get you very much of the effect you'd want for
>>>very little penalty (other than the interpretive overhead, of course,
>>>which is substantial but still faster than most VAXen).
>> 
>> VEST is a static translator.  The Translated Image Environment (TIE)
>> contains a fall-back interpreter but it's not particularly fast.              
>> One of the reasons we went to great effort to develop a translator
>> instead of an interpreter (which would have been far simpler) is that
>> interpretation would never have given acceptable performance.  There
>> are too many things that the VAX does (like maintain condition codes
>> all the time) that couldn't be optimized out in interpretation. 
>> Translation allows us to do all sorts of optimization.
> 
>I understand that -- but you can run VEST with the /INTERPRET=ALL
>qualifier, which does interpret the image (at least as I understand
>it).  It just seems to me that it wouldn't have been that difficult
>to do that by default if the image activator encountered a VAX/VMS
>image rather than an Alpha/VMS image, and that it would solve that
>particular problem.  

/INTERPRET=ALL is performing a static operation.  (for the uninitiated, 
/INTERPRET=ALL tells VEST to take an OpenVMS VAX image and to 
change the format to be an OpenVMS AXP image.  No code is translated,
so the entire image is interpreted). 

This takes time, so for a large image, image activation would take several
minutes.  Alternately, we could just supply an interpreter but as I said
earlier the need to do significant amounts of unnecessary work makes it 
very slow.

For example, we would have to maintain all parts of the VAX architecture
ALL THE TIME.

>I perfectly agree that it wouldn't set any land
>speed records;  and I think it would still be faster than any but the
>fastest VAX processors around now.

Why do you think this?   The only way you could create an interpreter 
that ran this fast (and didn't use on-the-fly translation) would be if 
you were to need only a few Alpha AXP instructions for each VAX instruction.
VEST can do that during translation because it can eliminate unnecessary
steps.    

But when you're interpreting an instruction that looks like
"MULL3 (SP)+, (R3), @28(R2)" you have to:

1.  Decode the instruction.   Fairly easy - use a jump table, but this   
    takes several instructions.

2.  Decode the operands.  Operand specifiers are variable length
    and may require multiple memory fetches to decode.  In this case, 
    one memory reference is required to decode the third operand
    specifier.  

3.  Load the operands.

4.  Perform the multiply (1 instruction).

5.  Compute N(egative), Z(ero) and V (overflow) - several instructions.

6.  If an overflow occurred see whether overflows are supposed to be 
    signalled - several instructions to extract the IV (overflow
    enable bit) from the PSL.  

7.  Store results.

8.  Insert the condition code bits in the PSL - a lot of instructions.

On top of this, you need to guarantee VAX-style exception behavior and
instruction and memory atomicity all the time since you never know when 
atomicity is or isn't going to be required, and the cost of allowing
this to be switch-selectable at run time in an interpreter is high
(e.g. each time an instruction is interpeted each switch must be checked).

How fast do you really think you can make this?  Analysis allows us to 
eliminate step 1 and reduce (or eliminate) steps 2, 3, 5, 6, 7, and 8.

=============================================================================
Matthew Kirk				  	     kirk@tallis.enet.dec.com

All opinions expressed here are mine and do not reflect those of Digital
Equipment Corporation.
=============================================================================