At 9:02 PM +0100 10/11/02, Nicholas Clark wrote:
>On Fri, Oct 11, 2002 at 01:30:33PM -0400, Dan Sugalski wrote:Where both operands are ints or nums, I think it's a good idea. I'm
>> At 7:10 PM +0200 10/10/02, Leopold Toetsch wrote:
>> >There are also 2 operand math operations of dubious achievement:
>> >Each of them will be doubled for each RHS INT argument giving ~25 opcodes.
>> Those are all for the:
>> a op= b
>> form. There's a minor benefit to keeping them.
>I would like to kill all generated variants of all the 3 argument opcodes
less sure in the case where there's a PMC or string involved, as
there may be some assumption of runtime behaviour (in the case of
constant PMCs that might have some methods overloaded) or strings
where the compiler is expecting runtime conversion to happen before
whatever gets done.
> > >I would kill these too.True, though I'm not hugely worried about this, as it happens only once.
>> >IMHO a smaller core will perform better, then the above saving of 1
>> >operand in the byte code can achieve.
>> Maybe, but I'm unconvinced. We are going to do a cull of the opcodes
>It should make the computed goto core compile more rapidly.
>It might also make the computed goto core run more efficiently, as byTrue. I think reordering is a bigger win, honestly. Lightly used
>being smaller it will bring more frequently used opcodes closer together.
>(Although we can probably have a larger effect by specificy a sort order
>either by iterative benchmarking the speed of parrot with different orders,
>or by code coverage profiling to find the most common opcodes.)
>Not much gain, but it might be worth it if we can automate the discovery
opcode functions won't get swapped in until they're really needed.
--------------------------------------"it's like this"-------------------
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.