Re: Quality of VAX compilers

"Tom Linden" <>
15 Jun 2006 15:00:04 -0400

          From comp.compilers

Related articles
Quality of VAX compilers (Peter \Firefly\Lund) (2006-06-03)
Re: Quality of VAX compilers (Louis Krupp) (2006-06-05)
Re: Quality of VAX compilers (Peter \Firefly\Lund) (2006-06-07)
Re: Quality of VAX compilers (John Fredrickson) (2006-06-07)
Re: Quality of VAX compilers (glen herrmannsfeldt) (2006-06-11)
Re: Quality of VAX compilers (Tom Linden) (2006-06-11)
Re: Quality of VAX compilers (=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=) (2006-06-12)
Re: Quality of VAX compilers (Tom Linden) (2006-06-15)
Re: Quality of VAX compilers (Ken Rose) (2006-06-15)
Re: Quality of VAX compilers (2006-06-15)
| List of all articles for this month |

From: "Tom Linden" <>
Newsgroups: comp.compilers
Date: 15 Jun 2006 15:00:04 -0400
Organization: Kednos
References: 06-06-009 06-06-027 06-06-034 06-06-043
Keywords: history, code
Posted-Date: 15 Jun 2006 15:00:03 EDT

On Mon, 12 Jun 2006 20:50:59 -0700, Jan Vorbrüggen
<> wrote:

>>> The VAX hardware and VMS Operating System were designed together and
>>> were a beautiful system. Digital Equipment Corporation (DEC) did a
>>> good job transitioning to Alpha and OpenVMS.
>> I think you will get some argument on that, the Alpha instruction set
>> left a lot to be desired, which is one reason a lot of the VAX objecrs
>> were 'VEST'ed
> Really? AFAICT, the three main reasons for VESTing (binary translation
> with run-time support) were

You are quite right, not sure what I had in mind when I wrote that, VESTing
had nothing to do directly with the instruction, only in the manner you
> - no source available (hah! so what else is new?)
> - the relevant compiler was not ported to Alpha (e.g., SCAN)
> - performance was good enough for the translated code, why bother with
> re-everythinging it?
> Code heavily using the "commercial" instruction set suffered, but it
> was already suffering on the later VAX implementations. Sometimes the
> compiler upgrade helped - for instance, certain COBOL data types were
> implemented as BCD on VAX but changed to use native 64-bit integers on
> Alpha. VESTing such applications could only have made things worse.

We discovered that when we ported PL/I to Tru64 (OSF-1) ca. 1994
That is just one of the many design flaws in the Alpha. Power PC
(last time I looked some years ago) has only a one tick penalty for
unaligned access, effectively making it a byte addressable machine. The
early Alphas omitted sign-extend byte and 16-bit word moves so that an
instruction like C = A + B; took 17 ticks if these were fixed bin(15)
but only 4 if fixed bin(31)

The port itself was interesting, we used Jack Davidson's VPO as the
backend and we modified and existing more-or-less traditional code
generator to emit the RTLs for VPO. This required some hammering to
support things like lexical scoping. The alignement requirements
effect the performance of PL/I considerably.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.