[Info-vax] Roadmap

[Craig A. Berry]

On 1/3/19 12:32 PM, Simon Clubley wrote:
> On 2019-01-03, gezelter at rlgsc.com <gezelter at rlgsc.com> wrote:
>> On Wednesday, January 2, 2019 at 9:51:03 AM UTC-5, John Reagan wrote:
>>> On Tuesday, January 1, 2019 at 8:26:51 PM UTC-5, Richard Maher wrote:
>>>>
>>>> And you added that new/optional parameter to math$random right?
>>>
>>> I'm not falling for that again...  The last time I suggested such a thing, I got schooled in PRNGs.
>>>
>>> Seriously, we've been talking about PRNGs, entropy pools, OpenSSL, etc.  Having access to the underlying x86 instructions (either as C builtins, new MATH$ entry points, enhanced MATH$ entry points, etc.) will be a part of that.
>>
>> John,
>>
>> My recommendation would be for an essentially "flat" port, with changes deferred to a later point.
>>
> 
> The problem with that is that while it can apply to much of VMS,
> security is an ever changing goal and VMS needs various things
> to be fixed as soon as possible.
> 
> I would also hope VSI isn't exclusively using the Intel hardware
> generator by default for security critical functionality.

There are also cases where staying flat means writing a lot of code for
a different platform.  Long doubles might be one of those cases.  If
they stay with T_FLOAT (which I suspect they will for compatibility),
they can't necessarily just use the same software emulation they had for
Alpha (maybe, if it was written in C, but obviously not if it was Alpha
assembler).  Compiler switches that make optionally available the 80-bit
long doubles more familiar to x86 users might be nice, but that would be
front-end changes they're unlikely to have time for now.