<div>Bob is quite right about the problem only occurring under specific circumstances. It appears to me that the problem lies with the version of the gnu C compiler that comes with CentOS 5.5, and we can hardly ask the maintainers to fix it since the latest version seems to work just fine.</div>

<div> </div>
<div>Ironically, I use CentOS because it is a robust system.   <img style="MARGIN: 0px 0.2ex; VERTICAL-ALIGN: middle" src="cid:33D@goomoji.gmail" goomoji="33D"></div>
<div> </div>
<div>Peter Allan<br><br></div>
<div class="gmail_quote">On 3 January 2011 17:47, Bob Supnik <span dir="ltr"><<a href="mailto:bob@supnik.org">bob@supnik.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Well, the 780 microcode is complicated and patched to fare-thee-well, but it uses absolutely common code for the tests on P0BR and P1BR.  [The PDFs are on line at Bitsaver.]  Based on the comments, the actual tests are:<br>
<br>1) Offset P1BR by 0x800000 (2**23).<br>2) Test PxBR<1:0> = 0.<br>3) Test PxBR<31> = 1.<br>4) Test PxBR<30> = 0.  [this is missing in SimH]<br><br>For SBR, it's:<br><br>1) Test SBR<1:0> = 0.<br>
2) Test SBR<31:30> = 0. [this is missing in SimH]<br><br>So while SimH may not be SRM conformant, it follows the 780 microcode more or less faithfully; in particular, by using a common macro for testing P0BR and P1BR.  Remember, SimH is a hardware simulator, not an architectural simulator.<br>
<br>So I would venture that the "right" formulation of these tests is:<br><br>#define ML_SBR_TEST(r)  if ((r) & 0xC000003) RSVD_OPND_FAULT<br>#define ML_PXBR_TEST(r) if ((((r) & 0x80000000) == 0) || \<br>
                           ((r) & 0x40000003)) RSVD_OPND_FAULT<br><br>Of course, you can throw in whatever casts, etc, you want to add to make the code 64b proof; and also the != 0 that good C coding seems to imply these days:<br>
<br>#define ML_SBR_TEST(r) if (((uint32)(r)) & 0xC000003u) != 0) RSVD_OPND_FAULT<br>#define ML_PXBR_TEST(r) if (((((uint32)(r)) & 0x80000000u) == 0) || \<br>                           (((uint32)(r)) & 0x40000003u) != 0)) RSVD_OPND_FAULT<br>
<br>The ANSI C standard says that hex constants are unsigned by default, so I really don't think all the u's are needed.<br><br>Remember, the problem is unique to one version of the C compiler, with CentOS 5.5.  It works everywhere else.<br>
<font color="#888888"><br>/Bob<br></font></blockquote></div><br>