I sent something similar to this about 6 hours
ago but it never showed up so I think it
got spam filtered or something. :-/
Anyway, just to clear things up, here
is my take on 'set' and 'assign':
set: replace the reference in the
destination register
assign: don't change the reference in the
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
- Original Message -
From: Dan Sugalski [EMAIL PROTECTED]
To: T.O.G. of Spookware [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 9:18 AM
Subject: Re: Set vs. Assign..?
At 11:45 AM -0700 8/1/03, T.O.G. of Spookware wrote:
Hi, all. I've been following Parrot
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
#
#
Having read this thread, I think that the real problem is not just that
there are multiple assignment semantics -- it's that the names set and
assign are not really meaningful -- that is, they *look* to english
speakers as if they are synonyms... their names alone aren't enough info
to know what
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:
PieThonInt, RubyInt?
Hmm. I that parrot should DTRT, and use
CurrentLanguageInt. :)
Hmm. I agree with Leo, here.
P6 = new PerlInt (3)
would be equivalent to PASM:
new P6, PerlInt
assign P6, 3
This is more generic and would be portable to
any kind of PMC you want. Arrays, Strings,
- 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
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
I would suggest the opnames/categories mutate, alias, and
create.
IMHO, we could leave PASM syntax as it is and create opcode aliases
inside
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
I would suggest the opnames/categories mutate, alias, and
create.
IMHO, we could leave PASM syntax as it is and create opcode aliases
inside the assembler ...
You mean leave the old ops with their names, but merely
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
I would suggest the opnames/categories mutate, alias, and
create.
IMHO, we could leave PASM syntax as it is and create opcode aliases
inside the assembler ...
I would rather
Benjamin Goldberg [EMAIL PROTECTED] wrote:
I would suggest the opnames/categories mutate, alias, and create.
IMHO, we could leave PASM syntax as it is and create opcode aliases
inside the assembler ...
I believe that the most in^H^H logical shorthand spellings of these
opcodes would be :=,
And ghod forbid, for arrays:
elements PMC, int
(an elements op would be really nice, because then
infinite lists
could return infinite elements:)
elements PMC, PMC
It might be confusing to have both set elements
and get elements
by the same name. But those are just
At 11:45 AM -0700 8/1/03, T.O.G. of Spookware wrote:
Hi, all. I've been following Parrot development and
been playing with Parrot for a...bout a year and a
half, now. First time posting to the list, though, so
forgive me if this has already been covered or is
stupid in some way :-)
Anyway, while
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:45 AM -0700 8/1/03, TOGoS wrote:
...blah, blah, blah...
What I don't like about this is
that it's not immediately obvious
from looking at the code whether
you're telling P3 to change its
value or simply replace the PMC
reference
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:45 AM -0700 8/1/03, TOGoS wrote:
...blah, blah, blah...
What I don't like about this is
that it's not immediately obvious
from looking at the code whether
you're telling P3 to change its
value or simply replace the PMC
34 matches
Mail list logo
