Hi David,<br><br><div class="gmail_quote">On Sun, Mar 18, 2012 at 6:30 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On a Linux system, the data types that represent file positions are 32 bits<br>
in size when the program is compiled in 32-bit mode (using the -m32 compiler<br>
option), and they are 64 bits in size when the program is compiled in 64-bit<br>
mode. The relevant data types are off_t and size_t, and if you compile the<br>
following in 32-bit mode (-m32) and compare the same program compiled in<br>
64-bit mode, you can see the difference:<br>
<br>
#include <stdio.h><br>
#include <sys/types.h><br>
main() {<br>
printf("off_t is %d\n", sizeof(off_t));<br>
printf("size_t is %d\n", sizeof(size_t));<br>
}<br></blockquote><div><br></div><div>Not quite. One can modify this by defining something like _LARGEFILE64_SOURCE at compile time. e.g. see _LARGEFILE_SOURCE _LARGEFILE64_SOURCE & _FILE_OFFSET_BITS in <a href="http://www.delorie.com/gnu/docs/glibc/libc_13.html">http://www.delorie.com/gnu/docs/glibc/libc_13.html</a>. I'll check that the appropriate one is defined when building Cog asap.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The VM is a program like any other, so when compiled as a 32-bit application,<br>
file operations will fail if sizes and offsets exceed the range of an<br>
off_t data type.<br>
<br>
If you are dealing with very large files, you will need to consider using<br>
a VM compiled in 64-bit mode, or you will need to find some mechanism to<br>
limit data file size.<br>
<br>
Cog is currently limited to 32-bit mode, so changing VMs may not be<br>
acceptable if performance is a key concern. An interpreter VM compiled<br>
in 64-bit mode is entirely suitable for server applications, except that<br>
FFI and certain plugins will not be available.<br>
<br>
Most users do not require large address spaces or data files, and the VMs<br>
in general circulation are compiled in 32-bit mode in order to provide<br>
support for a wide range of plugins.<br>
<br>
Dave<br>
<div class="im"><br>
<br>
Sun, Mar 18, 2012 at 11:10:17AM -0500, Chris Muller wrote:<br>
> Does a 32-bit VM mean that no individual primitives can have an<br>
> argument or return value greater than 32 bits? File-size is something<br>
> that, in 2012 with HD video recording devices, can very easily exceed<br>
> 32-bits so it would seem to be overkill for ALL objects to have to be<br>
> larger than 32 bits (as in a 64-bit VM) just for this one primitive..<br>
><br>
><br>
> On Thu, Mar 15, 2012 at 11:45 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> > On Thu, Mar 15, 2012 at 10:35:47PM -0500, Chris Muller wrote:<br>
> >> I have a 3.2GB file, but Squeak reports its #fileSize as 0 (in the<br>
</div>> >> DirectoryEntry). ?It seems to occur for any file that large.<br>
> >><br>
> >> Is it an overflow condition in the VM? ?Is it possible to fix?<br>
<div><div></div><div class="h5">> ><br>
> > It works fine with an interpreter VM compiled in 64-bit mode. I<br>
> > cannot look into it in detail now, but an educated guess is that<br>
> > it relates to the definition of size_t for 32-bit programs, and<br>
> > that for the kind of work you are doing here a 64-bit VM may be<br>
> > in order.<br>
> ><br>
> > Dave<br>
> ><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>