C#/Parrot Status
Rhys Weatherley
first opportunity I've had to catch up on Parrot.
I'm interested in the current status of the following within
Parrot:
- object/class support
- fixed-sized integers and/or conversion opcodes
- embedding of binary extension sections
"Not Done Yet" is an acceptable answer. :-)
Cheers,
Rhys.
Leopold Toetsch
.... and the correct answer too.
IMHO a start would be to do fixed-sized integers + conversion ops.
Please have a look at include/parrot/datatypes.h. I hope that there are
all types you'll need.
Can you specify, what opcodes you would need?
> Cheers,
>
> Rhys.
leo
Gopal V
> Please have a look at include/parrot/datatypes.h. I hope that there are
> all types you'll need.
It seems so ... but I'm not really certain about Float data types ...
> Can you specify, what opcodes you would need?
Hmm... I guess I can only quote the ECMA spec here ...
conv.i1 Convert to int8, pushing int32 on stack
conv.i2 Convert to int16, pushing int32 on stack
conv.i4 Convert to int32, pushing int32 on stack
conv.i8 Convert to int64, pushing int64 on stack
conv.r4 Convert to float32, pushing F on stack
conv.r8 Convert to float64, pushing F on stack
conv.u1 Convert to unsigned int8, pushing int32 on stack
conv.u2 Convert to unsigned int16, pushing int32 on stack
conv.u4 Convert to unsigned int32, pushing int32 on stack
conv.u8 Convert to unsigned int64, pushing int64 on stack
conv.i Convert to native int, pushing native int on stack
conv.u Convert to native unsigned int, pushing native int on stack
Thanks to the polymorphic nature of the opcodes the "from" entry is in
another table in ECMA .... But I guess conversions of lower integer
data types to I registers and back would be a starting point ?
Gopal
--
The difference between insanity and genius is measured by success
Iacob Alin
> If memory serves me right, Leopold Toetsch wrote:
>
> > Please have a look at include/parrot/datatypes.h. I hope that there are
> > all types you'll need.
>
> It seems so ... but I'm not really certain about Float data types ...
>
> > Can you specify, what opcodes you would need?
>
> Hmm... I guess I can only quote the ECMA spec here ...
> conv.i1 Convert to int8, pushing int32 on stack
> conv.i2 Convert to int16, pushing int32 on stack
> conv.i4 Convert to int32, pushing int32 on stack
> conv.i8 Convert to int64, pushing int64 on stack
> conv.r4 Convert to float32, pushing F on stack
> conv.r8 Convert to float64, pushing F on stack
> conv.u1 Convert to unsigned int8, pushing int32 on stack
> conv.u2 Convert to unsigned int16, pushing int32 on stack
> conv.u4 Convert to unsigned int32, pushing int32 on stack
> conv.u8 Convert to unsigned int64, pushing int64 on stack
> conv.i Convert to native int, pushing native int on stack
> conv.u Convert to native unsigned int, pushing native int on stack
This might be a stupid question, but are this datatypes going to be PMCs?
> Gopal
--
Alin
Leopold Toetsch
> If memory serves me right, Leopold Toetsch wrote:
^^^...
Your mailer should know ;-)
> Hmm... I guess I can only quote the ECMA spec here ...
> conv.i1 Convert to int8, pushing int32 on stack
truncate to [-128..127]? And why the push?
What is the behaviour on overflow?
> conv.i8 Convert to int64, pushing int64 on stack
Datatypes bigger then INTVAL would need a PMC as storage.
> Gopal
leo
Leopold Toetsch
> This might be a stupid question, but are this datatypes going to be PMCs?
Only types bigger then our current native types:
INTVAL typically 32 bit long on 32 bit machines
FLOTVAL typically double
> Alin
leo
Andy Dougherty
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
> > conv.i2 Convert to int16, pushing int32 on stack
[etc.]
> This might be a stupid question, but are this datatypes going to be PMCs?
It's a very good question, actually. The answer is probably something
like "ones that can be easily emulated with native types will probably not
need to be PMCs; the others probably will."
Two examples:
1. If your INTVAL is only 32 bits, then handling 64-bit ints will
probably have to be done with a PMC.
2. If your short, int, and long are all 64 bits, then handling the int16
and int32 types might have to be done with PMCs (depending on the precise
requirements for those types, which I don't know.)
--
Andy Dougherty doug...@lafayette.edu
Rhys Weatherley
> > If memory serves me right, Leopold Toetsch wrote:
>
> ^^^...
>
> Your mailer should know ;-)
That's his mailer talking. It always does that. :-)
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
>
> truncate to [-128..127]? And why the push?
Gopal was listing the IL opcodes, which are stack based.
They pop a value, convert, and then push a new value.
The stack cannot hold int8 values directly, so "conv.i1"
truncates, sign-extends back to int32, and then pushes that.
In Parrot syntax, it would probably be:
conv.int8 dstreg, srcreg
conv.uint32 dstreg, srcreg
(etc)
> What is the behaviour on overflow?
IL has two sets of conversion opcodes. One which truncates,
ignoring overflow. And the other which raises an exception
on overflow. It also has two sets of arithmetic operators
(add, sub, mul) that handle the "no overflow" and "overflow"
cases. (Overflow handling isn't needed for div, because
it cannot overflow).
Overflow handling would be nice, but we can work around it
in the same way we worked around it for JVM (with a helper
library). Support for unsigned types is more important.
The list of types in "datatypes.h" looks good. The one
exception was "signed and unsigned integers the same size
as a pointer". e.g. the C "intptr_t" type. Perhaps INTVAL
already handles that?
Cheers,
Rhys.
Gopal V
>
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
>
>
> truncate to [-128..127]? And why the push?
IL is a fully stack language ... pop int32, trunc, push int8 ...
Yes, truncate is the required operation . I guess sign-extension
is also present for up conversion ...
> What is the behaviour on overflow?
*.ovf suffixed instructions like (conv.i1.ovf) exist seperately ..
but that could be remedied by an explicit check ? ...
> Datatypes bigger then INTVAL would need a PMC as storage.
Ok. Otherwise this would complicate register handling ? (jvm allocates
2 adjacent local variables for a long and double .. *yow*)
Florian Weimer
> This might be a stupid question, but are this datatypes going to be
> PMCs?
And a related question: What about trapping integer arithmetic?
Dan Sugalski
That'll be done with the standard exception handling mechanism.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
Sorry for the ignorant question: This does mean what and implying that
and whatsoever?
A little bit more verbosity about requirements for data type extensions
would be really helpful, (IMHO always).
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> writes:
>
>> .NET has exception-throwing versions of its math operations. If you do
>> an add of two 8-bit integers and the result overflows, you should get
>> an exception (if you've used the "check overflow" versions of the ops)
>
>Actually, I thought about implementing Ada. The standard requires the
>following:
>
> 20. For a signed integer type, the exception Constraint_Error is
> raised by the execution of an operation that cannot deliver the
> correct result because it is outside the base range of the type.
>
>And this is painfully to implement if the machine doesn't support it
>(e.g. by overflow flags or trapping arithmetic).
Just becaues the base math ops don't throw exceptions doesn't mean
that there can't be exception-throwing versions. :) We should get
those added. Need to get exceptions done first, at least partially.
Florian Weimer
> .NET has exception-throwing versions of its math operations. If you do
> an add of two 8-bit integers and the result overflows, you should get
> an exception (if you've used the "check overflow" versions of the ops)
Actually, I thought about implementing Ada. The standard requires the
following:
20. For a signed integer type, the exception Constraint_Error is
raised by the execution of an operation that cannot deliver the
correct result because it is outside the base range of the type.
And this is painfully to implement if the machine doesn't support it
(e.g. by overflow flags or trapping arithmetic).
Unfortunately, in Ada, the base range of a type has to be known at
compile time (at least if you want to use any existing compiler), so
Ada needs fixed-width types, too.
Dan Sugalski
>Florian Weimer wrote:
>
>>"Iacob Alin" <ali...@fx.ro> writes:
>>
>>>This might be a stupid question, but are this datatypes going to be
>>>PMCs?
>>>
>>
>>And a related question: What about trapping integer arithmetic?
>
>Sorry for the ignorant question: This does mean what and implying
>that and whatsoever?
..NET has exception-throwing versions of its math operations. If you
do an add of two 8-bit integers and the result overflows, you should
get an exception (if you've used the "check overflow" versions of the
ops)
Nicholas Clark
> Dan Sugalski <d...@sidhe.org> writes:
>
> > .NET has exception-throwing versions of its math operations. If you do
> > an add of two 8-bit integers and the result overflows, you should get
> > an exception (if you've used the "check overflow" versions of the ops)
>
> Actually, I thought about implementing Ada. The standard requires the
> following:
>
> 20. For a signed integer type, the exception Constraint_Error is
> raised by the execution of an operation that cannot deliver the
> correct result because it is outside the base range of the type.
>
> And this is painfully to implement if the machine doesn't support it
> (e.g. by overflow flags or trapping arithmetic).
For integer maths if the machine uses 2s complement arithmetic I believe
it's not that painful. (And even if it doesn't it's not hugely painful)
[ie I think I know how to do it]
Floating point fills me with fear.
Nicholas Clark
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Rhys Weatherley
> Floating point fills me with fear.
If it makes you feel better, C# does not require overflow
detection on floating-point operations. FP overflow results
in +/-INF, underflow results in zero, and undefined is NAN.
Only integer overflow detection is required, and then only
on 32-bit, 64-bit, and native-sized integer types (8-bit
types don't need it).
If Parrot wants to add more opcodes for completeness sake,
then it won't do any harm to us, but don't bend over
backwards on FP for our sakes.
Cheers,
Rhys.
Dan Sugalski
We need it for our own purposes, so it'll have to go in.
FP over/underflow, of course, is one of those wonderfully
platform-dependent things. :(
Gopal V
> on 32-bit, 64-bit, and native-sized integer types (8-bit
> types don't need it).
Hmm... maybe there's only one way to stop this loooong thread ...
Oct 18 20:31:20 <Nicholas> no, no, you have it wrong. you don't
*ask* us to add features. YOu just send
us patches which do them :-)
Nov 25 03:09:38 <Dan> And I'm serious. If you want a dotnet.ops file,
go for it.
.....
I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ...
DISCLAIMER: I don't know anything about how parrot opcodes should be
written .. So all errors are accidental and I would like somebody to
point them out to me ..
Dan Sugalski
>Gopal V wrote:
>
>Thanks for the patch. I'll add some config methods and apply it
>after polishing.
>
>>DISCLAIMER: I don't know anything about how parrot opcodes should be
>>written .. So all errors are accidental and I would like somebody to
>>point them out to me ..
>
>
>catched ;-) hint, hint t/op/*.t ...
>
>Ok, here we go.
>
>>inline op conv_i1(inout INT) {
>> $1= (int)((char)($1));
>
>
> $1 = (INTVAL)((char)($1));
>
>The INTVAL could be a "long long".
That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
>>inline op conv_i2(inout INT) {
>> $1= (int)((short)($1));
>
>
> $1 = (INTVAL)((Parrot_int2)($1));
>
>Parrot_Int2 will be generated by a test in config/auto/somewhere and
>will be "short".
Same here. shorts may not be 16 bits.
Leopold Toetsch
Thanks for the patch. I'll add some config methods and apply it after polishing.
> DISCLAIMER: I don't know anything about how parrot opcodes should be
> written .. So all errors are accidental and I would like somebody to
> point them out to me ..
Pretty well done, modulo minor typos, which a *test* would have catched
;-) hint, hint t/op/*.t ...
Ok, here we go.
> inline op conv_i1(inout INT) {
> $1= (int)((char)($1));
$1 = (INTVAL)((char)($1));
The INTVAL could be a "long long".
> inline op conv_i2(inout INT) {
> $1= (int)((short)($1));
$1 = (INTVAL)((Parrot_int2)($1));
Parrot_Int2 will be generated by a test in config/auto/somewhere and
will be "short".
> inline op conv_i8(out PMC, in INT) {
inline op conv_i8(inout PMC, in INT) {
"inout", because the PMC has to exist in advance, and isn't emerging new
here, like an int or num.
> inline op conv_i8(out PMC, in NUM) {
> $1->vtable->set_integer_native(interpreter, $1,(int)$2);
$1->vtable->set_integer_native(interpreter, $1, $2);
The vtable function has to do the conversion.
> inline op conv_r4(out NUM, in INT) {
> $1= (FLOATVAL)($1);
inline op conv_r4(out NUM, in INT) {
$1 = (FLOATVAL)(float)($2);
^^
leo
Leopold Toetsch
> /*
> ** dotgnu.ops
> */
Thanks applied,
leo
PS please run "perl Configure.pl" after applying.
Nicholas Clark
> Gopal V wrote:
>
> > /*
> > ** dotgnu.ops
> > */
>
> Thanks applied,
I'm surprised that you did your regression tests longhand, rather than having
a data table in perl of input and expected output, and auto-generating parrot
code.
Is there any speed advantage in truncating by casting via a C type
[eg a = (int)(short) b]
rather than and on a bitmask
[eg a = b & 0xFFFF]
?
We're going to have to do that latter to make it work on Crays anyway, so is
a conditional compile to chose between the two worth it?
Nicholas Clark
Leopold Toetsch
>> $1 = (INTVAL)((char)($1));
>>
>> The INTVAL could be a "long long".
>
>
> That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
representation of a char might be different though.
> Same here. shorts may not be 16 bits.
Test for this is in.
leo
Dan Sugalski
The bitmask doesn't sign-extend where the casting will, which could
be an issue.
Dan Sugalski
>Dan Sugalski wrote:
>
>>> $1 = (INTVAL)((char)($1));
>>>
>>>The INTVAL could be a "long long".
>>
>>
>>That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
>
>
>AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
>representation of a char might be different though.
Alas not. That'd be too easy. :(
Nicholas Clark
> At 4:04 PM +0000 11/25/02, Nicholas Clark wrote:
> >Is there any speed advantage in truncating by casting via a C type
> >[eg a = (int)(short) b]
> >rather than and on a bitmask
> >[eg a = b & 0xFFFF]
> >?
> >
> >We're going to have to do that latter to make it work on Crays anyway, so is
> >a conditional compile to chose between the two worth it?
>
> The bitmask doesn't sign-extend where the casting will, which could
> be an issue.
That still lets us halve our conditional code. :-)
(do all the unsigned with masks)
And we ought to make a generic "safe" version of the code for signed
truncation that works for platforms that are any or all of the following
holds
1: no type of that size (eg Crays)
2: signed integer truncation (UTS) [and other OSes on S/390 processors?]
3: not 2s complement [no examples]
Nicholas Clark
David Robins
> Dan Sugalski wrote:
>
> >> $1 = (INTVAL)((char)($1));
> >> The INTVAL could be a "long long".
> >
> > That one needs a sizeof(char) check. chars are *not* 8 bits everywhere.
>
> AFAIK are chars 8 bits by defintion, i.e. C standard. The machine
> representation of a char might be different though.
The standard only requires CHAR_BIT ("number of bits for smallest object
that is not a bit-field (byte)") to be at least 8 (5.2.4.2.1). sizeof(char)
is 1 by definition (6.5.3.4.3).
Dave
Isa. 40:31
Leopold Toetsch
> On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote:
>
>>Gopal V wrote:
>>
>>
>>>/*
>>>** dotgnu.ops
>>>*/
>>>
>>Thanks applied,
>>
>
> I'm surprised that you did your regression tests longhand, rather than having
> a data table in perl of input and expected output, and auto-generating parrot
> code.
Writing a few explicit tests is faster ;-)
> Is there any speed advantage in truncating by casting via a C type
> [eg a = (int)(short) b]
> rather than and on a bitmask
> [eg a = b & 0xFFFF]
> ?
gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
This is listed to take 3 cycles which "and mem" needs too. Inkluding
sign extension would be slower then.
> We're going to have to do that latter to make it work on Crays anyway, so is
> a conditional compile to chose between the two worth it?
My Cray is currently out of order ;-) What is special with it?
> Nicholas Clark
leo
Nicholas Clark
> And we ought to make a generic "safe" version of the code for signed
> truncation that works for platforms that are any or all of the following
> holds
>
> 1: no type of that size (eg Crays)
> 2: signed integer truncation (UTS) [and other OSes on S/390 processors?]
> 3: not 2s complement [no examples]
oops. forgot one:
4: nasal demons (Irix64)
(doing stuff on out of range signed values is undefined behaviour, IIRC)
Nicholas Clark
Nicholas Clark
> Nicholas Clark wrote:
> > I'm surprised that you did your regression tests longhand, rather than having
> > a data table in perl of input and expected output, and auto-generating parrot
> > code.
>
>
> Writing a few explicit tests is faster ;-)
Good answer.
When I have tuits (little white things made of ice, commonly found in hell)
I'll re-write your tests as autogenerated from a table of pathological cases.
> > Is there any speed advantage in truncating by casting via a C type
> > [eg a = (int)(short) b]
> > rather than and on a bitmask
> > [eg a = b & 0xFFFF]
> > ?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
> This is listed to take 3 cycles which "and mem" needs too. Inkluding
> sign extension would be slower then.
and gcc's optimiser is not clever enough to spot bit & cases that are not
equivalent to this? :-(
> > We're going to have to do that latter to make it work on Crays anyway, so is
> > a conditional compile to chose between the two worth it?
>
>
> My Cray is currently out of order ;-) What is special with it?
sizeof(short) == 8
[sizeof (int) == 8 for that matter, and the elements of a sockaddr_in
structure are bitfields, so you can't take the address of them.]
Nicholas Clark
Gopal V
I guess I have more to learn about writing opcodes for parrot ... But
all I can say is you people make it almost too easy :-)
If memory serves me right, Leopold Toetsch wrote:
> The INTVAL could be a "long long".
Ok ... /me sort of needs an Int32 there ...
> Parrot_Int2 will be generated by a test in config/auto/somewhere and
> will be "short".
I asked the IRC room
Nov 25 16:23:21 <gopz> on a related note .. does parrot size types ?
Nov 25 16:23:33 <gopz> sort of like a Int8 I could cast to ?
Nov 25 16:24:19 <pdcawley> I just write the summaries.
Nov 25 16:24:52 <gopz> :-)
.....
Sure, made note of Parrot_Int2 for future use ...
> "inout", because the PMC has to exist in advance, and isn't emerging new
> here, like an int or num.
OK ..
> The vtable function has to do the conversion.
Yes.. especially if I have to use it for Float to Int64 ...
Thanks for correcting my errors,
Gopal V
> I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ...
On nicholas' advice I'm writing out the expected results for all
these opcodes... in the hope that someone more well versed in writing
..t files than me can help ..
conv_i1 & conv_i1_ovf
---------------------
Truncate to between (-128 and 127) so 128 converted to -128 ... 0 to 0
and the basic sign extensions of `char' apply here . 'ovf' suffix
instruction throws an OverFlowException message if the value is not
between -128 and 127. (TODO: throw catchable exceptions)
conv_u1 & conv_u1_ovf
---------------------
To between 0 and 255 ... ovf throws the OverFlowException if value not
in range. Original post bugs out for 256 ... See attached patch
conv_i2 & conv_i2_ovf
---------------------
To between -32768 and 32767 .. ovf for out of range
conv_u2 & conv_u2_ovf
---------------------
To between 0 & 65535 ... ovf for out of range
conv_i4
-------
NUM to int : 3.1415 to 3 , -3.1415 to 3
PMC to int (until csint64.pmc is done...try testing with perlint please ..)
conv_u4
-------
NUM to unsigned int: 3.1415 to 3, -3.1415 is not 3
PMC to int (when csint64.pmc is done ...)
conv_i8
-------
(int to csint64.pmc , NUM to csint64.pmc ...)
conv_r4
-------
(PMC to floatval) ... to be implemented as csint64.pmc
test 3 to 3.000 ... (not much of a test , eh ?)
I'll try to catch up on PMC writing at leisure ..
Florian Weimer
> (doing stuff on out of range signed values is undefined behaviour, IIRC)
Yes, that's right. Some GCC optimizations rely on the fact that
signed integer calculations can never overflow.
Bryan C. Warnock
> Is there any speed advantage in truncating by casting via a C type
> [eg a = (int)(short) b]
> rather than and on a bitmask
> [eg a = b & 0xFFFF]
> ?
>
> We're going to have to do that latter to make it work on Crays anyway
Why?
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Leopold Toetsch
> (do all the unsigned with masks)
Yep
> And we ought to make a generic "safe" version of the code for signed
> truncation that works for platforms that are any or all of the following
> holds
I tried this one:
inline op conv_i1(inout INT) {
#if 1
INTVAL x = $1;
x <<= 24;
x >>= 24;
x &= ~0xff;
x |= $1 & 0xff;
$1 = x;
#else
$1 = (INTVAL)((char)($1));
#endif
goto NEXT();
}
The 24 is something like (INTVAL_SIZE * CHAR_BIT - 8). Should be faster
on pipelined processors then a test for negative and branch.
leo
Leopold Toetsch
> inline op conv_u1_ovf(inout INT) {
> - if($1 >= 0 && $1 <= 256 ) {
> + if($1 >= 0 && $1 <= 255 ) {
Thanks, applied
leo
Nicholas Clark
> Nicholas Clark wrote:
> >Is there any speed advantage in truncating by casting via a C type
> >[eg a = (int)(short) b]
> >rather than and on a bitmask
> >[eg a = b & 0xFFFF]
> >?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
> This is listed to take 3 cycles which "and mem" needs too. Inkluding
> sign extension would be slower then.
What I didn't notice was that the 8 bit signed ops cast via char.
This isn't portable, as char is unsigned on PPC and ARM (and possibly other
platforms.) I've committed this:
--- dotgnu.ops~ Tue Nov 26 18:56:43 2002
+++ dotgnu.ops Sat Nov 30 16:09:08 2002
@@ -18,13 +18,13 @@ Additional opcodes for C# compilation ne
=cut
inline op conv_i1(inout INT) {
- $1 = (INTVAL)((char)($1));
+ $1 = (INTVAL)((signed char)($1));
goto NEXT();
}
inline op conv_i1_ovf(inout INT) {
if($1 >= -128 && $1 <= 127) {
- $1 = (INTVAL)((char)($1));
+ $1 = (INTVAL)((signed char)($1));
}
else {
internal_exception(1, "Overflow exception for conv_i1_ovf\n");
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/