B5500, I701, I704, I7010, I7070, I7080, I7090: Remove single UNIT DISABLE#327
B5500, I701, I704, I7010, I7070, I7080, I7090: Remove single UNIT DISABLE#327markpizz wants to merge 1 commit intorcornwell:masterfrom
Conversation
…ABLE
If a simh DEVICE has the DEV_DISABLE flag set AND it has 1 UNIT,
there really should never be a UNIT_DISABLE flag bit in the UNIT
initializer. The reason for this is that, for many things, the DEVICE
name can be used equivalently to represent the single UNIT.
What are we trying to achieve here?
- If the DEVICE is disabled, then the unit doesn't exist. That's fine.
- If the UNIT is disabled (if the UNIT_DISABLE flag is present allowing
SET <unit> DISABLE) what would that then mean about the DEVICE?
Bob Supnik's thoughts:
The rationale was that the device represents the controller logic, the
unit the physical transducer. So you could disconnect or power down
a paper tape reader, but its controller logic would still be there and
would still respond in some way.
Mark Pizzolato said:
If the fidelity to the hardware in simulation really behaved precisely
as the hardware worked, maybe, but I doubt that this has been a design
goal. Even if it had been a design goal, I see 2 issues:
a) it would seem that it would have been impossible to produce exactly
the failure details that real hardware did without a crazy amount
of side by side testing.
b) What good would be having a broken device like this connected to a
simulated system?
|
I'm going to reject this patch since it does not serve any purpose. |
|
It removes the option to day "SET DISABLE" for devices which have a single UNIT.
Certainly, DEVICEs with multiple UNITs could still be useful if some of their UNITs are non-existant, but otherwise, how will you be able to tell precisely how the running simulated system would be able to see exactly what the original hardware saw when the single UNIT is disabled? Notice the duplicate SET CP ENABLE SET CP DISABLE options. |
|
I don't care who's name is on the commit, but I think it is a good idea to remove the potential ambiguity in the example I showed. Precisely the same issue exists for every other device that has this trivial change in the PR. |
|
Right now I am knee deep in microsim360. Trying to get reference IBM360 so I can finish my simH IBM360. I still see this patch as cosmetic. |
|
It absolutely is cosmetic, and was a result of a complaint about the cosmetic information provided by the HELP output, which, at best, wasn't consistent and the multiple cases were confusing and didn't have the expected information for the user. Such information should be correct. |
If a simh DEVICE has the DEV_DISABLE flag set AND it has 1 UNIT, there really should never be a UNIT_DISABLE flag bit in the UNIT initializer. The reason for this is that, for many things, the DEVICE name can be used equivalently to represent the single UNIT. What are we trying to achieve here?
If the DEVICE is disabled, then the unit doesn't exist. That's fine.
If the UNIT is disabled (if the UNIT_DISABLE flag is present allowing SET DISABLE) what would that then mean about the DEVICE?
Bob Supnik's thoughts:
The rationale was that the device represents the controller logic, the unit the physical transducer. So you could disconnect or power down a paper tape reader, but its controller logic would still be there and would still respond in some way.
Mark Pizzolato said:
If the fidelity to the hardware in simulation really behaved precisely as the hardware worked, maybe, but I doubt that this has been a design goal. Even if it had been a design goal, I see 2 issues:
a) it would seem that it would have been impossible to produce exactly
the failure details that real hardware did without a crazy amount
of side by side testing.
b) What good would be having a broken device like this connected to a
simulated system?