Hi —
I've just traced my first 64bit image using the SystemTracer. The ckformat utility reports the Version number as 68002 (i.e. really a 64bit image). As far as I know, the 5.7.4 Cocoa Vm is a Combined (or how to call it) 32bit/64bit vm, but it tells me: This interpreter (vers. 0) cannot read image file (vers. 68002). Press CR to quit... which is a bit dissapointing. Did I misinterpret the line in the Menu bar that says ‘Squeak VM Host 64/32bits’? So Long, -Tobias |
On Wed, Apr 13, 2011 at 10:35:30PM +0200, Tobias Pape wrote:
> Hi ? > > I've just traced my first 64bit image > using the SystemTracer. > > The ckformat utility reports the Version > number as 68002 (i.e. really a 64bit image). > > As far as I know, the 5.7.4 Cocoa Vm is > a Combined (or how to call it) 32bit/64bit vm, > but it tells me: > > This interpreter (vers. 0) cannot read image file (vers. 68002). > Press CR to quit... > > which is a bit dissapointing. Did I misinterpret > the line in the Menu bar that says > ?Squeak VM Host 64/32bits?? > > So Long, > -Tobias The terminology for this is a bit confusing, but hopefully is clarified a little bit here: http://squeakvm.org/squeak64/faq.html The 64bit VM in the 32bit/64bit bundle refers to a VM that is compiled in 64 bit mode such that all the C pointers are 64 bits, as opposed to a 32 bit VM for which pointer size is the same as an int (i.e. 32 bits). Both of these VMs are intended to interpret a normal 32 bit object memory. The image that you traced will now be a 64 bit image, which means that all of the "slots" in the object memory are 64 bits in size, as opposed to the normal 32 bit words and OOPs used in a 32 bit image. What you are looking for now is a VM that understands that object memory format. (As a side note, it is entirely possible to compile that VM in 32 bit mode and still have it interpret the 64 bit image, although I would expect that anyone working with a 64 bit image is going to prefer the 64 bit VM for its effectively unlimited address space.) Are you interested in compiling your own VM from unix sources? If so it is merely a matter of setting one C preprocessor variable (SQ_VI_BYTES_PER_WORD=8) to produce the VM you need. Dave |
Am 2011-04-13 um 22:58 schrieb David T. Lewis: > On Wed, Apr 13, 2011 at 10:35:30PM +0200, Tobias Pape wrote: >> Hi >> > > The terminology for this is a bit confusing, but hopefully is > clarified a little bit here: > > http://squeakvm.org/squeak64/faq.html > > The 64bit VM in the 32bit/64bit bundle refers to a VM that is > compiled in 64 bit mode such that all the C pointers are 64 bits, > as opposed to a 32 bit VM for which pointer size is the same > as an int (i.e. 32 bits). Both of these VMs are intended to > interpret a normal 32 bit object memory. > Ok, so it was a misunderstanding of the > ‘Squeak VM Host 64/32bits’ tag line. > The image that you traced will now be a 64 bit image, which > means that all of the "slots" in the object memory are 64 bits > in size, as opposed to the normal 32 bit words and OOPs used > in a 32 bit image. What you are looking for now is a VM that > understands that object memory format. (As a side note, it > is entirely possible to compile that VM in 32 bit mode and > still have it interpret the 64 bit image, although I would > expect that anyone working with a 64 bit image is going to > prefer the 64 bit VM for its effectively unlimited address > space.) That is, the word size in an Image can differ from the VM pointer size? > > Are you interested in compiling your own VM from unix sources? > If so it is merely a matter of setting one C preprocessor > variable (SQ_VI_BYTES_PER_WORD=8) to produce the VM you need. Yes, I know :) But thanks for the reminder. So Long, -Tobias |
Am 2011-04-13 um 23:52 schrieb Tobias Pape:… … > > Ok, so it was a misunderstanding of the >> ‘Squeak VM Host 64/32bits’ > tag line. > >> The image that you traced will now be a 64 bit image, which >> means that all of the "slots" in the object memory are 64 bits >> in size, as opposed to the normal 32 bit words and OOPs used >> in a 32 bit image. What you are looking for now is a VM that >> understands that object memory format. (As a side note, it >> is entirely possible to compile that VM in 32 bit mode and >> still have it interpret the 64 bit image, although I would >> expect that anyone working with a 64 bit image is going to >> prefer the 64 bit VM for its effectively unlimited address >> space.) > > That is, the word size in an Image can differ from the VM > pointer size? Can somebody me enlighten me on this? How shall a VM be 32bit word- but 64bit pointer-size? Is there any documentation on this? So Long, -Tobias |
On 18.04.2011, at 12:45, Tobias Pape wrote: > > Am 2011-04-13 um 23:52 schrieb Tobias Pape:… > … >> >> Ok, so it was a misunderstanding of the >>> ‘Squeak VM Host 64/32bits’ >> tag line. >> >>> The image that you traced will now be a 64 bit image, which >>> means that all of the "slots" in the object memory are 64 bits >>> in size, as opposed to the normal 32 bit words and OOPs used >>> in a 32 bit image. What you are looking for now is a VM that >>> understands that object memory format. (As a side note, it >>> is entirely possible to compile that VM in 32 bit mode and >>> still have it interpret the 64 bit image, although I would >>> expect that anyone working with a 64 bit image is going to >>> prefer the 64 bit VM for its effectively unlimited address >>> space.) >> >> That is, the word size in an Image can differ from the VM >> pointer size? > > Can somebody me enlighten me on this? > How shall a VM be 32bit word- but > 64bit pointer-size? > Is there any documentation on this? http://squeakvm.org/squeak64/faq.html - Bert - |
In reply to this post by Tobias Pape
On Mon, Apr 18, 2011 at 12:45:51PM +0200, Tobias Pape wrote:
> > Am 2011-04-13 um 23:52 schrieb Tobias Pape:? > ? > > > > Ok, so it was a misunderstanding of the > >> ?Squeak VM Host 64/32bits? > > tag line. > > > >> The image that you traced will now be a 64 bit image, which > >> means that all of the "slots" in the object memory are 64 bits > >> in size, as opposed to the normal 32 bit words and OOPs used > >> in a 32 bit image. What you are looking for now is a VM that > >> understands that object memory format. (As a side note, it > >> is entirely possible to compile that VM in 32 bit mode and > >> still have it interpret the 64 bit image, although I would > >> expect that anyone working with a 64 bit image is going to > >> prefer the 64 bit VM for its effectively unlimited address > >> space.) > > > > That is, the word size in an Image can differ from the VM > > pointer size? > > Can somebody me enlighten me on this? > How shall a VM be 32bit word- but > 64bit pointer-size? > Is there any documentation on this? Think of the VM as a program, just like any other program. And think of the object memory as a bunch of data, either arranged as an array of 32-bit values or an array of 64-bit values. It does not matter if you compile your program with 32-bit pointers (-m32) or 64-bit pointers (-m64), in either case your program can still access its data. Sounds like magic, but that's all there is to it :) Dave |
Am 2011-04-18 um 16:45 schrieb David T. Lewis: > On Mon, Apr 18, 2011 at 12:45:51PM +0200, Tobias Pape wrote: >> […] >>> >> >> Can somebody me enlighten me on this? >> How shall a VM be 32bit word- but >> 64bit pointer-size? >> Is there any documentation on this? > > Think of the VM as a program, just like any other program. And > think of the object memory as a bunch of data, either arranged > as an array of 32-bit values or an array of 64-bit values. It > does not matter if you compile your program with 32-bit pointers > (-m32) or 64-bit pointers (-m64), in either case your program > can still access its data. > > Sounds like magic, but that's all there is to it :) But this implies that the VM does not treat object references as pointers, and I had the impression that this has been the case. Am I wrong? So Long, -Tobias PS: By this definition, it would be ‘easily’ possible to have a VM both execute 64 and 32 bit images, as they are just other datasets. |
On Mon, Apr 18, 2011 at 04:55:00PM +0200, Tobias Pape wrote:
> > Am 2011-04-18 um 16:45 schrieb David T. Lewis: > > > On Mon, Apr 18, 2011 at 12:45:51PM +0200, Tobias Pape wrote: > >> > [?] > >>> > >> > >> Can somebody me enlighten me on this? > >> How shall a VM be 32bit word- but > >> 64bit pointer-size? > >> Is there any documentation on this? > > > > Think of the VM as a program, just like any other program. And > > think of the object memory as a bunch of data, either arranged > > as an array of 32-bit values or an array of 64-bit values. It > > does not matter if you compile your program with 32-bit pointers > > (-m32) or 64-bit pointers (-m64), in either case your program > > can still access its data. > > > > Sounds like magic, but that's all there is to it :) > > But this implies that the VM does not treat object references as > pointers, and I had the impression that this has been the case. > Am I wrong? The terminology can be a bit confusing here if you are thinking only of C pointers. An object reference is a "pointer" to a location in the object memory in the same sense that a (char *) in the C language is a pointer to a location in an array of char. > PS: By this definition, it would be ?easily? possible to > have a VM both execute 64 and 32 bit images, as they are > just other datasets. Absolutely right, although you might not be happy with the resulting performance. Basically you would be dereferencing an "object pointer" at run time to point to the right 32 or 64 bit location. I've thought about trying to do this just for fun, but I'm afraid it would be a lot of work just to make the VM go really slow. But it would be interesting to try it and see how fast you could make it run. Dave |
On 18.04.2011, at 17:17, David T. Lewis wrote: > On Mon, Apr 18, 2011 at 04:55:00PM +0200, Tobias Pape wrote: >> >> Am 2011-04-18 um 16:45 schrieb David T. Lewis: >> >>> On Mon, Apr 18, 2011 at 12:45:51PM +0200, Tobias Pape wrote: >>>> >> [?] >>>>> >>>> >>>> Can somebody me enlighten me on this? >>>> How shall a VM be 32bit word- but >>>> 64bit pointer-size? >>>> Is there any documentation on this? >>> >>> Think of the VM as a program, just like any other program. And >>> think of the object memory as a bunch of data, either arranged >>> as an array of 32-bit values or an array of 64-bit values. It >>> does not matter if you compile your program with 32-bit pointers >>> (-m32) or 64-bit pointers (-m64), in either case your program >>> can still access its data. >>> >>> Sounds like magic, but that's all there is to it :) >> >> But this implies that the VM does not treat object references as >> pointers, and I had the impression that this has been the case. >> Am I wrong? > > The terminology can be a bit confusing here if you are thinking > only of C pointers. An object reference is a "pointer" to a location > in the object memory in the same sense that a (char *) in the C > language is a pointer to a location in an array of char. > >> PS: By this definition, it would be ?easily? possible to >> have a VM both execute 64 and 32 bit images, as they are >> just other datasets. > > Absolutely right, although you might not be happy with the resulting > performance. Basically you would be dereferencing an "object pointer" > at run time to point to the right 32 or 64 bit location. I've thought > about trying to do this just for fun, but I'm afraid it would be a > lot of work just to make the VM go really slow. But it would be > interesting to try it and see how fast you could make it run. > > Dave The VM uses macros to convert from oops to addresses and vice versa. These are used throughout nowadays (thanks in large part to Dave). For the "32 bit VM runs 64 bit image" case, it just ignores the higher 32 bits (thus limiting the image size to 4 GB). For the "64 bit VM runs 32 bit image" case, there is a 64 bit pointer to the start of the object memory, and oops are added to that. - Bert - |
Am 2011-04-18 um 17:55 schrieb Bert Freudenberg: >>> […] >> >> The terminology can be a bit confusing here if you are thinking >> only of C pointers. An object reference is a "pointer" to a location >> in the object memory in the same sense that a (char *) in the C >> language is a pointer to a location in an array of char. >> >>> PS: By this definition, it would be ?easily? possible to >>> have a VM both execute 64 and 32 bit images, as they are >>> just other datasets. >> >> Absolutely right, although you might not be happy with the resulting >> performance. Basically you would be dereferencing an "object pointer" >> at run time to point to the right 32 or 64 bit location. I've thought >> about trying to do this just for fun, but I'm afraid it would be a >> lot of work just to make the VM go really slow. But it would be >> interesting to try it and see how fast you could make it run. >> >> Dave > > The VM uses macros to convert from oops to addresses and vice versa. These are used throughout nowadays (thanks in large part to Dave). > > For the "32 bit VM runs 64 bit image" case, it just ignores the higher 32 bits (thus limiting the image size to 4 GB). > > For the "64 bit VM runs 32 bit image" case, there is a 64 bit pointer to the start of the object memory, and oops are added to that. Thanks to both of you for the clarification. So Long, -Tobias |
Free forum by Nabble | Edit this page |