We're talking bytecode. That will indeed be a case of huge arrays of
tightly packed integers.
For bytecode, it's not a big problem, certainly not one I'm worried about.
Machines that want 64-bit ints have, likely speaking, more than enough
memory to handle the larger bytecode.
I'm more
At 12:17 AM 9/24/2001 -0400, Michael Maraist wrote:
Dan wrote:
For bytecode, it's not a big problem, certainly not one I'm worried about.
Machines that want 64-bit ints have, likely speaking, more than enough
memory to handle the larger bytecode.
That's not the problem. The problem is
Dan Sugalski writes:
Speaking from on high here, bytecode is strictly identifiable as to its
characteristics. It will be as portable as a platform implementer wants it
to be. The only 'required' types of bytecode that need to be read are
32-bit integer (both big and little endian) with
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard numbers to support the claims.
Unless you are
On Sun, 23 Sep 2001, Bart Lateur wrote:
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard
At 05:32 PM 9/23/2001 +0200, Bart Lateur wrote:
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much
On Fri, Sep 14, 2001 at 06:00:38AM +0300, Jarkko Hietaniemi wrote:
But in some places Perl 5 has to use a similar union trick, too.
See struct xpvio in sv.h.
Thanks, that swings it; a union it shall be.
Simon
On Thu, Sep 13, 2001 at 06:38:56PM -0400, Dan Sugalski wrote:
I was thinking more that we'd have a type OP for opcodes, for example.
#typedef'd to int, or long, or int32_t, but conceptually standalone so we
could change it if need be. (The possibility still exists that we might
shrink to
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote:
At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote:
I think we should use int32_t instead of IV for all code related
data.
Absolutely. Using an IV was a quick answer to get things working--a first
draft if you will. It needs
On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote:
I think we're also going to need an integer type which is guaranteed to be
the same width as a pointer, so we can freely typecast between the two.
I thought that was what IVs are *for*.
Simon
At 10:06 AM 9/13/2001 +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote:
At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote:
I think we should use int32_t instead of IV for all code related
data.
Absolutely. Using an IV was a quick answer to get
At 06:27 AM 9/13/2001 +0300, Jarkko Hietaniemi wrote:
I think we should use int32_t instead of IV for all code related
data. The IV is 64-bit on 64-bit machine, which is significant waste.
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a
On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote:
If we are going to keep on doing fancy stuff with pointer arithmetic (eg
the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
integer type which is guaranteed to be the same width as a pointer, so
we can
On Thu, Sep 13, 2001 at 09:43:06AM -0700, Damien Neil wrote:
The language lawyer in me insists that I point out that this is
inherently nonportable.
That as may be, Perl 5 runs on nearly 80 platforms and uses this
trick.
Is that portable enough for you?
Simon
If we are going to keep on doing fancy stuff with pointer arithmetic (eg
the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
integer type which is guaranteed to be the same width as a pointer, so
we can freely typecast between the two.
You are not supposed to do fancy
In perl.perl6.internals, you wrote:
On Thu, Sep 13, 2001 at 09:43:06AM -0700, Damien Neil wrote:
The language lawyer in me insists that I point out that this is
inherently nonportable.
That as may be, Perl 5 runs on nearly 80 platforms and uses this
trick.
[interchanging pointers and
At 09:43 AM 9/13/2001 -0700, Damien Neil wrote:
On Thu, Sep 13, 2001 at 10:06:51AM +0100, Philip Kendall wrote:
If we are going to keep on doing fancy stuff with pointer arithmetic (eg
the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
integer type which is guaranteed
In perl.perl6.internals, you wrote:
The attached patch makes all bytecode have a type of int32_t rather than
IV; it also contains the other stuff I needed to get the tests running
on my Alpha (modifications to config.h.in and register.c).
I think this is a bad idea. There simply is no
At 04:55 PM 09-13-2001 -0400, Andy Dougherty wrote:
In perl.perl6.internals, you wrote:
The attached patch makes all bytecode have a type of int32_t rather than
IV; it also contains the other stuff I needed to get the tests running
on my Alpha (modifications to config.h.in and register.c).
I
At 05:08 PM 9/13/2001 -0400, Buddha Buck wrote:
At 04:55 PM 09-13-2001 -0400, Andy Dougherty wrote:
In perl.perl6.internals, you wrote:
The attached patch makes all bytecode have a type of int32_t rather than
IV; it also contains the other stuff I needed to get the tests running
on my Alpha
On Thu, Sep 13, 2001 at 05:08:33PM -0400, Buddha Buck wrote:
At 04:55 PM 09-13-2001 -0400, Andy Dougherty wrote:
In perl.perl6.internals, you wrote:
The attached patch makes all bytecode have a type of int32_t rather than
IV; it also contains the other stuff I needed to get the tests
I'd have thought it made sense to define it as a bytecode_t type, or
some such which could be platform specific.
It is better called opcode_t, since we are not using bytecode anyway.
Hong
On Thu, Sep 13, 2001 at 05:50:06PM +0100, Simon Cozens wrote:
On Thu, Sep 13, 2001 at 09:43:06AM -0700, Damien Neil wrote:
The language lawyer in me insists that I point out that this is
inherently nonportable.
That as may be, Perl 5 runs on nearly 80 platforms and uses this
trick.
At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote:
I think we should use int32_t instead of IV for all code related
data.
Absolutely. Using an IV was a quick answer to get things working--a first
draft if you will. It needs rewriting so all the ops are I32 and the
floating point constants are
I think we should use int32_t instead of IV for all code related
data. The IV is 64-bit on 64-bit machine, which is significant waste.
I always see this claim (why would you use 64 bits unless you really
need them big, they must be such a waste) being bandied around, without
much hard numbers
25 matches
Mail list logo
