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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Feb 8 18:39:23 EST 2016


On 2016-02-08 20:40:14 +0000, Johnny Billquist said:

> On 2016-02-08 17:13, Stephen Hoffman wrote:
>> 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.
> 
> All very true, but this is a different can of worms, Stephen.
> 
> Linux is not realtime. In fact, you have no idea how long time might 
> pass between the execution of one instruction and the next in your 
> application. Normally, it will be fast, but there is no bounded limit 
> on it. If you depending on a reaction within a bounded time, you are 
> playing russian roulette using a host OS like Linux.
> And this of course also affect how long "interrupt" latencies your 
> machine will appear to have. It might be super fast, and it might take 
> a long long time to react to that interrupt. And it varies from time to 
> time.
> Because with "next instruction", we're now talking about the next 
> instruction in the emulated machine. The actual host will be running 
> and executing instructions normally, just that it might be in the 
> bowels of Linux for a while...
> 
> 	Johnny

I was referring to vanilla, simple, ordinary timing dependencies 
involving incorrectly or unsynchronized operations.  Stuff that goes 
wrong when the underlying timing changes.   About timing-related things 
that should be simple to get right, but — as several folks around here 
are fond of demonstrating with some of the code that gets posted — 
correctly and consistently managing asynch activities isn't always 
something that always gets implemented.  Not even instruction 
dependencies.   (VAX instruction processing was its own special joy to 
deal with, but I digress.)

As for Linux Realtime, there are options:  https://www.rtai.org or 
http://xenomai.org or 
https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html or 
https://github.com/rtmux depending on specific requirements.

I'm sure there are others.

Related reading: http://elinux.org/images/0/00/Elc2013_Roman.pdf  — VMS 
has some of the same requirements and discussions, as — for instance — 
a cluster transition can hose the timing sof certain sorts of 
processing.

But discussions of what is or is not "realtime" — without application 
timing requirements, or at least a set of definitions that can be 
referenced — are rather more like "cloud" or "security" or "bare iron". 
  Either there's a framework for the discussions, or the conversation 
turns into "no true Scotsman".   As this one will continue.

With the prices of hardware, doing dedicated processing in a loop — 
either a specific core in a box, or with a dedicated box — or other 
such shenanigans becomes feasible.   Competent computing boards and 
boxes don't cost nearly as much as a PDP-11 or a VAX anymore, after all.



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list