Re: Quality of VAX compilers

On Mon, 12 Jun 2006 20:50:59 -0700, Jan Vorbrüggen
<jvorbrueggen@mediasec.de> 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
indicated.
>
> - 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.

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