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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
