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 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 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 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
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
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 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
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
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
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
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
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
12 matches
Mail list logo
