[Info-vax] Baremetal emulators, was: Re: Alpha emulator for OSX

[Stephen Hoffman]

On 2016-02-08 14:21:55 +0000, lists at openmailbox.org said:

> Very well said as usual. But is this an issue for OpenVMS users? Is 
> OpenVMS used for real-time applications?

There are many applications with latent dependencies on timing; that 
will fail when calls operate too quickly or too slowly.  These 
applications are arguably poorly written, but they can and do exist.

As one classic example of one of these timing dependencies: the DEC 
Pascal compiler had a timing dependency back in the VAX era.  With a 
sufficiently-fast VAX, the compiler would sometimes tip over with a 
stackdump.  This stackdump showed up during testing of the VAX 9000, 
with (IIRC) about a third of the compiles.   It turned out not to be a 
bug in the then-new VAX 9000 (cue much relief among the hardware team), 
but rather a case where the entire compile finished within the 
resolution of the clock, and some of the compilation-reporting code 
within the Pascal compiler failed with a divide-by-zero.

One of the device drivers I worked on tipped over after a MicroVAX 
update, as well.  The forks got tangled up over shared data; the 
sequencing had been reordered.   Threading can be subtle.

For those using hardware (and this is not applicable to AVT), various 
Q-bus devices were notorious for failing and needing ECOs for newer 
processors, as well.  A down-revision VCB02 graphics controller will 
work fine on KA630 (MicroVAX II processor) but will usually lock up if 
used on the faster KA650 (MicroVAX III, 3200, 3500).

Software is always dependent on timing.  Networking is one big heap of 
hopefully-not-interfering timers, all hopefully firing in the right 
order.   What happens when the timing changes... varies.

If the system timing changes unexpectedly due to something else 
happening "underneath", application code may fail.

As for the more general issues. there's also that somebody — AVT most 
likely, for this case — now has to maintain that Linux stack underneath 
the emulation.   With the more traditional definition of "bare metal", 
the only product patches that are necessary are specific to emulator 
issues.   With the AVT distros, you're still going to need Linux 
network stack and IP stack and kernel patches, probably also patches 
related to TLS (as the network connections are or should be encrypted) 
and maybe certificate updates, and those patches associated with any of 
the active management or logging services or other ports that might be 
open within the Linux portion of the stack.

This packaging with Linux does avoid the folks at AVT having to write 
and maintain their own operating system, networking stack and TLS 
implementation.     But now AVT (and you, being that you are ultimately 
responsible for your application) need to watch for applicable Linux 
patches.  One downside is that you may have to figure out how to 
"un-bare-metal" this emulator, if patches are no longer available from 
AVT for whatever reason.

This AVT monolithic packaging provides new for the folks interested in 
running an Alpha emulation natively on OS X, of course.  That you could 
VM and boot Windows or Linux or BSD was already mentioned.


-- 
Pure Personal Opinion | HoffmanLabs LLC