On 09/26/11 18:14, Gabriel Michael Black wrote: > Quoting Ali Saidi <[email protected]>: > >> On Mon, 26 Sep 2011 14:24:12 -0700, nathan binkert <[email protected]> >> wrote: >>>> >>>> The bottom line is that I think Platform is mostly historical, but >>>> I don't >>>> know the history, so maybe for starters someone like Nate or Ali >>>> could bring >>>> me up to speed... >>>> >>> >>> I believe that there is no good reason for Platform to be separate >>> to System >>> and I think that we should do as you say and have a System object >>> that does >>> both. >>> >>> Nate >> The reason for the platform is to separate the ISA from the >> implementation of the hw implementation that runs that ISA. For >> example if we think back to turbo laser, tsunami, alpha, linux and >> tru64. We have AlphaSystem, and then AlphaLinuxSystem and >> AlphaTru64System for the two operating systems. The platform provided >> an interface to interrupts and i/o so you could build a tsunami >> system that booted Linux or Tru64 or a Tlaser system that booted >> either. Otherwise there isn't a clear object hierarchy that can be >> built (some combination is going to result in a lot of code >> duplication).The Tusnami and the TLaser system had very different >> ways of handling interrupt and the translating memory for DMA, so >> there needs to be some specialization. >> >> Ali >> >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > Yeah, I think this is right. The platform object is a hub for the > hardware aspects of a machine, and the system object is a hub for the > software aspects. You can have Linux on platform X, Solaris on > platform Y, etc., and by having two halves to stick together then you > can mix and match without having to have a cross product of classes > with gobs of duplication. The problem I'm solving here is to remove > the bidirectional linkage between a system object and a platform > object. In SE mode, there are software components but (probably) no > hardware components perse. > > Gabe > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
To expand on this more, while I think something needs to serve the role of the platform object and that it shouldn't be the system object, I also think we should design out the platform object. It really has two roles right now, to forward interrupts from devices to the CPUs through an interrupt controller object, and to handle PCI address spaces and devices. The interrupt handling could be done directly by the interrupt controller by extending the system I have for x86 to all ISAs (local routing through "wires" with up/down state) and then sent up to the CPU through the memory system. The PCI aspect could be managed by a PCI controller object, which actually seems like a better reflection of real systems on top of being more modular. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
