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
On Thursday 04 October 2001 11:22 am, Dan Sugalski wrote:
> At 11:16 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
> >Since pointers and integers are now considered incommensurate, the only
> >integer that can be safely converted to a pointer is the constant 0.
> > The result of converting any oth
At 11:16 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
>Since pointers and integers are now considered incommensurate, the only
>integer that can be safely converted to a pointer is the constant 0. The
>result of converting any other integer to a pointer is machine dependent.
Since the only place
At 07:16 PM 10/4/2001 +0400, Timur Safin wrote:
>ptrdiff_t
> Signed integral type of the result of subtracting two pointers.
Ah, signed. Forgot about that.
size_t would be better, then. Absolute addresses are unsigned.
Dan
---
On Thursday 04 October 2001 11:08 am, Bryan C. Warnock wrote:
> In C9x, pointer-integer conversions (except for 0) aren't guaranteed for
> doing pointer arithmetic. (There was a good explanation that I ran across
> the other day, but I can't seem to find it now.)
Found it. The ANSI rationale
E_T
typedef unsigned long size_t;
#endif
Where sizeof(long)==8 while sizeof(int)==4. Taking into account the 64-bit nature of
the Alpha it should be faster to operate with long then with int (although I could
speculate on this respect).
Hence yes, INTVAL will be better to represent as size_t (if
On Thursday 04 October 2001 10:48 am, Gibbs Tanton - tgibbs wrote:
> My ANSI and ISO Standard C reference manual (Plauger and Brodie) has it
> listed in with the comment:
>
> ptrdiff_t( which is the type of the subtract operator when its operands
> are both pointers to data objects ).
>
> Althoug
-Original Message-
From: Bryan C. Warnock
To: Gibbs Tanton - tgibbs; '[EMAIL PROTECTED]'
Sent: 10/4/2001 9:41 AM
Subject: Re: replacing INTVAL in memory and register
On Thursday 04 October 2001 10:38 am, Gibbs Tanton - tgibbs wrote:
> INTVAL is used in memory and register to cast a
On Thursday 04 October 2001 10:38 am, Gibbs Tanton - tgibbs wrote:
> INTVAL is used in memory and register to cast a pointer to an integer for
> mathematical operators. Instead of using INTVAL I propose we use
> ptrdiff_t or size_t (with my preference being the former). It would not
At 09:38 AM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>INTVAL is used in memory and register to cast a pointer to an integer for
>mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t
>or size_t (with my preference being the former).
Is ptrdiff_t a base type t
INTVAL is used in memory and register to cast a pointer to an integer for
mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t
or size_t (with my preference being the former). It would not be used
anywhere else, just when we need to do mathematics on pointers. Both are
52 matches
Mail list logo
