On 12/20/23, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: The VAX-11/780, 11/750, and 11/730 were all implemented using 7400-series discrete, gate-level TTL integrated circuits. The planned follow-on series was Venus (ECL gate level; originally planned to be the 11/790 but after many delays released as the VAX 8600), Gemini (a two-board VAX implementation; cancelled), and Scorpio (a chip set eventually released as the VAX 8000). Superstar, released as the VAX-11/785, is a re-implementation of the 11/780 using faster TTL. The floating point accelerator board for the 11/785 was implemented using Fast Fairchild TTL. The first microprocessor implementation of the VAX architecture was the MicroVAX-I. It, and all later VAX processors, implemented only the MicroVAX subset of the VAX architecture in hardware and firmware. The instructions left out were the character string instructions (except for MOVC), decimal arithmetic, H-floating point, octaword, and a few obscure, little-used instructions such as EDITPC and CRC. The missing instructions were simulated by the OS. These instructions were originally dropped from the architecture because there wasn't enough real estate on a chip to hold the microcode for them. It's interesting that they continued to be simulated in macrocode even after several process shrink cycles made it feasible to move them to microcode. I wrote a distributed (computation could be done in parallel over a DECnet LAN or WAN) Mandelbrot Set computation and display program for VAX/VMS. It was implemented in PL/I. The actual display was incredibly sluggish, and I went in search of the performance problem. It turned out to be in the cartesian-to-screen coordinate translation subroutine. The program did its computations in VAX D-float double precision floating point. The window was 800x800 pixels and this was divvied up into 32x32-pixel cells for distributed, parallel computation. The expression "800/32" occurred in the coordinate conversion program. In PL/I language data type semantics, this expression is "fixed decimal(3,0) divided by fixed decimal(2,0)". This expression was being multiplied by a VAX D-float (float decimal in PL/I) and this mixture of fixed and float triggered one of the more bizarre of PL/I's baroque implicit data type conversions. First, the D-float values were converted to full-precision (15-digit) packed decimal by calling one of the Fortran RTL's subroutines. All the arithmetic in the routine was done in full-precision packed decimal. The result was then converted back to D-float (again by a Fortran RTL call). There were effectively only two instructions in the whole subroutine that weren't simulated in macrocode, and one of those was the RET instruction at the end of the routine! I changed the offending expression to "800E0/32E0" and got a 100X speedup--everything was now being done in (hardware) D-float. -Paul W.