[Simh] A few more possible bugs found

[Michael Bloom]

I guess I should have looked more closely and skipped this "possible 
bug".  I had mistakenly assumed it to be the same "possible bug" as in 
Ea_ch(),  but it is not.

What bugged me was the result of a non-bitwise operation being used as 
an operand to a bitwise operation.  It can only be a bug if the objects 
are two or more bits wide, which is the case in pdp1_cpu.c (where the 
object being logically inverted is 16 bits wide).  But since only one 
bit is cared about in this case, nothing is lost, so it's OK.

- michael

On Wed Mar 21 at 01:41:35 EDT,  J. David Bryan wrote:

 > 5) In pif_io(), in HP2100/hp2100_pif.c
 > At the line
 >         setIRQ (select_code, !pif_control & pif_flag & pif_flagbuf);
 > Is it really intended to use a boolean value with a bitwise operator?

To which boolean value are you referring?  The three "pif" variables are
enums (compatible with int) with values of 0 or 1, the logical negation
produces an int, and ANDing produces an int, which is what is desired.

(The hardware modeled is a three-input AND gate with one input inverted.)


 > (should ~ have been used instead of !

! produces 0 or 1, which matches one of the enum values.  ~ produces a
value that is not one of the enum values.

In practice, though, only the LSB matters for setIRQ(), so they'd be
effectively equivalent.


 >  or perhaps parenthesis added to make it clearer?)

I'm not sure I see where you'd add the parentheses.  Around !pif_control?

                                       -- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120321/b8467c12/attachment-0002.html>