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. The IV is also platform specific, and has caused some
nasty problems so far.
Hong
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 N6
> 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 numbe
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 nee
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 answ
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
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 fr
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 guara
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 nee
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 guaran
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
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
>> >
At 11:44 PM 9/13/2001 +0100, Nicholas Clark wrote:
>If bytecode is 32 bit, and we want an opaque C type to be a thing capable
>of representing 32 bits, as ANSI allows structure padding I believe that
>there's no guarantee that sizeof an array of two of them is 8 chars
>(by which I am assuming 64bi
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
> 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
> tric
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
> shrin
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
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
> >mu
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
> 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 ar
On Sun, 23 Sep 2001 21:45:39 -0400, Dan Sugalski wrote:
>>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 th
> >>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 byteco
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 pro
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
30 matches
Mail list logo
