[Info-vax] Roadmap

[John Reagan]

On Thursday, January 3, 2019 at 2:45:30 PM UTC-5, Craig A. Berry wrote:
> On 1/3/19 12:32 PM, Simon Clubley wrote:
> > On 2019-01-03, gezelter <> 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.

Ugh, "long double"...  We had yet another discussion about that today.

The 128-bit support we have is written mostly in C but GEM knows it and does some operations inline.  clang/LLVM can do the "leave a 128-bit hole but put an 80-bit float in it" just fine.  If we want to retain our full 128-bit floating, we would just deal with it like we do with COBOL packed decimal (ie, call RTL routines for every operation) but we would need additional RTL routines.  Or use T_FLOAT in a 64-bit hole (our current behavior for the C cross-compiler) or T_FLOAT in a 128-bit hole or ...

Fortunately it isn't needed for first boot and later clang/LLVMs have better support.  We'll probably wait until we bootstrap native to make a final decision.

And would we need some support to convert the 128-bit binary format into the 80-bit format in CVT$CONVERT_FLOAT and CVT$FTOF routines?

If somebody has a strong opinion, write it on the back of a $100 bill and send it to me.