On Aug 26, 2011, at 7:19 AM, Michael Meissner wrote:
>>> The alternative is something like what Kenney and Mike are doing in their
>>> private port, where they have new syntax in the MD file for builtins.
>>
>> But are those user-exposed builtins? Certainly interesting to combine
>> builtin definition and the instruction it expands to.
>
> Yes, these are user exposed builtins. Massive amounts of user exposed
> builtins
> (Mike said he needs 13 bits for the builtin index). I think it would be
> better
> if Mike comments on this.
I gave the quick intro yesterday. You wind up specifying the built-ins that
you have, and the generator does things like assign enum values, create a file
that appears the builtins into the user name space from the __builtin_
namespace, generate compilation test cases for all the built-ins with all
different types they support. Generate executable testcases to ensure
everything works flawlessly. We have mods to the overload builtin mechanism so
that one can do things like:
template <class T>
T foo(T x, T y) {
x = add(x, y);
return x;
}
Or, if you perfer the C version:
int fooi(int x, int y) {
return add(x, y);
}
short foos(short x, short y) {
return add(x, y);
}
and have it work out just fine when T is instantiated with all the various
types that are supported by the hardware, and it works in C. This permits a
nice api for the machine builtins, as you don't have to mangle in types into
the builtin-name. The system is complete enough to handle the needs of
anything coming down the pike in the next decade. It can handle input/output
parameters that have register assignments. It can handle reference parameters
(like the input/output parameters, but these are done as values in memory. The
generator builds up _all_ the types one needs, handles all the registration and
all the wiring up for codegen. There is a mechanism to remap arguments going
to the rtl generators, so the operand ordering of the builtin doesn't have to
match the operand ordering of the md pattern for the semantics that back the
builtin. There is a beefy macro system built into the generator so that you
can have nice simple patterns and it is beefier than the iterators one can use
today. So, for example, we have:
(define_special_iterator imath3 [add sub mul])
to define some built-ins that are regular with respect to the operation, but,
this isn't a code nor mode iterator, it just iterators the pattern with the
string substituted. For machines with any regularity, the patterns wind up
being smaller and easier to maintain. I'd be happy to answer questions about
it.
