[Info-vax] LLVM, volatile and async VMS I/O and system calls

[Stephen Hoffman]

On 2021-10-03 12:35:45 +0000, chris said:

> On 10/03/21 01:32, Stephen Hoffman wrote:
>> Previous ports have shown weird bugs, those latent in the existing 
>> codebase that was ported, those bugs introduced by the platform tools, 
>> and those exposed by (for instance) updated processors of the same 
>> architecture. q.v. SRM_CHECK.
> 
> Perhaps rewritten was the wrong word, so ported ?. Even so, would 
> suspect a lot of the low leve stuff (which this thread is about) must 
> have been rewritten as part of the porting effort.

Ah, moving the goalposts.

The lowest reaches—a small but gnarly part of any operating system 
platform—is different, yes. Hardware config and boot and errors, memory 
management, interlocking, code generation, etc. Alas, bugs are not 
constrained to those lowest reaches.

BTW, EV6 broke latent (and architecturally incorrect) code-generation 
assumptions within the GEM compiler code generator. Assumptions that 
had worked fine on OpenVMS and on Alpha processors prior to EV6. This 
code-generation error is what SRM_CHECK detected. This old EV6 
code-generation bug is entirely reminiscent of what Simon is concerned 
about with x86-64 code generation, too.

>> Hyrum's Law: With a sufficient number of users of an API, it does not 
>> matter what you promise in the contract: all observable behaviors of 
>> your system will be depended on by somebody."
>> 
>> And some of us would be interested in some Arm waving too, but for now 
>> it's all x86-64 waving.
> 
> Very much so, but needs an available standard platform in volume to 
> make it worthwhile for sw vendors to get behind it...

Hyrum applies to most any complex system, software or hardware. It's 
part of what can make changing OpenVMS or any other upward-compatible 
platform so entertaining. A cluster-related change to the queue manager 
job ID allocation algorithm blew up a number of apps, for instance. 
Lots of other examples.

> Really hard to break the X86 stranglehold...

As with past market shifts, shifts usually arise from below. Not from 
above. Shifts can progress slowly for a decade or two. Then can 
progress much more quickly.

As for x86-64, the ~fourth largest computer vendor by revenue (2020) 
has invested heavily in and is migrating all of its laptops and 
desktops off of x86-64 processors. Whether and how many customers might 
accept that?

Are we in a shift? Donno. Maybe. Intel would certainly prefer not. 
Microsoft too would probably prefer not too, their previous boutique 
platform port investments, and their more recent Windows 11 ARM64 and 
ARM64EC and related efforts, aside.

But as for OpenVMS, yes, getting native compilers working and reliable 
and with decently-performing app code being generated is the 
prerequisite. OpenVMS usually ends up needing some architectural tweaks 
or extensions or other workarounds too, and some of those have been 
mentioned by VSI.

On the plus side for the upcoming and entirely hypothetical OpenVMS Arm 
port, LLVM already generates code compliant with Armv8-A and Armv9-A 
designs.

Trivia: VSI has previously discussed an Arm port, though not in some 
years. VSI seemingly have several more years before the current x86-64 
port work, and VSI and third-party and end-user apps, are all 
sufficiently available and are entering volume production on x86-64 
servers. We should have a better idea of what is happening with x86-64 
and Arm by then, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC