How can I tell if a perl interpreter was built for 32 or 64 bits?

Discussion in 'Perl Misc' started by David Filmer, Jul 29, 2010.

  1. David Filmer

    David Filmer Guest

    How can I tell if a perl interpreter was built at 32 or 64 bits?

    If I do "perl -V" I see:
    use64bitint=undef, use64bitall=undef
    So maybe it's 32-bits, but that doesn't really seem definitive.

    Thanks!
     
    David Filmer, Jul 29, 2010
    #1
    1. Advertising

  2. David Filmer

    David Filmer Guest

    On Jul 29, 11:43 am, Sherm Pendley <> wrote:

    > Yep, that's how you can tell. Why did you ask if you already knew?


    Because the flags don't say "use64bitint=no" - they say undef. So, if
    the interpreter is built on a 64-bit system, and those flags aren't
    defined, I thought it would probably default to 64-bits. That's how
    it _should_ work, IMHO.

    --
    http://DavidFilmer.com
     
    David Filmer, Jul 29, 2010
    #2
    1. Advertising

  3. David Filmer

    Uri Guttman Guest

    >>>>> "DF" == David Filmer <> writes:

    DF> On Jul 29, 11:43 am, Sherm Pendley <> wrote:
    >> Yep, that's how you can tell. Why did you ask if you already knew?


    DF> Because the flags don't say "use64bitint=no" - they say undef. So, if
    DF> the interpreter is built on a 64-bit system, and those flags aren't
    DF> defined, I thought it would probably default to 64-bits. That's how
    DF> it _should_ work, IMHO.

    not really. undef is a false value in perl so it is also false in the
    config file. in fact the Config.pm module is used to dump those values
    with -V so that is showing what is really there which is undef (or
    possibly even doesn't exist which has a value of undef).

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Jul 29, 2010
    #3
  4. On 2010-07-29 18:43, Sherm Pendley <> wrote:
    > David Filmer <> writes:
    >> How can I tell if a perl interpreter was built at 32 or 64 bits?


    That depends on what you mean by "built at X bits".

    IV size? pointer size? Register size of the architecture?
    I'm guessing the latter.

    >> If I do "perl -V" I see:
    >> use64bitint=undef, use64bitall=undef

    >
    > Yep, that's how you can tell.


    No, not really.

    use64bitint says whether IVs are 64 bit. This can be achieved on a 32
    bit system if "long long" is available:

    |Summary of my perl5 (revision 5 version 12 subversion 1) configuration:
    |
    | Platform:
    | osname=linux, osvers=2.6.32-3-686, archname=i686-linux-64int
    [...]
    | use64bitint=define, use64bitall=undef, uselongdouble=undef
    [...]
    | ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8


    OTOH, you probably can have a 32bit IV even on a 64 bit system.

    use64bitall might be more conclusive (at least you need both 64 bit ints
    and 64 bit pointers to get it, which almost certainly means a 64bit
    architecture).

    If you want to know the architecture, look at archname (although the
    names may not be very descriptive).

    hp
     
    Peter J. Holzer, Jul 29, 2010
    #4
  5. David Filmer

    Reini Urban Guest

    Ben Morrow schrieb:
    >
    > Quoth "Peter J. Holzer"<>:
    >> On 2010-07-29 18:43, Sherm Pendley<> wrote:
    >>> David Filmer<> writes:
    >>>> How can I tell if a perl interpreter was built at 32 or 64 bits?

    >>
    >> That depends on what you mean by "built at X bits".
    >>
    >> IV size? pointer size? Register size of the architecture?
    >> I'm guessing the latter.

    >
    > 'Register size of the architecture' is an ambiguous term. An x86-64
    > machine running in compatibility mode (which is how 32bit programs are
    > run under a 64bit OS) has 16bit, 32bit and 64bit registers available,
    > but the default address size is still 32 bits.
    >
    > The normal meaning of this question is 'what size are my pointers', to
    > which the answer is perl -V:ptrsize.
    >
    >>>> If I do "perl -V" I see:
    >>>> use64bitint=undef, use64bitall=undef
    >>>
    >>> Yep, that's how you can tell.

    >>
    >> No, not really.
    >>
    >> use64bitint says whether IVs are 64 bit. This can be achieved on a 32
    >> bit system if "long long" is available:
    >>
    >> |Summary of my perl5 (revision 5 version 12 subversion 1) configuration:
    >> |
    >> | Platform:
    >> | osname=linux, osvers=2.6.32-3-686, archname=i686-linux-64int
    >> [...]
    >> | use64bitint=define, use64bitall=undef, uselongdouble=undef
    >> [...]
    >> | ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
    >> Off_t='off_t', lseeksize=8
    >>
    >> OTOH, you probably can have a 32bit IV even on a 64 bit system.
    >>
    >> use64bitall might be more conclusive (at least you need both 64 bit ints
    >> and 64 bit pointers to get it, which almost certainly means a 64bit
    >> architecture).

    >
    > It's possible at least on some architectures to choose whether to
    > use64bitall or not (otherwise the option wouldn't exist). As I said
    > earlier, the only values that actually matter are ptrsize and ivsize.


    Yes, yes, yes.
    The only right answer is

    $ perl -V:ptrsize
    ptrsize='4';

    on 32-bit

    $ perl -V:ptrsize
    ptrsize='8';

    on 64-bit
     
    Reini Urban, Jul 31, 2010
    #5
  6. On 2010-07-29 21:42, Ben Morrow <> wrote:
    > Quoth "Peter J. Holzer" <>:
    >> On 2010-07-29 18:43, Sherm Pendley <> wrote:
    >> > David Filmer <> writes:
    >> >> How can I tell if a perl interpreter was built at 32 or 64 bits?

    >>
    >> That depends on what you mean by "built at X bits".
    >>
    >> IV size? pointer size? Register size of the architecture?
    >> I'm guessing the latter.

    >
    > 'Register size of the architecture' is an ambiguous term. An x86-64
    > machine running in compatibility mode (which is how 32bit programs are
    > run under a 64bit OS) has 16bit, 32bit and 64bit registers available,


    According to http://support.amd.com/us/Embedded_TechDocs/24593.pdf (S.
    1.3 Operating Modes, p. 11) this is not true. In compatibility mode the
    GPRs are limited to 32 bit. But that's not the point.

    > but the default address size is still 32 bits.


    I would define a "32 bit program" or a "program built at/for 32 bits" as
    an executable which was built to run at an architecture with 32 bit
    registers (for example 686). It may run on an architecture where larger
    registers are available but that't not the target architecture.

    Of course there may be architectures with different register sizes (in
    fact the x86 architecture is a good example because it has always had 80
    bit FP registers (on an optional coprocessor until the 486), and in
    this case "register size" is ambiguous.

    > The normal meaning of this question is 'what size are my pointers', to
    > which the answer is perl -V:ptrsize.


    On the (2)86 a pointer could be (and frequently was) 32 bit. On a 386 a
    pointer could be 48 bit (although I don't know any OS which ever
    implemented it). I'd hesitate to call a program using far pointers on a
    286 a 32-bit program and on a 386 a 48-bit program. To me the 286 was a
    16-bit architecture and the 386 a 32 bit architecture, and I would call
    programs built for the 286 16-bit programs and for the 386 32-bit
    programs. (there is another ambiguity here: On the 386, a program was
    able to access the 32-bit registers in real or 16-bit protected mode,
    and there were programs which did this. They may even have used only
    near (16-bit) pointers - were the 16-bit or 32-bit programs? But I'm
    digressing)


    [about the (lack of) relevance of use64bitint and iv_size]

    >> use64bitall might be more conclusive (at least you need both 64 bit ints
    >> and 64 bit pointers to get it, which almost certainly means a 64bit
    >> architecture).

    >
    > It's possible at least on some architectures to choose whether to
    > use64bitall or not (otherwise the option wouldn't exist).


    I meant that use64bitall=define is an indication that the architecture
    supports 64 bit pointers, and therefore is almost certainly a 64 bit
    architecture (but not necessarily: It could be segmented or
    capability-based). I didn't mean to imply that use64bitall=undef means a
    32 bit architecture.

    hp
     
    Peter J. Holzer, Jul 31, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Umesh

    Can we replace 8 bits by 2 bits?

    Umesh, Jan 5, 2007, in forum: C Programming
    Replies:
    22
    Views:
    657
    Randy Howard
    Jan 10, 2007
  2. Umesh
    Replies:
    23
    Views:
    729
    Randy Howard
    Jan 10, 2007
  3. Zhi
    Replies:
    2
    Views:
    1,175
    Mike Treseler
    Oct 9, 2007
  4. alex23
    Replies:
    4
    Views:
    240
    Asun Friere
    Jul 16, 2009
  5. Dilbert
    Replies:
    0
    Views:
    873
    Dilbert
    Nov 10, 2011
Loading...

Share This Page