[Info-vax] Platform Migrations

[Arne Vajhøj]

On 12/30/2018 4:33 PM, Stephen Hoffman wrote:
> On 2018-12-29 22:22:45 +0000, Arne Vajhj said:
>> On 12/29/2018 4:46 PM, Stephen Hoffman wrote:
>>> And as the character encoding... The lack of UTF-8 is limiting.  As 
>>> is the lack of flagging on the descriptors.  I have to track my own 
>>> string encoding.
>>>
>>> VAX, Alpha or Itanium are unlikely to see any work on UTF-8, and 
>>> certainly not until well after the x86-64 port and a pile or three of 
>>> other work is completed.
>>
>> But for some things (user mode things like UTF-8 support) wouldn't it 
>> be easier to make changes to both x86-64 and Itanium (and maybe Alpha) 
>> instead of making them x86-64 only?
> 
> Easier in some ways?  Sure.  Definitely.  In others?  Implementing for 
> and testing code across multiple architectures adds incremental effort 
> and costs and time.  Not the least of which is new releases of OpenVMS 
> for the platforms.
> 
> And ponder why this support might or might not be appropriate, too. I've 
> had a working assumption that new Itanium HPE Integrity i6 server 
> availability will end in 2020, though the end of new sales has not been 
> officially announced.  In ~2025 or whatever timeframe this hypothetical 
> UTF-8 work might eventually be completed, are we really going to be 
> expecting very much of then-old Itanium servers?  And would this and 
> other architectural back-ports really serve to reduce the incremental 
> sales value of OpenVMS on x86-64?  Or will VSI be working on Intel and 
> x86-64 changes, on adding support for SGX and MKTME and follow-ons, and 
> on peripheral support?   Or will VSI be pondering a port to Arm and 
> AArch64?
> 
> Seeing a hard fork akin to what happened with VAX to Alpha would not 
> particularly surprise me, with the eventual advent of OpenVMS x86-64 
> native builds rather than the current cross-builds.  (There's at least 
> one CMS export git import tool around, too.)

Let us say that full character set support get added in version 10.0
(whether that full character support will be UTF-8 internal and external
or UTF-16 internal and default UTF-8 external is another question).

If 10.0 will be released on I64 (and maybe Alpha) then I don't see
any point in not adding the full character set support to those.

code fork => lots of duplicate work
no code fork and in x86-64 but not in I64 => extra test on I64 to test 
that the other changes works without
no code fork and in all platforms => test on I64

I still don't see much point in not including it.

If 10.0 will not be released on I64 then the problem goes away.

Arne