Jason --
> Making the distinction between the three cases enables a number of
> optimizations of native code based on analysing data flow. 'in' would be good
> as an implicit default, as many PMC opcodes will not overwrite any PMC
> registers.
>
> An optimizing native code generator (whether static or JIT) will also need to
> be aware of operands that may implicitly clobber parrot register values or
> modify control flow, so that it knows when it musth "spill" updated parrot
> register values in hardware registers back to their memory locations and when
> it must reload hardware registers from main memory.
I had considered something like this, using Apocolypse 2 properties, and
'sub' instead of 'op':
sub set(INTVAL $1 is written, INTVAL $2 is read) is inline {
$1 = $2;
goto NEXT();
}
# ...
sub branch(INTVAL $1 is read) is inline nonlinear {
goto OFFSET($1);
}
Heck, that's almost Perl. In fact, we *could* go all the way to named
args:
sub set(INTVAL $target is written, INTVAL $source is read) is inline {
$target = $source;
goto NEXT();
}
# ...
sub branch(INTVAL $dest is read) is inline nonlinear {
goto OFFSET($1);
}
We could even use adverbial-looking notation for gotos:
sub set(INTVAL $target is written, INTVAL $source is read) is inline {
$target = $source;
goto : next;
}
# ...
sub branch(INTVAL $dest is read) is inline nonlinear {
goto : offset $dest;
}
Finally, we could use the Perl 6 no-funny-business typenames:
sub set(int $target is written, int $source is read) is inline {
$target = $source;
goto : next;
}
# ...
sub branch(int $dest is read) is inline nonlinear {
goto : offset $dest;
}
We could take 'written' as implying 'register' and not 'constant'; and
'read' (without 'written') could imply 'constant' and not 'register'.
We could automatically treat those 'read' args as we do 'x|xc' today.
We could automatically treat those 'written' args as we do 'x' today.
This moves us in the direction of very-Perl-looking .ops code vs. semi-
C-looking .ops code, which wouldn't bother me. I can live with C-like
or Perl-like syntax here. Note, though that we *are* using Perl-style
comments and POD documenjtation, which means that Perl-like syntax would
be consistent.
One Perl thing we would be breaking is subroutine name overloading.
We'd have 'set' in there multiple times, once for each register type. To
get around this, we'd have to name them set_[inps] and make sure we've
got the C function name generation logic doing The Right Thing. Not
insurmountable.
The code that does the .ops file reading could be made to permit any
number of tags. Stashing them in the Parrot/opblib/*.pm file is easy.
Stashing them in *_ops.c won't be hard if we just treat them like an
array of strings with a NULL terminator, probably sorted. Harder to
use than flag bits, but extensible. Either way would work.
Regards
-- Gregor
____________________________________________________________________
/ Inspiration >> Innovation >> Excellence (TM) \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\____________________________________________________________________/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
>From 85.83.77.67: Time to live exceeded
