My original intention was actually to represent the ABIs as objects and not
as systems of templates, so that you could do something like this:
ABI abi;
abi->call(foo);
There are a few problems with that though which made it impossible. First,
C++ won't let you have templated virtual methods. It has to know up front
how many slots to make in the vtable, and what should go in each slot in
subclasses. That would mean that you'd have to define categories of inputs
ahead of time like 64 bit ints, float, double, structures, pointers, etc,
etc. The unbounded number of types and the subtle nuances in how an ABI
might handle them would make predefining those categories impossible. For
instance, in the aarch64 ABI, there are special rules for arrays and
structures which have only one type within them which is a type of float,
and have 4 or less members. How you treat structures is also different
depending on if they're bigger or smaller than 16 bytes. There's basically
no chance the types of arguments would be fine grained enough to catch
those differences without knowing about them ahead of time. On top of that,
exactly where things end up on the stack depend on what alignment they
need, and that in turn depends (at least to some extent) on what's inside
them.
Second, you need to know what the signature of the function your calling
is, and there's really no good way to take that apart that I know of other
than templates. If you don't do it that way, it's sort of like making all
your functions take "..." as their only argument. Any system of functions
*can* work that way if you, for instance, premangle the names so
polymorphism works out, but you lose a major source of documentation about
how the function should work/be used.
There are also some things that style (and the existing one-by-one argument
extraction) makes harder than it could be. If, for instance, you have
multiple similar versions of a function which take slightly different
arguments, or that take them in a different order, then might need to have
a central implementation which takes a bunch of flags telling it what
arguments to skip over or read, or what order to extract things in. The
"pipe" system call is like that, as well as "clone".
If your functions just look like functions, you can have:
SyscallReturn cloneFunc(..., Addr a, Addr b)
{
...
}
SyscallReturn cloneBackwardsFunc(..., Addr b, Addr a)
{
return cloneFunc(..., a, b);
}
Since everything is just an argument, you can call using normal C++ from
within gem5 just as easily as you could call from inside the TC, and that
lets you add, replace, remove, or reorder arguments easily without having
to try to tell the main implementation what to do at arm's length.
Aside from the mechanical necessity of templates for this system to work
well, I think the complexity (which is real and worth noting) is actually
not that big a problem since unlike the stats I've made a concerted effort
to explain how they work, and almost everyone who interacts with this
mechanism won't need to worry about how it works down in its guts anyway,
they just need to know how to use it.
For instance, let's say you want to add a new syscall which adds two
numbers together and returns the result. With this new mechanism, that
would look like this:
SyscallReturn
addFunc(SyscallDesc *desc, int num, ThreadContext *tc, int a, int b)
{
return a + b;
}
That looks pretty simple, and you can tell what to do just by looking at
the functions around it without having to use any unfamiliar API to get
your arguments or set your return value.
As a matter of fact, that reminds me I wanted to fold "num" into
SyscallDesc since it's almost never used and makes all the signatures
messier, but that's a bit of a tangent.
Gabe
On Thu, Dec 19, 2019 at 2:09 PM Jason Lowe-Power <[email protected]>
wrote:
> Hi Gabe,
>
> Thanks for the document! This really cleared things up for me.
>
> I made a bunch of comments in the document, but I think they can
> almost all be boiled down to this one thing:
>
> I would like to understand the tradeoff between implementing the ABIs
> as virtual objects vs templates. Generally, I would like to see us
> avoid using templates except in exceptional cases. I think that in
> many cases templates over complicate the code. For instance it's quite
> difficult to understand the code when using variadic recursive
> template functions!
>
> I completely understand the need for a more general ABI
> implementation, and I really like the idea of unifying the syscall,
> pseudo instruction, and other interfaces! I think that what you've
> designed is quite beautiful and very clever. However, I worry that
> it's a little *too* clever, and won't be easy to maintain by other
> developers in the future. Another good example of this in gem5 is the
> statistics interface. That's a block of code that most of us are too
> scared to touch due the template complexities.
>
> That said, if there are required features that cannot be implemented
> by using virtual objects, then I can get behind the template
> implementation. You hint that there are things that can't be done with
> virtual objects at the end of the document. I'd like to understand
> this better before I review the code.
>
> Thanks for the hard work! I think the end goals of this proposal are
> important and I definitely want to see this implemented!
>
> I'm traveling right now, but I'll do my best to keep up with this
> thread and reply in a timely manner.
>
> Cheers,
> Jason
>
> On Thu, Dec 19, 2019 at 3:41 AM Gabe Black <[email protected]> wrote:
> >
> > I made another editing pass and made a few small changes which hopefully
> > will make things easier to understand.
> >
> > Gabe
> >
> > On Wed, Dec 18, 2019 at 6:51 PM Gabe Black <[email protected]> wrote:
> >
> > > Ok, great, thanks. I know the implementation is heavy on C++ sorcery,
> so
> > > please let me know if you have any questions.
> > >
> > > Gabe
> > >
> > > On Wed, Dec 18, 2019 at 6:20 PM Jason Lowe-Power <[email protected]>
> > > wrote:
> > >
> > >> I'll have some time tomorrow to look it over.
> > >>
> > >> Cheers,
> > >> Jason
> > >>
> > >> On Wed, Dec 18, 2019 at 4:06 PM Gabe Black <[email protected]>
> wrote:
> > >> >
> > >> > Great, thanks!
> > >> >
> > >> > Gabe
> > >> >
> > >> > On Wed, Dec 18, 2019 at 5:04 PM Giacomo Travaglini <
> > >> > [email protected]> wrote:
> > >> >
> > >> > > Thanks Gabe, I am reviewing the document, will address your
> patchset
> > >> as
> > >> > > soon as I finish
> > >> > >
> > >> > > Giacomo
> > >> > > ________________________________
> > >> > > From: gem5-dev <[email protected]> on behalf of Gabe
> Black <
> > >> > > [email protected]>
> > >> > > Sent: 18 December 2019 02:05
> > >> > > To: gem5 Developer List <[email protected]>
> > >> > > Subject: [gem5-dev] Guest ABI design doc
> > >> > >
> > >> > > Hi folks. I talked to some people and got permission to share this
> > >> design
> > >> > > doc externally first. Please take a look to when you get a chance.
> > >> > >
> > >> > >
> > >> > >
> > >>
> https://docs.google.com/document/d/1CvB_srNAXXi6JgU8Q8Ou0tEcAv4DXdulhNj8kxowFkk/edit?usp=sharing
> > >> > >
> > >> > > Gabe
> > >> > > _______________________________________________
> > >> > > gem5-dev mailing list
> > >> > > [email protected]
> > >> > > http://m5sim.org/mailman/listinfo/gem5-dev
> > >> > > IMPORTANT NOTICE: The contents of this email and any attachments
> are
> > >> > > confidential and may also be privileged. If you are not the
> intended
> > >> > > recipient, please notify the sender immediately and do not
> disclose
> > >> the
> > >> > > contents to any other person, use it for any purpose, or store or
> > >> copy the
> > >> > > information in any medium. Thank you.
> > >> > > _______________________________________________
> > >> > > gem5-dev mailing list
> > >> > > [email protected]
> > >> > > http://m5sim.org/mailman/listinfo/gem5-dev
> > >> > _______________________________________________
> > >> > gem5-dev mailing list
> > >> > [email protected]
> > >> > http://m5sim.org/mailman/listinfo/gem5-dev
> > >> _______________________________________________
> > >> gem5-dev mailing list
> > >> [email protected]
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >
> > >
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
