[Info-vax] How far away is first boot ?

[John Reagan]

On Wednesday, May 8, 2019 at 1:24:12 PM UTC-4, Dave Froble wrote:
> On 5/8/2019 10:23 AM, John Reagan wrote:
> > On Wednesday, May 8, 2019 at 8:22:20 AM UTC-4, Simon Clubley wrote:
> >> On 2019-05-08, clair.grant <> wrote:
> >>> On Wednesday, May 8, 2019 at 12:55:24 AM UTC-4, Simon Clubley wrote:
> >>>> I am curious how far away VSI thinks first boot probably now is.
> >>>>
> >>>> Is it hours/days/weeks/whenever John fixes the Macro-32 compiler ? :-)
> >>>>
> >>>
> >>> No idea.
> >>>
> >>> We had a big set back thinking the system disk was mounted when it really wasn't. After a long slog of over a week, that is fixed now. Running in 64bit space continues to bring out the need for a change now and then. And, yes, compiling the MACRO32 code will always be challenging, enough said. As Mike points out, we can do a bunch of stuff in DCL but the acid test of
> >>>
> >>
> >> Thanks to Clair and Michael for the update.
> >>
> >> It's nice to see things slowly coming along.
> >>
> >> Thanks,
> >>
> >> Simon.
> >>
> >> --
> >> Simon Clubley,
> >> Microsoft: Bringing you 1980s technology to a 21st century world
> >
> > Here's an example of the latest bug (which we initially thought was a Macro compiler bug)
> >
> > CMPL R22, R2
> > BGTRU bugcheck
> >
> > It went the "wrong" way vs Alpha or Itanium.  We stared at the code and the x86 instructions look perfectly fine but it still took the error branch.  Looking closer at the code, the CMPL in the .MAR file has been backwards since 1991 and worked by "accident".
> >
> > R2 was previously used to put a BYTLM in the high longword and a BYTCNT in the low longword (for some reason that escapes me).  On Alpha and Itanium, the compiler uses 64-bit compares (or 64-bit subtracts) so R22 could never be GTRU than R2 (these are all positive numbers).  On x86, there is perfectly good 32-bit compare instruction which sets the condition codes.  So the BYTLM in the upper 32-bits isn't an issue, the comparison was done, the branch to the bugcheck was taken.  The fix is to the Macro-32 source file to swap the CMPL operands.
> >
> > Yet one more example of how Macro-32 (or any assembly code) comes with additional risks and requires a higher-level of skill.
> >
> 
> Interesting, to me.  Probably frustrating to you.  So, another question 
> to give you nightmares.
> 

I actually sleep surprisingly well.