On Mon, Dec 24, Gregor N. Purdy wrote:
> Nicholas --
>
> > Parrot_set_i_i(in,out): \x8b \x0d &IR2 \x89 \x0d &IR1
>
> I'm tempted to push the specification of this information all the way
> back to the syntax of .ops files, since the code that lives there
> should behave the same wrt read/write on args.
>
> Dan likes C-like syntax as much as possible in other parts of the ops
> file. Thats why I chose 'inline' as the tag for 'trivial' ops (although
> that's a C++-ism).
More than one C compiler uses 'inline' as an extension to hint
at inlining code under optimization. As we are effectively defining
our own compiler...
> If we didn't mind the verbosity, a C-like syntax would be:
>
> inline op set(register INTVAL, const register INTVAL) {
> $1 = $2;
> }
>
> instead of
>
> inline op set(i, i) {
> $1 = $2;
> }
>
> The problem is, we lose the nice space/time/etc. saving capability of:
>
> inline op set(i, i|ic) {
> $1 = $2;
> }
FWIW, I like the 'C-ish' version. It makes it accessible to folks
who know C, not a mongrel language which may or may not even exist.
Note that in the last version above, we are _not_ saying that
the second argument is the result of evaluating a bitwise OR
on 'i' and 'ic'.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED] printf "%d", 0x2a;
-- deep thought
