Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

set Boolean to 2

6 views
Skip to first unread message

Leopold Toetsch

unread,
Aug 15, 2002, 10:08:30 AM8/15/02
to P6I
Hi,

when testing native types with perl6 I encountered the following problem:

..p6:
my $b is Boolean = 2;

..imc:
.local Boolean _SV_b1
$P4 = new PerlUndef
$P4 = 2
_SV_b1 = $P4

..pasm:
new P14, .PerlUndef
set P14, 2
set P10, P14

..pbc
new_p_ic P14,2
set_p_ic P14,2
set_p_p P10,P14

which justs sets $1=$2 in core.ops.

What is the intended behaviour of Booleans?
An more generally, shouldn't set_p_p call some vtable function?

leo

Peter Gibbs

unread,
Aug 15, 2002, 1:36:08 PM8/15/02
to Leopold Toetsch, P6I
Leopold Toetsch wrote:

> new P14, .PerlUndef
> set P14, 2
> set P10, P14

> An more generally, shouldn't set_p_p call some vtable function?

No. set Px, Py simply sets the Px register to point to the same PMC
as Py already points to; it does not care about the content of the
PMC in any way. The future 'assign Px, Py' will call a vtable function
(set_pmc); however, in the quoted example, the pure register level
behaviour is all that is intended.

--
Peter Gibbs
EmKel Systems


Leopold Toetsch

unread,
Aug 15, 2002, 4:55:40 PM8/15/02
to P6I
Peter Gibbs wrote:

[ set_p_p ]

> ... The future 'assign Px, Py' will call a vtable function
> (set_pmc);


So, trying to set a Boolean to "2", would be a case for the proposed
"assign" function, ok, yes.

> ... however, in the quoted example, the pure register level


> behaviour is all that is intended.


I currently can't imagine any useful RL example for the current
implementation of set_p_p as $1=$2, _if_ the involved PMC types are
different.

my 2¢
leo

Peter Gibbs

unread,
Aug 15, 2002, 5:14:13 PM8/15/02
to Leopold Toetsch, P6I
Leopold Toetsch wrote:

> I currently can't imagine any useful RL example for the current
> implementation of set_p_p as $1=$2, _if_ the involved PMC types are
> different.

You need to differentiate between the PMC itself, and a Parrot register
that holds the address of a PMC. In the instruction "set Px, Py" the only
PMC involved is the one pointed to by register Py; if Px happens to point
to a PMC then that linkage will be broken, with no effect on the PMC
(previously) pointed to by Px; the register Px will then point to the same
PMC as Py does.
In the code snippet you originally posted, there seemed to be no need
for this; however, calling subroutines, for example, will require that the
addresses of the parameters be placed in specific registers, and so
the set operation may well be used frequently in those circumstances.

The instruction that performed the actual assignment to the PMC was
the "set Px, 2" instruction; this (which may be replaced by "assign")
calls the set_integer_native vtable method. Since the PMC type is
PerlUndef at that point, the current automatic morphing kicks in, and
the PMC actually gets turned into a PerlInt - in future, the perl compiler
will have to create a PMC with the correct type initially, and this
morphing will be removed for typed variables.

Leopold Toetsch

unread,
Aug 15, 2002, 4:32:23 PM8/15/02
to P6I
Sorry for replying myself,

> my $b is Boolean = 2;

Here obviously a syntax disorder slept in, but the conclusion would be
the same.

leo

0 new messages