Because functions can't be treated like ports and so have to be special cases? That's what we already have, and it doesn't work very well. Right now we can group SimObjects together, but we can't treat them like a unified thing, they're just a bunch of parts strapped together which still have to be dealt with individually, or through special case code. Export would (hypotehtically) be the name of the type, not the object. It's just like how "Port" isn't very descriptive, but actual ports have descriptive names.
Gabe On Thu, Mar 18, 2021 at 7:40 AM Jason Lowe-Power <[email protected]> wrote: > Hi Gabe, > > Why have a new special "port" and not just a function (e.g., connectCPU or > connectMemory depending on if you're CPU or memory-side focused)? > > I would strongly prefer to have descriptive names and not something like > "Export" which could mean many things. > > Jason > > On Wed, Mar 17, 2021 at 9:05 PM Gabe Black via gem5-dev <[email protected]> > wrote: > >> Hi folks. I've been thinking about a new type of port which only exists >> in python, and which just proxies for another port which belongs to some >> other object. If you're familiar with systemc, I think this is pretty >> similar to the "export" object. The major use case for this would be to, >> for instance, add some to a SubSystem class (which is nothing but a blank >> box to hold other things) to expose ports within the SubSystem without >> having to dig around inside it. For instance, if you have a CPU complex >> with internal structure, you might want to wrap it all in a SubSystem and >> add a port for data, instruction, cached, uncached, etc. That would provide >> a lot more uniformity between CPUs, and help avoid having special little >> methods to hook up ports or say what port to use when connecting to a bus. >> >> The name is a little tricky since port proxy is already a well known >> thing. Maybe just Export? That name has precedence, but I've always thought >> it wasn't immediately clear what it was. >> >> Gabe >> _______________________________________________ >> gem5-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > >
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
