Determining PMC memory addresses
Cory Spencer
Is there any way in PASM to determine whether or not two PMC's share the
same memory address?
That is, for example, given the following IMC snippet:
.sub _eq
.param pmc arg1
.param pmc arg2
.local int retv
...
...
.pcc_begin_return
.return retv
.pcc_end_return
.end
what I'd like to do is to determine whether arg1 and arg2 are the SAME pmc
object (not in value, but whether or not they reside at the same location
in memory).
Regards,
Cory
Leopold Toetsch
> Is there any way in PASM to determine whether or not two PMC's share the
> same memory address?
Not yet. We have the vtable methods but the opcodes are missing.
We have:
Op vtable Meaning
- is_same PMCs are ident
- is_equal PMCs are equivalent, holding the same value
Y cmp cmp PMCs
- cmp_num cmp PMCs numerically
- cmp_string cmp PMCs as strings
Proposals for opcode names welcome.
> Regards,
> Cory
leo
Cory Spencer
On Fri, 28 Nov 2003, Leopold Toetsch wrote:
> Op vtable Meaning
> - is_same PMCs are ident
> - is_equal PMCs are equivalent, holding the same value
> Y cmp cmp PMCs
> - cmp_num cmp PMCs numerically
> - cmp_string cmp PMCs as strings
>
> Proposals for opcode names welcome.
How does the current 'eq' opcode deal with comparissons of PMC/PMC values?
Simon Glover
'eq' calls is_equal, so that should have a 'Y' in the table above.
Simon
Cory Spencer
> > On Fri, 28 Nov 2003, Leopold Toetsch wrote:
> >
> > > Op vtable Meaning
> > > - is_same PMCs are ident
> > > - is_equal PMCs are equivalent, holding the same value
> > > Y cmp cmp PMCs
> > > - cmp_num cmp PMCs numerically
> > > - cmp_string cmp PMCs as strings
> > >
> > > Proposals for opcode names welcome.
> >
Well, a page could be stolen from the Lisp book by defining eq/eql/equal
opcodes (though in ths case, differing from the Lisp counterparts in the
meaning of the tests) where
- eq is true if both arguments have the same value (that is, both are
numerically equal or both are equivalent strings)
- eql is true if both arguments are the same, identical object
- equal does a comparison to test if the two objects are structurally
similar (ie. in the case of a PerlArray, an element-by-element
comparrison would be performed to determine the similarity of the
structure.)
Cory
Jos Visser
I think this is definitely something we should do if we want to confuse
people as much as possible :-)
Much can be said about this topic, but let's keep in mind that:
- The length of the opcode name is not important for execution speed or
memory space used (this contrary to the early LISP
machines/interpreters).
- English is only a small language (with respect to the amount of native
speakers, which are mainly restricted to a number of large islands
and some of the residents of a large and mostly uninhabited landmass
somewhere on the western hemisphere) :-)
Non-native speakers can not be trusted to immediately grasp the
semantic differences between things as:
- equal/identical/same
- compare/test
I would therefore vote that we keep these opcodes as verbose as
possible. So no eq/eql/equal, but rather
same_address/same_content/compare/compare_as_num/compare_as_string.
And remember, I am nobody... :-)
++Jos.es
--
Viel mehr als gestern liebe ich dich heute.
Doch weniger noch als ich dich morgen lieben wird.
"Wie vor Jahr und Tag", Reinhard Mey
Cory Spencer
> I think this is definitely something we should do if we want to confuse
> people as much as possible :-)
This is likely true, seeing as I *still* have troubles keeping the various
Lisp eq/eql/equal/equalp's straight. ;)
> I would therefore vote that we keep these opcodes as verbose as
> possible. So no eq/eql/equal, but rather
> same_address/same_content/compare/compare_as_num/compare_as_string.
Some of those are probably a little too verbose for my tastes. ;)
We're already using 'eq' to perform equality testing, and in the interests
of maintaining a consistent design I would choose to stick with something
eq-related as opposed to changing it to 'same'.
eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
With respects to the compare_as_num/compare_as_string opcodes, there's
also already a 'cmp' opcode and there already seems to be the established
naming scheme of opcodeX, where X is one of n/i/s/p, depending on the type
being dealt with (ie. cleari, clearn, clears, clearp).
cmpi/cmpn/cmps/cmpp? cmpasi/cmpasn/cmpass/cmpasp?
cmp_as_i/cmp_as_n/cmp_as_s/cmp_as_p?
Personally, I'd probably pick the first option in each of the above sets,
though that is just my preference... :)
Cory
Cory Spencer
> We're already using 'eq' to perform equality testing, and in the interests
> of maintaining a consistent design I would choose to stick with something
> eq-related as opposed to changing it to 'same'.
>
> eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
Oops, correction there - I'd forgotten an earlier post that pointed out
the proposed functionality of eqval/eq_val/eq_value had already been
implemented.
Leopold Toetsch
> I would therefore vote that we keep these opcodes as verbose as
> possible. So no eq/eql/equal, but rather
> same_address/same_content/compare/compare_as_num/compare_as_string.
Or as verbose as needed [1]:
ident, eq, <op>, <op>_num, <op>_string for <op> in (lt le gt ge)
eq and ne are a bit special - yes they do vtable->is_equal now, but that
might be wrong when either numerically or string-compare is intended.
<op> and (<op>_num, <op>_string) seem to be suitable for languages that
don't have different compare ops and those like perl that have
respectively.
> ++Jos.es
leo
[1] eq, ne, lt, le, gt, ge are already widely used
Alex
> Well, a page could be stolen from the Lisp book by defining eq/eql/equal
> opcodes (though in ths case, differing from the Lisp counterparts in the
> meaning of the tests) where
>
> - eq is true if both arguments have the same value (that is, both are
> numerically equal or both are equivalent strings)
> - eql is true if both arguments are the same, identical object
> - equal does a comparison to test if the two objects are structurally
> similar (ie. in the case of a PerlArray, an element-by-element
> comparrison would be performed to determine the similarity of the
> structure.)
There's a paper by Henry baker which proposes an equality predicate
which (I think) is supposed to combine address and contents equality
in a useful way:
http://home.pipeline.com/~hbaker1/ObjectIdentity.html
May be worth thinking about.
Alex
Cory Spencer
> We're already using 'eq' to perform equality testing, and in the interests
> of maintaining a consistent design I would choose to stick with something
> eq-related as opposed to changing it to 'same'.
>
> eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
So just to follow up on this thread, was there any preference at all for
the name of the opcode performing equality testing of PMC memory
addresses? I needed the functionality for the code I'm working on, so
I've created a patch implementing an "eq_addr" opcode...
Regards,
Cory
Cory Spencer
> I don't think there was ever a consensus about opcode naming.
> It seems that we need this but can you give an example
> of where you are using it, just to give me some context to think
> with?
I've been implementing a Lisp interpretter (and hopefully at some point,
compiler) and was using the eq_addr (or whatever it's eventually destined
to be named) to test for equality between symbol types. (I'm sure there's
another hackish way of implementing the test, but this seemed like the
cleanest way of doing it at the time...)
Dan Sugalski
Make it eq_addr. We'll go with that scheme for the other comparisons
(eq_str, eq_num) as well.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Christopher E. Stith
> I think this is definitely something we should do if we want to confuse
> people as much as possible :-)
Not necessarily. Most programmers have at least some understanding of
mathematics in the language in which they are about to use when
programming.
Equality, identity, and congruenc[ey] are three mathematical
principals which are fairly basic and fairly widely understood even
outside the mathematic and computer fields. I don't think that making
use of these terms would confuse so many people. I may be wrong.
> I would therefore vote that we keep these opcodes as verbose as
> possible. So no eq/eql/equal, but rather
> same_address/same_content/compare/compare_as_num/compare_as_string.
How about eq/ident/congruent? Since this is roughly the order in which
they would be used, from most to least, it even maintains Huffman
coding for the ops.