«

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!

On Jul 29, 11:43*am, Sherm Pendley <sherm.pend...@gmail.com> 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

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

DF> On Jul 29, 11:43*am, Sherm Pendley <sherm.pend...@gmail.com> 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 ---------

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

Ben Morrow schrieb:
>
> Quoth "Peter J. Holzer"<hjp->:
>> 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 -Vtrsize.
>
>>>> 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 -Vtrsize
ptrsize='4';

on 32-bit

$ perl -Vtrsize
ptrsize='8';

on 64-bit

On 2010-07-29 21:42, Ben Morrow <> wrote:
> Quoth "Peter J. Holzer" <hjp->:
>> 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 -Vtrsize.

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