[Info-vax] Future comparison of optimized VSI x86 compilers vs Linux compilers

[Stephen Hoffman]

On 2020-08-03 21:10:51 +0000, onewingedshark at gmail.com said:

> On Monday, August 3, 2020 at 12:40:31 PM UTC-6, Arne Vajhøj wrote:
>> On 8/3/2020 2:34 PM, onewingedshark wrote:
>>> 
>>> Here's a question: how hard would it be to simply [re]write the 
>>> code-generator for the GEM-compilers to do VMS x86? Yes, I realize 
>>> there's a lot of hype around LLVM, and it would be nice to get the 
>>> optimizations, but this should be weighted against what you have now.
>> 
>> I think VSI strategically wants to get on LLVM.
>> 
>> Modern compilers are very complex pieces of software. And for some 
>> languages they are relative fast evolving software.
> 
> This is madness.
> It's literally building in dependencies to things which are still 
> changing, much like the idiocy of "living standards" your full 
> implementation can be completely undermined by the "living standard" 
> making some sweeping change.

Welcome to modern computing.

We're doing less bespoke code and targeting that work where we can make 
the biggest differences, and we're doing far more software integration 
work, and the software projects are increasing in size and many are 
vastly larger than they once were.

Yes, VSI does get to try to reduce the associated UI churn to their 
developers and users, if the folks at VSI get the time to address the 
various UIs. I've previously mentioned networking UIs as an area that 
sees churn, whether it's DECnet or TCP or IPv6 or TLS or SCS or such. 
That could well be abstracted, and that can provide a path for folks 
using DECnet or non-TLS IP to move forward to secure and authenticated 
connections, whether that's TLS, maybe IPsec, or otherwise, and over 
IPv6.

But there will be some software churn and some API if there are to be 
fixes and updates, because whoever promised the OpenVMS folks 
compatibility neglected to mention the limitation and insecurity 
inherent in that approach. Software and networking and server designs 
evolve. The designs and implementations have to change and change 
incompatibly, as the tech and the scale and the expectations and the 
servers all change. And the apps get to contend with and adopt these 
changes. You cannot return 16 or 32 bytes of data into an 8-byte 
app-embedded buffer, you need dynamic sizing and/or objects.

> Also, VSI has access to some very good compiler technology, albeit 
> somewhat dated (GEM), and once world-respected implementations like DEC 
> Ada. -- IMO, They should play to these strengths first.

GEM is more than slightly dated, and the code generation you're focused 
on is just a rounding error in the entirety of the current expectations 
around tooling and IDEs.

And for this GEM "renaissance", you're suggesting a staffing and 
scheduling investment that's would require re-assigning a substantial 
part of the entire current VSI development team, if not outright 
doubling the size of the VSI development team for the added work, and 
these new folks for development tooling, and with probably a decade of 
effort and updates before reaching parity with what LLVM offers now. 
That includes code generation and debugging across a whole pile of 
x86-64 processors and generations, and adding the run-time support 
necessary for newer versions of the languages and tools, as the newest 
of the current GEM-based compilers are ~twenty years outdated. We 
*just* got most of C99 on OpenVMS. In 2019. I'm routinely bumping into 
source code that's dependent on C11. And in that same decade, LLVM 
features and capabilities and expectations will have moved forward. 
Probably more quickly.

>> Having VMS specific compilers will result on either compilersc falling 
>> behind or VSI bleed out of money to fund the work.
>> 
>> Hooking into an external toolchain like LLVM is the only way VSI can 
>> afford uptodate compilers long term.
> 
> No, it's really not.
> Look at the last option I gave; there's zero LVMM there. Granted, it 
> would force other compiler implementers to either do what they're doing 
> now [porting LLVM], or port their own architectures.

We're in an era when very few vendors can competitively differentiate 
based solely on compiler tooling. And the era of the 
edit-compile-link-run-debug loop is fading. OpenVMS folks tend to have 
less familiarity with IDE usage, but that's shifting. And emitting 
Bliss or C as an intermediate language is amusing as a proposed 
solution, but then I've worked with that approach.




-- 
Pure Personal Opinion | HoffmanLabs LLC