NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/arch/8335

Internet Message Format | 1992-07-26 | 4.2 KB

Path: sparky!uunet!charon.amdahl.com!amdahl!JUTS!cd.amdahl.com!jjs40
From: [e-mail] (John Sullivan)
Newsgroups: comp.arch
Subject: Translating ML (was Re: MVC and MVCL)
Message-ID: <[e-mail]>
Date: 26 Jul 92 17:56:03 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 68

In article <dec.com>, [e-mail] (Ed Gould) writes:
>> And since most of the code is written in assembly language to begin
>> with, compiler optimizations are moot.
>
>I don't think this necessarily follows.  For example, one of the compiled
>languages for Alpha is Macro-32, i.e., VAX Assembly.  It's unusual to think
>of what started out as an assembly language to be run through a compiler,
>but there's nothing magic about it.

As I understand it, the ability to translate VAX assembly code to Alpha is
highly dependent on the "good behavior" of the original VAX code, such
as seperate data/code segments, no self-modifying code, well behaved OS calls,
etc.  Obviously it's possible to handle these cases, but then your
compile-time translation degenerates to run-time emulation with a big
performance hit (and a lot of added complexity.)

Unfortunately for IBM/370 customers, very few of the above properties are
guaranteed to hold for a given program.  Mixed code/data is very common and
self-modifying code also happens frequently enough to be a concern.  This
is a headache for our cache system - fortunately, we can spend the extra gates
in a mainframe CPU to handle these cases quickly.

The IBM/370 also has a fairly-frequently used instruction called EX (for
"execute") which basically feteches an instruction from a specified memory
address and executes it, and then continues on to the next sequential
instruction after the EX instruction.  This would be a major headache in
translated code, because you'll have to jump in to emulation mode every
time you encounter an EX instruction.  There are orders of magnitude of
added complexity in trying to get this right over simple translation.

On a side note: To a pipelined IBM/370 CPU, EX just looks like a branch
instruction, so it is handled very fast.  But, there are enough odd side
effects that it still causes a lot of problems (solved, of course, by spending
extra gates) for CPU designers.  For the curious RISC devotee, you can get
the same effect as an EX - executing a single instruction in an arbitrary
location - by executing two sequential delayed branch instructions.

As far as the OS goes, some IBM/370 applications tend to think of themselves
as running on a full-fledged virtual machine (not just a user-state process)
of their own (under the control of IBM's operating system, VM) and thus have
control over page-tables, and user/supervisor states within the application.
This is good for application performance (apparently, the ability to perform
your own memory mapping and scheduling is good for very large databases.) but
bad news for anyone trying to port to a new architecture. (Exactly as IBM
has always intended.)

--

Here's an interesting philosphical question:  If a new architecture
(say, Alpha)
is primarily used by customers to run translated code from an older
architecture (say, VAX) then what kind of synthetic effect will this
have on
the priorities of the CPU designers in designing higher-performance
future
generations of their machine?

For example, if translated code makes a lot of use of "compatibility" type
features that were never intended to be very fast, will these features win
out in gates in future versions of the CPU as opposed to spending the gates
on improving the "better" features from the new architecture?  Will architects
have to "dirty" their architecture in future versions by adding new features
(say, byte-wide or unaligned loads) to support better performance on
translated code?

--
John Sullivan, Engineer/Computer Development.   Email: [e-mail].
Amdahl Corporation, Sunnyvale CA.               Phone: [phone].