Missing Ops
Leopold Toetsch
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
Leon Brocard
> 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
Dan Sugalski
> 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
Piers Cawley
> [Something! For the first time in ages!]
Hurrah! A summarizer breaths easily!
Leopold Toetsch
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
Dan Sugalski
> 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
Leopold Toetsch
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.000000
> Dan
leo
Nicholas Clark
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=0xFFFFFFFFFFFFFFFF/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
Dan Sugalski
> Dan Sugalski <d...@sidhe.org> 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
Leopold Toetsch
> 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