On Tue Oct 02 10:19:39 2007, pcoch wrote:
> In the file src/mmd.c there is the todo item within mmd_sort_candidates():
>
> * TODO use half of available INTVAL bits
Now in src/multidispatch.c, Parrot_mmd_sort_candidates
--
Will "Coke" Coleda
That fixes it, thanks!
Closing ticket,
Pm
icket/Display.html?id=59374 >
>
>
> Summary: pmc2c produces incorrect code for returning negative
> integer constants, as in RETURN(INTVAL -1)
>
>
> Longer description: In the set_readline_interactive method of the
> ParrotIO PMC line 200 reads
>
>RETURN(IN
nts, as in RETURN(INTVAL -1)
Longer description: In the set_readline_interactive method of the
ParrotIO PMC line 200 reads
RETURN(INTVAL -1);
This is supposed to return a value of -1 when the method is called
and the readline library is not present. However, when run this is
actua
On Thursday 10 July 2008 13:42:07 Andrew Whitworth wrote:
> I found this while tracking a nasty GC-related bug. In
> src/packfile/pf_items.c:PF_fetch_integer, we have the following two
> notes:
>
> XXX assumes C INTVAL size in the PackFile header
>
> XXX assume sizeof (opcode
On Thu, 10 Jul 2008, Andrew Whitworth wrote:
> I found this while tracking a nasty GC-related bug. In
> src/packfile/pf_items.c:PF_fetch_integer, we have the following two
> notes:
>
> XXX assumes C INTVAL size in the PackFile header
>
> XXX assume sizeof (opcode_t) == s
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #56810]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56810 >
I found this while tracking a nasty GC-related bug. In
src/packfile/pf_items.c:PF_fe
On Sat, 26 Apr 2008 11:40:43 -0700
Mark Glines (via RT) <[EMAIL PROTECTED]> wrote:
> # at t/op/sysinfo.t line 53.
> # got: '8'
> # expected: '4'
Found it. The test was checking the op's report of sizeof(INTVAL)
against $PConfig{intsize},
# New Ticket Created by Mark Glines
# Please include the string: [perl #53390]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53390 >
r27167 added a test (from RT #53362) for the "sysinfo" op. And now
that it's being teste
Hi,
I'm trying to get an intuition how Parrot uses the basic data types,
with an eye on INTVAL and opcode_t, what their limits and relationships are.
Given a regular 32-bit x86 box, should it be possible to use Parrot with
a 16-bit short, or a 64-bit long long, intval? The same questio
tes():
* TODO use half of available INTVAL bits
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44317]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44317 >
In r20380 I committed a change:
[config] Making explicit casts to INTVAL to rem
- the {g,s}et__keyed_int vtables take a plain INTVAL now, no more
a pointer to one
- the src_key argument of pmc_keyed functions is gone
- all arithmetic, logical and boolean multi keyed vtables are gone
- as well as set P[k], P[k]
All these were unused. Tests still pass.
This did reduce the
gt;
>
>
> The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the
> Sparc jit.
>
> diff -r -u parrot-orig/config/auto/jit.pl parrot-andy/config/auto/jit.pl
> --- parrot-orig/config/auto/jit.plThu Aug 8 23:18:04 2002
> +++ parrot-andy/config/auto/j
On Thu, Oct 10, 2002 at 06:52:25PM +, Andy Dougherty wrote:
>
> The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the
> Sparc jit.
Seems fair to me. Thanks, applied.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17844]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17844 >
The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the
S
eeds
to be done yet:
- Update classes/*.pmc to conform to the spec (default.pmc should already
be conformant; you can use it for a reference)
- Modify array.pmc and perlarray.pmc to take advantage of INTVAL keys.
- For that matter, finish array.pmc.
- Add opcodes to core.ops for push/pop/shift/uns
At 06:49 PM 1/10/2002 -0600, David M. Lloyd wrote:
> > The problem is that when you save an int constant on the stack in a
> > mixed 32/64-bit system, the int type is 8 bytes but the pointer points
> > to four bytes of int constant and four bytes of... something else. So
> > it has to be copied o
ore.ops,v
retrieving revision 1.74
diff -a -u -r1.74 core.ops
--- core.ops10 Jan 2002 23:14:56 - 1.74
+++ core.ops11 Jan 2002 00:50:04 -
@@ -2292,7 +2292,8 @@
=cut
inline op save(in INT) {
- stack_push(interpreter, interpreter->user_stack, &($1), STACK_ENTRY_I
At 03:47 PM 1/10/2002 -0600, David M. Lloyd wrote:
>Just as the subject says.
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
er->user_stack_top, &($1),
STACK_ENTRY_INT, NULL);
+ INTVAL val = $1;
+ push_generic_entry(interpreter, &interpreter->user_stack_top, &val,
+STACK_ENTRY_INT, NULL);
goto NEXT();
}
- D
<[EMAIL PROTECTED]>
@@ -253,7 +253,7 @@
=cut
inline op print(in INT) {
- printf(INTVAL_FMT, $1);
+ printf(INTVAL_FMT, (INTVAL)$1);
goto NEXT();
}
@@ -301,7 +301,7 @@
break;
default: file = (FILE *)$1;
}
- fprintf(file, INTVAL_FMT, $2);
+ fprintf(file, INTVAL_FMT, (INTVAL)$2
,v
> > retrieving revision 1.68
> > diff -u -r1.68 core.ops
> > --- core.ops 4 Jan 2002 02:36:25 - 1.68
> > +++ core.ops 5 Jan 2002 03:58:14 -
> > @@ -463,8 +463,8 @@
> > =cut
> >
> > op write(i|ic, i|ic) {
> > - INTVAL * i =
ore.ops 4 Jan 2002 02:36:25 - 1.68
> +++ core.ops 5 Jan 2002 03:58:14 -
> @@ -463,8 +463,8 @@
> =cut
>
> op write(i|ic, i|ic) {
> - INTVAL * i = &($2);
> - write($1, i, sizeof(INTVAL));
> + INTVAL i = (INTVAL)$2;
> + write($1, &i, sizeof(
At 09:59 PM 1/4/2002 -0600, David M. Lloyd wrote:
>That's what I thought I remembered; in that case, here's a patch:
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even
2 03:58:14 -0000
@@ -463,8 +463,8 @@
=cut
op write(i|ic, i|ic) {
- INTVAL * i = &($2);
- write($1, i, sizeof(INTVAL));
+ INTVAL i = (INTVAL)$2;
+ write($1, &i, sizeof(INTVAL));
goto NEXT();
}
- D
<[EMAIL PROTECTED]>
On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
>
> So that you can use constants that are up to sizeof(opcode_t) bytes, but
> after that you're on your own. That raises a question, though: Do we
> want to move integer constants into the constant table?
We're guaranteeing 32 bits of i
I'm getting warnings on this bit of core.ops when compiling with 64-bit
ints:
op write(i|ic, i|ic) {
INTVAL * i = &($2); /* <<<< */
write($1, i, sizeof(INTVAL));
goto NEXT();
}
I'm getting a warning that stems from the fact that sizeof(INTVAL) = 8 and
si
Re: PDD 4
To be a pain in the rumpus, I'm in need of some philosophical understandings.
Why is INTVAL one-size-fits-all for Perl? (I can think of two reasons right
off the bat: it's always been that way, and it's simpler/easier to code and
maintain (casting issues and the li
At 04:57 PM 11/23/2001 +0100, Bart Lateur wrote:
>On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote:
>
> >Nah, using an I register as a host-machine-address for jumps doesn't argue
> >for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
> >
On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote:
>Nah, using an I register as a host-machine-address for jumps doesn't argue
>for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
>that uses an int as an absolute address is wrong.
>
>I'm g
At 11:35 AM 11/21/2001 -0800, Brent Dax wrote:
>Dan Sugalski:
># At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
># >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
># > > I propose that we make INTVAL and opcode_t the same size,
># and gaurrenteed
># &g
On Wed, 21 Nov 2001, Dan Sugalski wrote:
> Nah, using an I register as a host-machine-address for jumps doesn't argue
> for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
> that uses an int as an absolute address is wrong.
>
> I'm going to rew
Dan Sugalski:
# At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
# >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
# > > I propose that we make INTVAL and opcode_t the same size,
# and gaurrenteed
# > > to be able to hold a void*.
# > >
# >
# >Seems reasonable to
At 12:19 PM 11/20/2001 -0500, Ken Fox wrote:
>James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
>It sounds like you want portable byte co
At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
>On Mon, 2001-11-19 at 19:59, James Mastros wrote:
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
> >
>
>Seems reasonable to me, since jsr and jump are slat
get the best of both worlds. We, I think, should be able
> to get the bytecode format such that it is mmapable on platforms with the
> same endiannes and sizeof(INTVAL), and nonmmapable otherwise.
There is not much problem on the bytecode side. As we discussed before,
the bytecode is a stream
I
> know others disagree.
I think we can get the best of both worlds. We, I think, should be able
to get the bytecode format such that it is mmapable on platforms with the
same endiannes and sizeof(INTVAL), and nonmmapable otherwise.
-=- James Mastros
--
Put bin Laden out like a bad ci
On Tue, 2001-11-20 at 12:19, Ken Fox wrote:
> James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
> It sounds like you want portable byte co
James Mastros wrote:
> In byteswapping the bytecode ...
>
> I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> to be able to hold a void*.
It sounds like you want portable byte code. Is that a goal? It seems like
we can have either mmap'able byte code
feature-splitting, for example in file opening, some interfaces
> (POSIX open(), for example) want to return an integer (the fd), and some
> (win32 CreateFile(), for example) want to return a void* (the file
> handle). (This is a pointer to a kernel-allocated structure that will
> cause a s
r (the fd), and some
(win32 CreateFile(), for example) want to return a void* (the file
handle). (This is a pointer to a kernel-allocated structure that will
cause a segfault to directly access, BTW, so no GC problems here.)
I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
to
42 matches
Mail list logo
