This has come up before and the discussion always semi-warnocks, but
it's time to bring it up again.
All the vtable operations that do PMC things are three-arg
versions--they get both the args and the destination PMCs passed in.
This is done specifically for speed reasons, as the assumption is
Dan Sugalski wrote:
This becomes a bit less efficient when we're looking at intermediate
values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType
add $P0, b, c
add a, $P0, d
Well...how about this:
1. Have all vtable methods which take a dest retur
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This becomes a bit less efficient when we're looking at intermediate
> values of expressions. Something like:
> a = b + c + d
> turns to
> new $P0, SomeIntermediateType
> add $P0, b, c
> add a, $P0, d
> and we need to create that $P0 te
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>> This becomes a bit less efficient when we're looking at intermediate
>> values of expressions. Something like:
>>
>>a = b + c + d
>>
>> turns to
>>
>>new $P0, SomeIntermediateType
>>add $P0, b, c
>>add a, $
And I show my ignorance yet again. I really need to do some serious
research into how things have changed...
Leopold Toetsch wrote:
It could work, if the sequence is:
$P0 = $P1 + $P2
null $P3
$P3 = $P0 + $P4
The C opcode cuts the life range of C<$P3> because of
its C specifier.
Hmmm...
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> And I show my ignorance yet again. I really need to do some serious
> research into how things have changed...
> Leopold Toetsch wrote:
>> It could work, if the sequence is:
>>
>>$P0 = $P1 + $P2
>>null $P3
>>$P3 = $P0 + $P4
>>
>> T
Ergh. Once agian, sorry if this shows up twice. If
someone can tell me a way to be subscribed to the list
without actually getting every message (I prefer to
read from the archive), that'd be great. Anyway...
> This has come up before and the discussion
> always semi-warnocks, but
Yeah...
> 1)
Togos <[EMAIL PROTECTED]> wrote:
>> 1) Have a version of the binary vtable
>>methods that create the destination PMC
> Well, as I was saying last summer, #1 is really what
> the add instruction should have done in the first
> place, as that would make it behave the same way as it
> does for i
> This has come up before and the discussion
> always semi-warnocks, but
Yeah...
> 1) Have a version of the binary vtable
>methods that create the destination PMC
> 2) Make a universal assignment PMC that
>takes on the characteristics
>of the RHS of the assignment
> 3) Have a "this
At 2:05 PM -0800 3/26/04, Brent 'Dax' Royal-Gordon wrote:
This does mean checking if dest == NULL at the beginning of each
vtable function, but other than that, it's fairly clean.
That's one of the things I was trying to avoid in the original
design, though. It means a null check in every vtable
At 7:38 AM +0100 3/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
This becomes a bit less efficient when we're looking at intermediate
values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType
add $P0, b, c
add a, $
Well I just realized something. Or at least realized a
better way to explain it.
Let's say we have a HLL that is mapping HL variables
to Parrot registers.
someint1 = someint2 + someint3
will, of course, map to something like
$I1 = $I2 + $I3
Now, if those ints were replaced by PMC reference
Togos <[EMAIL PROTECTED]> wrote:
> $I1 = $I2 + $I3
> $P1 = $P2 + $P3
> Which, of course, doesn't work. But this is what
> languages like Python or Ruby would expect to be able
> to do, as they don't need Perl's fancy variable
> objects -- a register is good enough.
> sementics of
That and o
At 3:32 PM -0800 3/29/04, TOGoS wrote:
Well I just realized something. Or at least realized a
better way to explain it.
Let's say we have a HLL that is mapping HL variables
to Parrot registers.
someint1 = someint2 + someint3
will, of course, map to something like
$I1 = $I2 + $I3
Now, if thos
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >we Ruby folks would like to be able to do:
> >
> > $P1 = $P2 + $P3
> >
> >Which, of course, doesn't work.
>
> Well... actually you don't want what you're asking
> for.
Maybe... :/
> Specifically you don't want
>
> foo = bar + baz
>
> to acc
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Togos <[EMAIL PROTECTED]> wrote:
>
>> $I1 = $I2 + $I3
>
>> $P1 = $P2 + $P3
>
>> Which, of course, doesn't work. But this is what
>> languages like Python or Ruby would expect to be able
>> to do, as they don't need Perl's fancy variable
>> objects
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> That and other arguments are of course all correct. I just have the gut
>> feeling that having both opcode and vtable variants blows core size up
>> to an isane value.
> Couldn't you have a single opcode, C,
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > Togos <[EMAIL PROTECTED]> wrote:
> >
> >> $I1 = $I2 + $I3
> >
> >> $P1 = $P2 + $P3
> >
> >> Which, of course, doesn't work. But this is what
> >> languages like Python or Ruby would expect to be
>
18 matches
Mail list logo
