[Simh] BBS/C behavior [was Re: Needed: RH750 specification]

[Bob Supnik]

On 8/12/2015 12:00 PM, simh-request at trailing-edge.com wrote:
> Message: 1
> Date: Wed, 12 Aug 2015 09:03:41 -0400
> From: Timothe Litt<litt at ieee.org>
> To:simh at trailing-edge.com
> Subject: Re: [Simh] Needed: RH750 specification
> Message-ID:<55CB442D.5010200 at ieee.org>
> Content-Type: text/plain; charset="utf-8"
>
> For the non-"SRM lawyers":  the short(er) form of my long reply:
>
> 1) Yes, SimH needs to match the 750's behavior.
Agreed. That's why I want to know what the 750 did for real, not guess 
at it.
>
> 2) No, the SRM doesn't tell you how to do it.
I'll disagree here, but I don't have sufficient evidence that every 
system (except the 9000) did it the way I describe. I have checked all 
the VAX chip microcode listings, including NVAX; they all issue a read 
of byte length. The 780 is the same. However, I don't have microcode 
listings for MicroVAX I, 730, 750, 8600, or 8800.

The point is moot for memory. For BBx, which is read only, memory can't 
detect the kind of reference used, it doesn't matter. The write back in 
BBxy{I} does have to be precisely one byte, because the VAX supported 
byte granularity of sharing.
> 3) The*code*  in question violates the SRM because this instruction is
> not allowed to reference I/O space.
Yes, but as you point out, it works, as did the BLBC to Qbus space in 
Ultrix. That too is outlawed by the SRM (only byte and word references 
allowed), but it worked on real hardware, and I ended up rewriting all 
of the unaligned memory access routines to get it to work per the hardware.
>
> 4) Exactly how the instruction is implemented when the operand IS in
> memory can differ from the literal SRM text, as long as the programmer
> sees results AS IF the SRM text was followed literally.  Which is hard
> because the text is somewhat confused.  But memory behavior is fairly
> flexible.  Attempting to apply this to I/O space gets complicated,
> because I/O space has special characteristics and rules. (This is why
> there are restrictions on which instructions can be used.)
>
> What SimH does now is SRM-compliant.  It's just not useful in that the
> hardware does something different.
>
I would prefer to say that SimH 750 is inaccurate. It's rather broad to 
label SimH, or even SimH VAX, as not useful.

The question of where the 750 simulator is inaccurate is easily tested 
on real hardware. Try

BITB #1,aligned_massbusadapterregister

If there's a trap, exception, or interrupt, then the implementation of 
BBx is wrong for the 750. If there's none, then the Massbus adapter 
doesn't validate operand lengths, just like its Unibus counterpart.

/Bob