On 8/12/2015 12:00 PM, [email protected] wrote:
Message: 1
Date: Wed, 12 Aug 2015 09:03:41 -0400
From: Timothe Litt<[email protected]>
To:[email protected]
Subject: Re: [Simh] Needed: RH750 specification
Message-ID:<[email protected]>
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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
