If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
in [Perl]
|
Prev: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Next: How to synchronize I/O (Parallel::ForkManager)
From: Sherm Pendley on 28 Jul 2010 18:30 David Filmer <usenet(a)davidfilmer.com> writes: > If Perl is compiled on a 32-bit system, and the system is later > upgraded to 64-bit hardware and O/S, would Perl programs then be able > to use the full amount of memory that a 64-bit system would allow? Not unless the upgrade included a 64-bit perl - which, on many *nix systems, it would. > Or would I need to re-compile Perl in the 64-bit environment to access > the larger memory? You'd need a 64-bit Perl interpreter, certainly, but there's no reason you'd *need* to compile it yourself. You could just as easily use the one that shipped with the OS, or download a binary installer if you're using Windows. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Ted Zlatanov on 29 Jul 2010 10:06 On Wed, 28 Jul 2010 23:31:50 +0100 Ben Morrow <ben(a)morrow.me.uk> wrote: BM> (Think about it for a minute. The 32bit perl was, by definition, BM> compiled with 32bit pointers. Thus, it cannot address more than 32 bits' BM> worth of memory, regardless of what the OS can address or what is BM> physically present in the machine.) It's not the case here, but it's not generally true (as you imply) that just because pointers are N-bit you are limited to 2^N memory. You can definitely address more than the pointer size will allow in a segmented memory model, just not necessarily all at once. Ted
From: Sherm Pendley on 29 Jul 2010 10:23 Ted Zlatanov <tzz(a)lifelogs.com> writes: > On Wed, 28 Jul 2010 23:31:50 +0100 Ben Morrow <ben(a)morrow.me.uk> wrote: > > BM> (Think about it for a minute. The 32bit perl was, by definition, > BM> compiled with 32bit pointers. Thus, it cannot address more than 32 bits' > BM> worth of memory, regardless of what the OS can address or what is > BM> physically present in the machine.) > > It's not the case here, but it's not generally true (as you imply) that > just because pointers are N-bit you are limited to 2^N memory. You can > definitely address more than the pointer size will allow in a segmented > memory model, just not necessarily all at once. You can even access it all at once, if your pointer data structures contain both a segment identifier and an address. I remember quite well using memory models and different size pointers in MS-DOS, to access up to 1MB on a 16-bit 8086. Theory and history aside though, I don't think perl uses far pointers, even on a system that supports them. Nor can I think of any such system that's still in use. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Ben Morrow on 29 Jul 2010 10:51 Quoth Sherm Pendley <sherm.pendley(a)gmail.com>: > Ted Zlatanov <tzz(a)lifelogs.com> writes: > > > On Wed, 28 Jul 2010 23:31:50 +0100 Ben Morrow <ben(a)morrow.me.uk> wrote: > > > > BM> (Think about it for a minute. The 32bit perl was, by definition, > > BM> compiled with 32bit pointers. Thus, it cannot address more than 32 bits' > > BM> worth of memory, regardless of what the OS can address or what is > > BM> physically present in the machine.) > > > > It's not the case here, but it's not generally true (as you imply) that > > just because pointers are N-bit you are limited to 2^N memory. You can > > definitely address more than the pointer size will allow in a segmented > > memory model, just not necessarily all at once. > > You can even access it all at once, if your pointer data structures > contain both a segment identifier and an address. I remember quite > well using memory models and different size pointers in MS-DOS, to > access up to 1MB on a 16-bit 8086. ....but then your pointers are more than (32|16) bits wide. A DOS/Win16 __far pointer is a perfectly respectable 32bit pointer. > Theory and history aside though, I don't think perl uses far pointers, > even on a system that supports them. Nor can I think of any such system > that's still in use. PAE on x86 systems, though it's mostly kernel-only. (A bad idea never dies...) Ben
From: Sherm Pendley on 29 Jul 2010 11:29
Ben Morrow <ben(a)morrow.me.uk> writes: > Quoth Sherm Pendley <sherm.pendley(a)gmail.com>: >> Ted Zlatanov <tzz(a)lifelogs.com> writes: >> >> > On Wed, 28 Jul 2010 23:31:50 +0100 Ben Morrow <ben(a)morrow.me.uk> wrote: >> > >> > BM> (Think about it for a minute. The 32bit perl was, by definition, >> > BM> compiled with 32bit pointers. Thus, it cannot address more than 32 bits' >> > BM> worth of memory, regardless of what the OS can address or what is >> > BM> physically present in the machine.) >> > >> > It's not the case here, but it's not generally true (as you imply) that >> > just because pointers are N-bit you are limited to 2^N memory. You can >> > definitely address more than the pointer size will allow in a segmented >> > memory model, just not necessarily all at once. >> >> You can even access it all at once, if your pointer data structures >> contain both a segment identifier and an address. I remember quite >> well using memory models and different size pointers in MS-DOS, to >> access up to 1MB on a 16-bit 8086. > > ...but then your pointers are more than (32|16) bits wide. A DOS/Win16 > __far pointer is a perfectly respectable 32bit pointer. Certainly - that's why I took care to distinguish between a pointer as data structure, vs. a hardware register. Ted wrote "pointer," but I'm pretty sure he meant to refer to hardware registers. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer |