@HoffmanLabs I've worked on IBM assembler but never really on vax and always with integers.
If code says (float) C = (int) A / (float) B, then at sone point before division, A gets converted to float, right?
Do CPUs have assembler instructions to convert from int to float and back? or does compiler generate code to set the 64 bits of a float with sign, exponent and mantissa based on value of integer, after which floating point instructions can treat those 64 bits as a float?
@jfmezei Usually, yes. But like most things in IT, details can vary.
VAX has a wad of CVT conversion instructions, among other wads of instructions including the vector extensions, for instance. VAX offers instructions for pretty much everything to everything (everything circa 1978) and either has an instruction, or maybe has a macro.
For VAX floating point details, see section 9.9 here:
Details here will vary by architecture, and often by implementation within architecture. (q.v. Alpha extensions including the byte-word extension, and Arm SBSA, etc.)
Here’s an Alpha intro, as Alpha was effectively VAX with most of the latent VAX limits removed (not the least of which were the condition codes):
Alpha too has a wad of CVT conversion instructions.
The wrinkle with C code can be the implicit conversions that can (necessarily) arise when mixing data types. I’m not entirely certain a compound if {} else {} and a ?: ternary will produce the same outcome for all possible variations, and I’ve been using C for... for a while.
<voice=buzzlightyear>And UB, UB everywhere.
C looks kinda like a weird PDP-11 in various ways.
If you want to view the instructions of recent architectures, visit godbolt.
Atari had a video game Major Havoc, where a clone battled the evil Vaxxian empire located on Planet Maynard.
Entirely coincidentally, the headquarters of the producer of VAX supermini computers, Digital Equipment, was located in Maynard Massachusetts.
The pub located across Main Street from DEC’s Maynard Mill headquarters had a Major Havoc game for a while, too.
DEC used an addressing system that identified each site, building, floor, and pillar and mailstop within each DEC complex worldwide. Within the many buildings located in the Maynard Mill, the aforementioned pub self-allocated the next highest available building number for themselves, “becoming” (IIRC) MLO25; building 25.
Of course, various meetings were then held in building 25.
An image of mine showing a quiet evening in Maynard is included below.
@tommythorn@jfmezei DEC did do some semi-cheaper semi-SOC-ish Alpha processors; the DECchip 21066 and 21068 LCA45 and LCA4s designs.
DEC was interested in Arm for embedded projects, for I/O controllers, for handheld devices akin to the Compaq iPaq, and to help keep the fabs filled.
Several of the embedded projects in my acquaintance used 80186 (what doesn’t?) and having a corporate Arm option and tooling would have been nice. Doing the multi-port RAM memory refresh for the I/O controller’s 80186 bootstrap from within a VAX device driver was amusing, though.
Arm, and the 80186 and giblets, were all cheaper than the VAX processors that some of the DEC networking gear used as embedded processors.
Like the VAX microprocessors, the
Alpha fully-amortized production costs were high, so it made sense to have a lower-spec’d and cheaper processor designs available.
@pervognsen@steve@cr1901@regehr The VAX/VMS kernel and a fair amount of VMS userland were written in VAX BLISS, and in VAX MACRO-32 assembler.
That implementation shifted with work to allow C in the VMS (later OpenVMS) kernel, and the remaining portions of BLISS and MACRO-32 in the current kernel are now far much smaller.
VSI still maintains BLISS and MACRO-32 compilers for OpenVMS on Alpha, Itanium, and x86-64.
A little fragment of Digital Equipment Corporation storage development that ended up at IBM by way of Quantum, now with 50 TB drives, and with the LTO tape drives that descended from the DEC TK50 DLT digital linear tape…
@dosnostalgic VAX/VMS circa 1978 used to boot with PDP-11 RSX-11M compatibility mode available and a fair chunk of the apps in the early VAX/VMS versions were RSX-11M apps running in compatibility mode.
The VAX-11 boxes supported PDP-11 instructions in hardware.
You could run your existing PDP-11 RSX-11M apps directly, too.
That all ended at VAX/VMS V4.0 (~1984), and with then-new VAX models after VAX 8600.
VAX 8600 was originally to be named VAX-11/790, but marketing marketed and dropped the -11 with the “architecture for the ‘80s”.
PDP-11 RSX-11M compatibility mode became a separate product, and the PDP-11 instructions were emulated, and the -11 was dropped from VAX.
Technically, an LSI-11 console processor booted RT-11 from the 8” console floppy which then booted the VAX-11/780 (organizationally within he hardware, the VAX was an enormous LSI-11 peripheral) which ran VAX and PDP-11 instructions and which could run simh emulator to emulate PDP-11 running RT-11. If the LSI-11 failed—as happened on a couple of occasions—the VAX could continue to run. Just not reboot.
The approach Apple used for migrations with Rosetta and Rosetta 2 was far smoother.
Yeah. Fun times. When it all worked.
There are shenanigans in newer boxes too, but they’re usually somewhat better hidden.
And to think, Alpha EV7z peaked at 1.3 GHz, and a top-binned Itanium Poulson, err, Kittson peaked at 2.66 GHz, and here an old and slow i5 is now well past both at 3.4 GHz. (Yes, I am well aware of the perils of comparing clock speeds across disparate architectures, but thanks for mentioning that.)
Many years ago, I watched the relatively rapid disintegration of Digital Equipment Corporation (DEC), an important and massive firm that I admired greatly -- that even ran a private helicopter between its Mass/NH facilities (I rode it several times, it had its own gate at Logan!). Back then, it seemed impossible, unimaginable that they'd become just a memory due to technical and business decisions that proved to be out of step with the time in various ways.
I seriously and fervently hope that #Google doesn't end up the same way.
@lauren Worked for DEC in the Maynard Mill for a while, and then in Nashua, and then through the acquisitions.
DEC was a fun ride, into the early 1990s.
Lots of cool tech. Alpha, networking, clustering, DECtalk and DECvoice, etc.
But the markets DEC was selling into either shifted or entirely faded away, and DEC didn’t adapt.
Lower-cost product fabrication was difficult or unobtainable with the longstanding production approaches DEC used, too. Commoditization and consolidation hit hard, both hardware and software.
(The fully-amortized cost of production for various DEC chips was prodigious. Competitive semiconductor chip production is not cheap.)
That the core of Microsoft Windows NT was DEC MICA undoubtedly stung some in DEC management.
@jfmezei@lauren The epoxy in the BA11 backplane of the MicroVAX II/RC (variously translated as reduced cost, reduced configuration, or really crappy) was one of various attempts to sell lower-end hardware configurations at lower prices.
That also all meant DEC had to restrict replacement BA11 backplane availability.
Another example of artificial segmentation was the deliberately-slowed firmware in the VAX 8500. Somebody found that loading VAX 8700 firmware into the VAX 8500 made the slower VAX run faster; run at VAX 8700 speeds.
Which then led to the addition of firmware checks, and to the VAX 8530 and VAX 8550 servers.
For a while, it was cheaper to buy a DEC VT240 and the color monitor upgrade than to buy the VT241 configuration, too. Same hardware, spare monochrome monitor, and cheaper.
Underneath all this and various other examples was the difficulty of building cheaper boxes without undercutting the profits from the higher-end boxes.
VAX wasn’t getting faster or cheaper, RISC got faster than VAX, PRISM never happened, Alpha was seriously fast but also late and wasn’t hitting volume even with Windows, DECstation four-digit (MIPS boxes) wasn’t all that popular, and the VAXmate and DECpc and DECstation three-digit (x86 boxes) were not things DEC was able to build cheaply enough.
DEC was better at building lower-volume and higher end and not-commodity boxes, couldn’t get product positioning and pricing and volumes right for commodity, and customers weren’t all that happy with (overt) product segmentation efforts.
If a vendor is not actively undercutting their own products with newer products and newer work, somebody else is. And the incumbent vendor won’t usually be able to catch up, once they realize they’re in competitive trouble. DEC got undercut in technical computing (with RISC), and then undercut in commercial.
And x86 then undercut all of the CISC and RISC vendors of that era.
@lauren@jfmezei The VAX-11/780 had a console clock speed command.
I’d have to rummage for the VAX console syntax, but it was a SET CLOCK (IIRC) selection for the clock speed akin to very stable (slow), stable (normal), and maybe-unstable (fast).
Newer hardware debug comands tend to be less obvious, and less exposed. And less necessary.
Before the web and HTML became ubiquitous, there were videotext terminals and similar software packages around, and probably most famously including the French Minitel system.
The DEC VTX videotext layered product for then VAX/VMS and MicroVMS (later OpenVMS) was inspired by Minitel.
While VTX wasn’t often purchased by DEC customers, nor used all that widely outside of DEC, there was a whole lot inside DEC using VTX and the Notes conferencing app inside DEC. VTX was replaced by other mechanisms, while Notes was deprecated but never died.
There are some accessible Notes conferences (free) at the DECUServe server, for those interested in experiencing that. I’m not aware of any sites still running DEC VTX.
DEC Alpha is an exceedingly asynchronous design, with memory reads and writes reordered or coalesced for performance.
This approach also arises with traps and exceptions, too. (With locks too, and EV6 exposed a bug in the DEC compiler code generation, but that’s fodder for another time.)
With floating point instructions, Alpha will trap on floating point errors, but not immediately. Some number of subsequent instructions will have been performed, and the inputs into the error and outputs from the error can have been overwritten. This is called the trap shadow. And there can be other traps arising in the same shadow; between the same execption barriers, or between the same trap barriers.
This means the code can get to rewind and restart the whole instruction sequence from the last barrier, in what amounts to synchronous operations. Or pass the whole problem to the caller, of course.
This asynchronous behavior works great for floating point finite operations with finite results, and not so well for code with underflows or overflows. If the FP gets wonky, the app or the system necessarily gets involved.
The compiler can generate barriers as needed or as requested, and with the obvious trade-off: the fewer the barriers inserted into the instruction stream, the faster the code execution, and the slower the error recovery.