missing ops/vtable: lsr, pow
We have vtables for shr/shl but not for lsr. Is there a specific
reason that these vtables are not in pdd02?
The same is with pow, though this could be treated like the
trigonometric ops, which we don't have for PMCs either.
BTW: What about trig ops for PMCs:
sin P1, P0 # no vtable, so ...
set N0, P0 # 2 more ops to convert
sin N1, N0
set P1, N1
or
op sin(in PMC, in PMC) {
double n0 = VTABLE_get_number(interp, $2);
double n1 = sin(n0);
VTABLE_set_number_native(interp, $1, n1);
}
or
trig P1, P0, sin # implemented as method in PerlScalar or ...
trig P1, P0, .PERL_SCALAR_SIN_METHOD
Ctrig would use Cfind_method. The latter with an
array-lookup/integer index (if find_method uses an OrderedHash as method
table).
leo
Re: missing ops/vtable: lsr, pow
On Mon, 22 Sep 2003, Leopold Toetsch wrote: We have vtables for shr/shl but not for lsr. Is there a specific reason that these vtables are not in pdd02? Mainly because languages generally only define a single left and right shift operator The same is with pow, though this could be treated like the trigonometric ops, which we don't have for PMCs either. I've considered adding a separate sub-vtable for trig ops, hanging off a pointer in the class' base vtable, so multiple classes can share a single trig vtable. I don't expect it to be overridden enough to be worth adding another 128 bytes (or more) to each vtable we use. Most of the trig functions can be return function(SELF-get_float) or something like that. Dan
Re: Missing Ops
Dan Sugalski [EMAIL PROTECTED] wrote: For us, teh equivalent would be returning a PerlInt if we find the result produces an integral value, and a PerlNum if it doesn't. (Assuming, of course, that the operation took place on two perl-style PMCs, as other languages may have different rules on what happens) Ok. Most done. (PerlNum) 4.2+2.8 gives PerlInt 7 now. Dan leo
Re: Missing Ops
Leon Brocard [EMAIL PROTECTED] writes: [Something! For the first time in ages!] Hurrah! A summarizer breaths easily!
Re: Missing Ops
Dan Sugalski wrote:
On Mon, 8 Sep 2003, Leopold Toetsch wrote:
1) should these ops just be implemented or
This one. We can consider pruning out unused variants later, after we've
been up and running and have reasonable HLL output to check against.
Ok. Started that.
- neg_p
- new vtables for cmodulus (both mod and cmod where doing C-modulus)
- c?modulus_{int,float}
- separated the implementation into utils.c
BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me.
I think we need some clarification for the PerlNum implementation.
Dan
leo
Re: Missing Ops
On Tue, 9 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski wrote:
On Mon, 8 Sep 2003, Leopold Toetsch wrote:
1) should these ops just be implemented or
This one. We can consider pruning out unused variants later, after we've
been up and running and have reasonable HLL output to check against.
Ok. Started that.
- neg_p
- new vtables for cmodulus (both mod and cmod where doing C-modulus)
- c?modulus_{int,float}
- separated the implementation into utils.c
Cool.
BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me.
I think we need some clarification for the PerlNum implementation.
That's right--perl math always ends up as floats.
Dan
Re: Missing Ops
Dan Sugalski [EMAIL PROTECTED] wrote: On Tue, 9 Sep 2003, Leopold Toetsch wrote: BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me. I think we need some clarification for the PerlNum implementation. That's right--perl math always ends up as floats. I'm not sure: $ perl -MDevel::Peek -e 'Dump 4.2/2.' SV = PVNV(0x8149f78) at 0x8124b78 REFCNT = 1 FLAGS = (NOK,READONLY,pIOK,pNOK) IV = 2 NV = 2.1 PV = 0 $ perl -MDevel::Peek -e 'Dump 4.2/2.1' SV = PVNV(0x8149f80) at 0x8124b78 REFCNT = 1 FLAGS = (IOK,NOK,READONLY,pIOK,pNOK) IV = 2 NV = 2 PV = 0 AFAIK is (IOK, pIOK) the same as a real IV. At least they look differently: $ perl -le 'print 4.2/2.1' 2 $ echo 'div N0, 4.2, 2.1 print N0 print \n' | parrot -a - 2.00 Dan leo
Re: Missing Ops
On Tue, Sep 09, 2003 at 08:41:56AM -0400, Dan Sugalski wrote: On Tue, 9 Sep 2003, Leopold Toetsch wrote: BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me. I think we need some clarification for the PerlNum implementation. That's right--perl math always ends up as floats. No longer true as of 5.7.3 when IVs/UVs are larger than the floating point mantissa and the result is exact: $ /usr/local/perl5.8.1-snap21133/bin/perl5.8.1 -MDevel::Peek -le '$a=0x/3; Dump $a' SV = IV(0x8145674) at 0x8144cb8 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 6148914691236517205 The same perl for a small value uses NVs: $ /usr/local/perl5.8.1-snap21133/bin/perl5.8.1 -MDevel::Peek -le '$a=0xFF/3; Dump $a' SV = NV(0x814b4cc) at 0x8144c90 REFCNT = 1 FLAGS = (NOK,pNOK) NV = 85 Nicholas Clark
Re: Missing Ops
On Tue, 9 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: On Tue, 9 Sep 2003, Leopold Toetsch wrote: BTW PerlInt.divide() always yields a PerlNum, this seems bogus to me. I think we need some clarification for the PerlNum implementation. That's right--perl math always ends up as floats. I'm not sure: FLAGS = (NOK,READONLY,pIOK,pNOK) FLAGS = (IOK,NOK,READONLY,pIOK,pNOK) AFAIK is (IOK, pIOK) the same as a real IV. Internally it's sometimes not a float in new versions of perl, as Nicholas pointed out, but unless the 'use integer' pragma's in effect, the math is treated as if it were a floating point operation. The IOK flag is an indication that the integer cache slot is valid--it means that perl realized that the operation produces an integral value and filled in the slot appropriately. For us, teh equivalent would be returning a PerlInt if we find the result produces an integral value, and a PerlNum if it doesn't. (Assuming, of course, that the operation took place on two perl-style PMCs, as other languages may have different rules on what happens) Dan
Missing Ops
While playing with YAL (Yet Another Language) I'm discovering a lot of asymmetries in ops files: neg_p is missing (neg_p_p only, but neg_i is there) mod_p_p_i, mod_p_p_n are missing (add, sub, ... have these variants) keyed assign ops are missing (set only) The question is what to do: 1) should these ops just be implemented or 2) should the assembler work around missing ops 3) should each HLL work around missing ops leo
Re: Missing Ops
Leopold Toetsch sent the following bits through the ether: 1) should these ops just be implemented or At this point we want to make it really easy to target parrot. I know it's not hard to work around these exceptions, but I reckon implementing the complete set of ops for now would be a good idea. We can always move the logic into the assembler later if we decide to prune ops. ObLeonBrocard: he just be restin', arrr -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... I was young, I needed the money
Re: Missing Ops
On Mon, 8 Sep 2003, Leopold Toetsch wrote: While playing with YAL (Yet Another Language) I'm discovering a lot of asymmetries in ops files: neg_p is missing (neg_p_p only, but neg_i is there) mod_p_p_i, mod_p_p_n are missing (add, sub, ... have these variants) keyed assign ops are missing (set only) The question is what to do: 1) should these ops just be implemented or This one. We can consider pruning out unused variants later, after we've been up and running and have reasonable HLL output to check against. Dan
