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
