Pretty straightforward. Edit call_types.txt. First parameter's the
return type, the rest are the parameter types. Use "p" for any
generic "i've stuffed a struct pointer into a PMC" type. Do please
only add in signatures for functions you're actually going to call
(or are adding if you're adding
At 7:55 PM -0500 11/25/02, Dan Sugalski wrote:
Okay, I've finished the framework for the NCI stuff. The code to
make storing into PMCs, and using strings, needs finishing, but the
rest is in there. (Something went awry with the checkin, so it might
not have been noted properly)
Okay, fetches f
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.
Okay, I've finished the framework for the NCI stuff. The code to make
storing into PMCs, and using strings, needs finishing, but the rest
is in there. (Something went awry with the checkin, so it might not
have been noted properly)
Please be aware that the code in build_nativecall.pl is well pa
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
On Sun, Nov 24, 2002 at 07:02:11PM -0500, David Robins wrote:
> Actually it looks like the problem is in assemble.pl's sub constant_table;
> even though $PConfig{numvalsize} is 12, $PConfig{packtype_n} is 'd' and
> pack('d',$n) uses 8 bytes. This is after hacking NUMVAL_SIZE to 12,
> though, whic
21 matches
Mail list logo
