Benjamin Goldberg wrote:
Brent Dax wrote:
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and store it in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed
Benjamin Goldberg writes:
Hmm... I just thought of something. Since 'set' semantics can be easily
simulated when we have only ops for 'assign' semantics, maybe imcc
itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will be translated by imcc into
add $P0, $P1, $P2
Luke Palmer wrote:
Benjamin Goldberg writes:
Hmm... I just thought of something. Since 'set' semantics can be
easily simulated when we have only ops for 'assign' semantics, maybe
imcc itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will be translated by imcc
On Sun, 17 Aug 2003, Luke Palmer wrote:
Benjamin Goldberg writes:
Hmm... I just thought of something. Since 'set' semantics can be easily
simulated when we have only ops for 'assign' semantics, maybe imcc
itself could do this for us.
That is, by default,
$P0 = $P1 + $P2
will
Dan Sugalski wrote:
No. It isn't, and JITting doesn't have anything to do with this. The
issue is expressable semantics, and in languages with active data (which
encompasses a number of the languages we're interested in, icluding
perl, python, and ruby) not allowing direct access to members of
At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
Togos [EMAIL PROTECTED] wrote:
... a bit strange that there is a keyed version
of 'add', anyway.
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables, for which we never want to have opcodes. Did I
miss one?
At 5:36 PM -0400 8/15/03, Gordon Henriksen wrote:
Is the RISC design philosophy not useful
when applied to a JITted virtual machine?
Skipping all the rest...
No. It isn't, and JITting doesn't have anything to do with this. The
issue is expressable semantics, and in languages with active data
Brent Dax wrote:
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and
# store it in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed to be based
#
Brent Dax wrote:
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and store it in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed to be based
# on
On Fri, 15 Aug 2003, TOGoS wrote:
There may be something I'm missing, but I don't
understand why we need a keyed version of just
about every opcode.
It avoids having to create a lot of temporary PMCs with weird magic on
them, avoids having to create temporary PMCs in general, and allows the
On Fri, 15 Aug 15, 2003 Dan Sugalski wrote:
On Fri, 15 Aug 2003, TOGoS wrote:
There may be something I'm missing, but I don't
understand why we need a keyed version of just
about every opcode.
It avoids having to create a lot of temporary PMCs with weird
magic on them, avoids
Togos [EMAIL PROTECTED] wrote:
... a bit strange that there is a keyed version
of 'add', anyway.
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables, for which we never want to have opcodes. Did I
miss one?
Ah yes - docu needs updating, but Dan didn't put
Benjamin Goldberg [EMAIL PROTECTED] wrote:
... I'd rather have two versions of add, one
with set/create semantics and the other with assign/mutate semantics.
As already outlined, this leads to some kind of duplicating of our
opcodes, vtables, penalty on JIT implementators and so on. We (/me)
TOGoS:
# syntax. As it is, the add(ints) op and the
# add(pmcs) ops do very different things (one
# has 'set' while the other has 'assign' semantics),
# but they look exactly the same. If not at
I think that's mostly because there's no difference between set
semantics and assign semantics for
On Thursday, August 14, 2003, at 04:36 , TOGoS wrote:
P1 = new PerlInt
P1 - P2 + P3 # When you see - instead of =,
# You know that it's operating on
# an existing value, not just
# altering the contents of
# registers, as your
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and store it in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed to be based
# on the types of $P1 and $P2
#
#
Togos [EMAIL PROTECTED] wrote:
[ add semantics ]
... Adding something to a PythonInt
would return a PythonInt, while adding to a PerlInt
would return a PerlInt.
That's anway the way these oopcode work:
add PDest, PSsrc, PVal
PSrc-vtable-add ...
do add according to type, then:
- Original Message -
From: Brent Dax [EMAIL PROTECTED]
To: 'TOGoS' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 11:25 PM
Subject: RE: set vs. assign, continued: 'add' vs. 'add!'
TOGoS:
# syntax. As it is, the add(ints) op and the
# add(pmcs) ops do very
--- Brent Dax [EMAIL PROTECTED] wrote:
TOGoS:
# When I say in IMCC:
#
# $P0 = $P1 + $P2
#
# , I expect it to create a new value and store it
in
# $P0, not give me a segfault because I didn't say
#
# $P0 = new figure out what the heck type
# $P0 is supposed to be
Togos [EMAIL PROTECTED] wrote:
add(out PMC, in PMC, in PMC)
add!(in PMC, in PMC, in PMC)
While that is all fine and useful, we would need that for e.g. keyed set
and get too (store/get a reference or value). So that would lead to
effectively almost doubling our opcode count.
This can lead
that's mostly because there's no difference
between set
semantics and assign semantics for ints. You can
think of them as both
having assign semantics, if you like.
Works better to think of only 'set' semantics.
I think of it like this, and it makes things
work out very nicely:
Think of
add(out INT, in INT, in INT)
add(out NUM, in NUM, in INT)
add(out NUM, in NUM, in NUM)
add(in PMC, in PMC, in INT)
add(in PMC, in PMC, in NUM)
add(in PMC, in PMC, in PMC)
This kind of ties into the 'set vs assign' issue.
Add behaves differently depending on whether
the first parameter is an
22 matches
Mail list logo
