On Sat, Aug 27, 2011 at 12:12 AM, Mike Stump <mikest...@comcast.net> wrote:
> 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.
Maybe you can even post the code somewhere?
Richard.
