Prev: FAQ 4.7 How do I multiply matrices?
Next: FAQ 7.10 How do I adopt or take over a module already on CPAN?
From: Sherm Pendley on 29 Jul 2010 16:09
David Filmer <davidfilmer(a)gmail.com> writes:

> On Jul 29, 11:43 am, Sherm Pendley <sherm.pend...(a)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.

I don't think you've thought this through... :-)

If "undef" meant "default value," users couldn't tell at a glance if
an option is active or not - instead, they'd then have to go digging
through their platform's hints file to see what the default value is.

sherm--

--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
From: Peter J. Holzer on 29 Jul 2010 16:46
On 2010-07-29 18:43, Sherm Pendley <sherm.pendley(a)gmail.com> wrote:
> David Filmer <usenet(a)davidfilmer.com> 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

From: Ben Morrow on 29 Jul 2010 17:42

Quoth "Peter J. Holzer" <hjp-usenet2(a)hjp.at>:
> On 2010-07-29 18:43, Sherm Pendley <sherm.pendley(a)gmail.com> wrote:
> > David Filmer <usenet(a)davidfilmer.com> 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.

Ben

From: Reini Urban on 31 Jul 2010 04:53
Ben Morrow schrieb:
>
> Quoth "Peter J. Holzer"<hjp-usenet2(a)hjp.at>:
>> On 2010-07-29 18:43, Sherm Pendley<sherm.pendley(a)gmail.com> wrote:
>>> David Filmer<usenet(a)davidfilmer.com> 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
From: Peter J. Holzer on 31 Jul 2010 14:37
On 2010-07-29 21:42, Ben Morrow <ben(a)morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2(a)hjp.at>:
>> On 2010-07-29 18:43, Sherm Pendley <sherm.pendley(a)gmail.com> wrote:
>> > David Filmer <usenet(a)davidfilmer.com> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: FAQ 4.7 How do I multiply matrices?
Next: FAQ 7.10 How do I adopt or take over a module already on CPAN?