NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/os/vms/18266

Text File | 1992-11-20 | 4.1 KB | 82 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!tallis.enet.dec.com!kirk
From: [e-mail] (Matthew B. Kirk)
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Digital Equipment Corporation
Date: Fri, 20 Nov 1992 15:29:41 GMT
Lines: 71


In article <[e-mail]>, [e-mail] (Bruce C. Wright) writes...
>In article <[e-mail]>, [e-mail] (Harvey Brydon [phone]) writes:
>> In article <[e-mail]>, [e-mail]
>> (Julian James Bunn) writes:
>>>What worries me more about a mixed architecture VAX/Alpha VMS Cluster is
>>>how the poor innocent users are going to sort out the confusion between
>>>VAX and Alpha executables. [...]

We've been running a test system as a mixed cluster in my group (my
primary workstation, a 3000 model 500, is a member of it).  We haven't
had problems with 'gee, is that a OpenVMS VAX executable or an OpenVMS AXP
executable'.  We do have separate system disks though, which is
necessitated by the fact that we frequently have each OpenVMS AXP node in the
cluster running a different test version of OpenVMS.

>
>This is one of those situations where you can't win.  If the default
>extension for executable images were changed, then many of the programs
>that spawn subprocesses or do dynamic mapping to sharable images are
>likely to break when they're recompiled for Alpha.  (For the most part
>you don't need to go through your programs to look for things like
>that when you move them to Alpha -- though you may want to do so for
>other reasons, such as improving efficiency on the new architecture).
>

Exactly correct.  We run into a similar problem with translated images
that do something with another image (e.g. vfork) and specify the image
name as 'FOO.EXE'.  If FOO.EXE is translated (and hence renamed FOO_TV.EXE),
then the user must do one of two things:

1. rename FOO_TV.EXE to be FOO.EXE.  This runs the risk of confusing
   translated and native images (which are different in some cases,
   even if they would otherwise share the same name).

2. modify the source to simply specify 'FOO', then $DEFINE FOO FOO_TV
   on the OpenVMS AXP system.

You would run into the same problem if .EXEs on OpenVMS AXP were renamed
.AXEs, or .AEXEs (both were suggested at one point).

>The idea one person had, about embedding both types of executable
>code in one image, also has similar problems but probably a lot less
>code depends on the image format than on the file names.  If any code
>does depend on the image format it will break for Alpha anyway.

The problem here is that the images get much larger, so more disk space
is required.  Also, image formats are different.

>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.

=============================================================================
Matthew Kirk                           [e-mail]

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