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

[Arne Vajhøj]

On 8/3/2020 5:10 PM, onewingedshark at gmail.com wrote:
> 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.
Changing is a positive not a negative.

What people expect from their compilers change as standards evolve
and new languages arrive.

VSI needs something that keeps up.

> 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.
DEC compilers were very good 40 years ago.

But times has changed since then.

>> Having VMS specific compilers will result on either compilers
>> 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.
I did not see anything in that which would provide C++ 14, C++ 17,
Rust, Julia, Swift etc. and what else people want today.

Arne