On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote:
> 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 & 0x]
> >?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word
Gopal V wrote:
inline op conv_u1_ovf(inout INT) {
- if($1 >= 0 && $1 <= 256 ) {
+ if($1 >= 0 && $1 <= 255 ) {
Thanks, applied
leo
Nicholas Clark wrote:
(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 <<=
On Mon, 2002-11-25 at 11:04, 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 & 0x]
> ?
>
> We're going to have to do that latter to make it work on Crays anyway
Why?
--
Bryan C.
Nicholas Clark <[EMAIL PROTECTED]> writes:
> (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.
If memory serves me right, Gopal V wrote:
> 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
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 t
On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote:
> 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 test
On Mon, Nov 25, 2002 at 04:39:23PM +, Nicholas Clark wrote:
> 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
Nicholas Clark wrote:
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
On Mon, Nov 25, 2002 at 11:29:01AM -0500, Dan Sugalski wrote:
> At 4:04 PM + 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 & 0x]
> >?
> >
> >We're going to have
On Mon, 25 Nov 2002, Leopold Toetsch wrote:
> 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
> repr
At 4:04 PM + 11/25/02, Nicholas Clark wrote:
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 expec
At 5:01 PM +0100 11/25/02, Leopold Toetsch wrote:
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 o
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.
Same here. s
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
Gopal V wrote:
/*
** dotgnu.ops
*/
Thanks applied,
leo
PS please run "perl Configure.pl" after applying.
At 3:58 PM +0100 11/25/02, Leopold Toetsch wrote:
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
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 ..
Pretty well done, modulo minor typ
If memory serves me right, Rhys Weatherley wrote:
> 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 lng thread ...
Oct 18 20:31:20 no, no, you have it wrong. you don't
*ask* us t
At 10:55 AM +1000 11/25/02, Rhys Weatherley wrote:
Nicholas Clark wrote:
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
Nicholas Clark wrote:
> 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 Sun, Nov 24, 2002 at 10:33:23PM +0100, Florian Weimer wrote:
> Dan Sugalski <[EMAIL PROTECTED]> 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 "ch
At 10:33 PM +0100 11/24/02, Florian Weimer wrote:
Dan Sugalski <[EMAIL PROTECTED]> 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
Dan Sugalski <[EMAIL PROTECTED]> 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
At 8:07 PM +0100 11/24/02, Leopold Toetsch wrote:
Florian Weimer wrote:
"Iacob Alin" <[EMAIL PROTECTED]> 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
Florian Weimer wrote:
"Iacob Alin" <[EMAIL PROTECTED]> 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?
At 1:46 PM +0100 11/24/02, Florian Weimer wrote:
"Iacob Alin" <[EMAIL PROTECTED]> writes:
This might be a stupid question, but are this datatypes going to be
PMCs?
And a related question: What about trapping integer arithmetic?
That'll be done with the standard exception handling mechanism
"Iacob Alin" <[EMAIL PROTECTED]> writes:
> This might be a stupid question, but are this datatypes going to be
> PMCs?
And a related question: What about trapping integer arithmetic?
If memory serves me right, Leopold Toetsch wrote:
>
> > 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,
Leopold Toetsch wrote:
> > 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
On Mon, 18 Nov 2002, Iacob Alin wrote:
> > 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 ve
Iacob Alin wrote:
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
Gopal V wrote:
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?
co
Gopal V said:
> 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?
>
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 q
Rhys Weatherley wrote:
I've been working on some other stuff lately, so this is the
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
I've been working on some other stuff lately, so this is the
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 sect
38 matches
Mail list logo
