Philosophical question re IOTs

[Bill E]

My dynamic IOT impl simulates async behavior by allowing an IOT to say it wants to be polled every 1-N instruction cycles. However, the polling is only done when the -1 is in run state. My question, should the polling happen regardless of machine state? After all, something like the drum doesn't stop spinning just because the processor is halted.

Maybe let an IOT specify?

Comments welcome,

Bill

[Glenn Babecki]

I haven't studied the PiDP-1 or your drum simulation, or the background details of a real PDP-1 so the following response could be missing something.  But why should I let that stop me from postulating the following scenario that I think your trying to cover (just cause it's an interesting question).

Since your drum implementation is all software, I can see the following scenario supporting your thinking to essentially "separate" the drum operation from the state of the CPU.  Suppose a request was made to the drum to read or write some data and after the request the CPU was stopped for some reason.  I think it appropriate that any status changed posted by the drum hardware simulation be cached or "latched" so that when the CPU operation resumed it could read the updated state of last drum operation.  This might be a possible scenario if you separated the drum simulation from the CPU.

However, I could also argue that the drum operation is really contained within the overall simulation cycle and thus no need to separate the asynchronous operation of the drum.  The only behavior I can think of that would be possibly affected is the number of wait cycles for data access (i.e., drum virtually continuously spinning vs. start/suspended/continue).

Again, I could be way off base about how the original hardware worked or current simulation is intended to work.  I would imagine there are other simulated devices that would encounter similar events sequences.  Just a thought off the top of my head so take it with a gram of NaCl.

--
You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/52efa52d-7dd8-4b35-99c1-3d6be3137720n%40googlegroups.com.

[Bill E]

The drum rotation is exactly the issue that got me thinking about this. In the grand scheme of things, it really makes no difference other than being perhaps a bit too obsessive about an accurate reproduction. The real drum also did dma using the high speed channel hardware. I don't know if that halts on a processor halt, but I suspect not. Otherwise, the drum would rotate out of sync with the transfer. But again, won't affect my simulation, because there is no actual drum. I do simulate the dma cycle time, so it would be inaccurate also, but still work just fine.

However, it now comes up in my new socket IOT. If the processor is halted, no reads will be done on the sockets. Halted long enough, the connections could time out. OTOH, even so, the local buffers could get filled up, so maybe this isn't important either.

I guess I should just leave well enough alone.

Bill

[Glenn Babecki]

Yeah this simulation stuff can make you crazy obsessive (not you specifically 😉).  It can make you just want to recreate the actual device, which is not often practical.  Just do what seems reasonable. 👍🏻

--

You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/b6b44938-8d04-46d2-8c99-1892c8e7098bn%40googlegroups.com.