This seems like a lot of complexity for not much gain. Remember, that we don't have to do exactly what the real hardware does. We can have PIC/IO APIC device that handles both modes. While it needs to appear to the OS in the correct fashion, it doesn't need to actually be exactly the same way real hardware is implemented. That level of detail tends to limit the experiments experiments that can easily be done.
Ali On Jan 31, 2009, at 6:04 PM, Gabe Black wrote: > I'm revamping the way I've had interrupt lines implemented in my patch > queue and I have a few questions. > > First I'll describe how it used to (and does in the head) work. > There is > an interrupt "pin" which knows what object it belongs to and what its > index is. To connect the timer to the PIC's second interrupt pin, you > would assign an interrupt pin which is associated with the PIC and had > an index of 2 to the output pin parameter of the timer. The PIC > wouldn't > really know anything about what could poke it to handle an interrupt, > and the originating device didn't have to know anything about what it > was driving. The pin itself would call "signalInterrupt(line)" on the > target device. This works great, except that there's no way to have a > single output drive multiple inputs. That's what's commonly done so > that > interrupt sources are connected to both the ancient PIC the machine > starts up with and the IO APIC it can switch to later. If it does > switch, the IO APIC turns on it's own direction connection and stops > passing along interrupts from the PIC. > > What I want to switch to is more generic and realistic in a couple of > ways. First, I want to get rid of the "signalInterrupt(line)" call > from > the pin object. That semantic basically makes all interrupts edge > triggered because they act like instantaneous events. What I want to > switch to is a pair of functions, "raise()" and "lower()" which simply > propagate that call from a source to a destination. That implies that > the logic which figures out that, say, a 0->1 transition or being > still > set to 1 indicates an interrupt needs to be pushed into code > specific to > a particular device. Second, I want to make it so that an interrupt > source or destination can be connected to an arbitrary number of the > other. > > What I've got so far on the python side is a source pin class, a sink > pin class, and a line class which pairs the two. The idea is that the > line class will represent pairings in python, and then once it's > instantiated in C++ it will connect the two ends. The source pin class > will not be specialized by the thing it's driven by since it's only a > generic vehicle to propagate a signal elsewhere. The sink pins are > more > complicated though. They need to be able to signal the device so > that it > can figure out what a particular transition signifies, but the device > needs to know which of its pins is being wiggled. I could add > "raise(line)" "lower(line)" classes in place of > "signalInterrupt(line)" > on interrupt capable devices, but then I run into problems where it's > not just an PIC with 8 generic lines. If it was something like a CPU > with lint0, lint1, smi, nmi, init, blah blah interrupt pins, it > would be > awkward to assign them arbitrary numbers. > > It would be nice if the line would be able to pull a pointer out of > the > destination object to a pin subclass. It would work sort of like ports > where the port on the receiving side would know how to do all the > fancy > stuff through a generic virtualized interface it's peer could call > into. > I don't want to go into the params stuff an invent a new class of > objects, though, since that seems like overkill. What I was then > thinking is that the pins in python could really just be tokens. The > destination would know which tokens go with which parameter and could > look up for the line which pointer it really wanted when making the > connection. That would involve somehow making the pins uniquely > identifiable. The pointer to a particular pin would identify it, but > that seems like a pretty fragile solution. There could be an auto > incrementing id in the pin object implemented with a metaclass, but > then > I don't know how that would interact with the SimObject metaclass. All > in all, that direction turns into over kill too. > > I'm going to think about this more and see what I can come up with, > but > if anyone has a great idea for how to do this (or part of this) please > let me know. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
