On Mar 25, 2013, at 20:35 , Graham Cox <[email protected]> wrote:
> OK, this seems more complicated than my simple-minded attempt so I'll try > with this approach and see how it goes. The environment you describe seems rather similar to software-controlled video playback -- in some ways -- at a fairly high level. The frame decoder would be the analog of your CPU. Other stuff (such as a remote control or front panel emulation) would be the analog of your system of logic gates. On the video side, my experience has been is that it gets very unpleasant when the thread emulating a real-world process blocks. In effect, you're modeling the stopping of time, and that doesn't mesh well with what happens in the real world. (For example, a viewer can pause the video, but needs the remote control to keep working.) You can end up very deep in thread synchronization issues. I think you're better off trying to apply the excellent timing model of your gate emulation to the cpu emulation. I can think of two possible approaches, but I haven't thought them through very far, so they may easily be flawed. 1. Augment your cpu component with emulated logic "circuitry" that provides the cpu with a "data request" output, a delay of n cycles, connected back to a "data ready" input. In this approach, the cpu would only be "advanced" from the outside when its inputs changed, in exactly the same way you described for gates. The main problem to solve would be to have it avoid advancing its *internal* state when "data request" was 1 and "data ready" was 0, but other inputs had changed for unrelated reasons. 2. Attach a timestamp (in units of emulator cycles) to every logic gate, as well as the cpu. This is a slight but perhaps generally useful enhancement to your emulation mechanism. There would be two basic rules for dealing with these timestamps: 2a. When a component processed a change in input by computing new outputs, it would then advance itself "into the future", to <current time>+n. For most logic gates, n would be 1. For the cpu, n might be 1 normally, but something larger when it needs a memory access. 2b. When the emulator looks for components to "advance" in response to a change in input, it would ignore components whose internal time was in the future relative to the current emulator time. Current emulator time could advance one cycle at a time, creeping up on "future" components, or it could actually jump to the earliest future time in any of the components, thus skipping cycles where nothing happens. This would effectively "stop" the cpu while it waiting for a memory access to complete, without forcing the cpu code to implement a "I'm waiting" state internally, and without requiring multl-threading. FWIW _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
