Hi All,
I am forwarding a message from David (Thanks a lot to him) who pointed that SystemTracer2 should be run with a non-cog VM otherwize, the generated image is not usable.
Does someone know why? Thanks,
#Luc
---------- Forwarded message ---------- From: David T. Lewis lewis@mail.msen.com Date: 2011/12/30
Actually, I think I just spotted the problem. If I use an interpreter VM to run the system tracer, then load the cloned image with an interpreter VM, then save the cloned image, then run it under Cog, it works.
If I use Cog to do the system tracing, the cloned image does not work.
If I use the interpreter VM to trace the image, then run the cloned image under Cog, it does not work.
If I run the same cloned image on an interpreter VM, it works.
After the cloned image has been saved from an interpreter VM, it can be used with Cog.
I do not know the reason for this, but that is what I am seeing.
I am using Linux, but on a Mac you can probably use Ian's unix VM for Mac from http://squeakvm.org/unix/ and see if you get the same results.
Dave
system tracer writes an image 6404 version while cog uses 6405 i dont remember what is the difference between them, can someone remind me?
On 31 December 2011 10:49, Luc Fabresse luc.fabresse@gmail.com wrote:
Hi All,
I am forwarding a message from David (Thanks a lot to him) who pointed that SystemTracer2 should be run with a non-cog VM otherwize, the generated image is not usable.
Does someone know why? Thanks,
#Luc
---------- Forwarded message ---------- From: David T. Lewis lewis@mail.msen.com Date: 2011/12/30
Actually, I think I just spotted the problem. If I use an interpreter VM to run the system tracer, then load the cloned image with an interpreter VM, then save the cloned image, then run it under Cog, it works.
If I use Cog to do the system tracing, the cloned image does not work.
If I use the interpreter VM to trace the image, then run the cloned image under Cog, it does not work.
If I run the same cloned image on an interpreter VM, it works.
After the cloned image has been saved from an interpreter VM, it can be used with Cog.
I do not know the reason for this, but that is what I am seeing.
I am using Linux, but on a Mac you can probably use Ian's unix VM for Mac from http://squeakvm.org/unix/ and see if you get the same results.
Dave
On Sat, Dec 31, 2011 at 2:37 PM, Igor Stasenko siguctua@gmail.com wrote:
system tracer writes an image 6404 version while cog uses 6405 i dont remember what is the difference between them, can someone remind me?
You mean 6504 (6502 + 2) and 6505 (6504+1).
6502 = the Squeak V3 format with blue-book BlockContext (but _without_ BlockClosure support). 6504 = the Squeak V3 format with blue-book BlockContext /and/ BlockClosure support. 6505 = the Squeak V3 format with BlockClosure support (but _without_ BlockContext support).
One simple approach is to have the SystemTracer write out an image with the format of the VM. This is Smalltalk vmParameterAt: 41
On 31 December 2011 10:49, Luc Fabresse luc.fabresse@gmail.com wrote:
Hi All,
I am forwarding a message from David (Thanks a lot to him) who pointed
that SystemTracer2 should be run with a non-cog VM otherwize, the generated image is not usable.
Does someone know why? Thanks,
#Luc
---------- Forwarded message ---------- From: David T. Lewis lewis@mail.msen.com Date: 2011/12/30
Actually, I think I just spotted the problem. If I use an interpreter VM to run the system tracer, then load the cloned image with an
interpreter
VM, then save the cloned image, then run it under Cog, it works.
If I use Cog to do the system tracing, the cloned image does not work.
If I use the interpreter VM to trace the image, then run the cloned image under Cog, it does not work.
If I run the same cloned image on an interpreter VM, it works.
After the cloned image has been saved from an interpreter VM, it can be used with Cog.
I do not know the reason for this, but that is what I am seeing.
I am using Linux, but on a Mac you can probably use Ian's unix VM for Mac from http://squeakvm.org/unix/ and see if you get the same results.
Dave
-- Best regards, Igor Stasenko.
For record keeping you can refer to class ImageFormat (package ImageFormat in the VMMaker repository):
(ImageFormat fromInteger: 6504) description ==> 'A 32-bit image with closure support and no native platform float word order requirement (6504)'
(ImageFormat fromInteger: 6505) description ==> 'A 32-bit image with closure support and float words stored in native platform order (6505)'
With respect to the image itself (as opposed to the image file header), the difference is that format 6505 stores 8-byte floats in native platform word order, while the traditional Squeak image format stores them in big-endian word order (hence word-swapped when running on Intel).
Cog also adds some additional information to the image file header, although this is probably not relevant to image tracing.
Dave
On Sat, Dec 31, 2011 at 03:13:23PM -0800, Eliot Miranda wrote:
On Sat, Dec 31, 2011 at 2:37 PM, Igor Stasenko siguctua@gmail.com wrote:
system tracer writes an image 6404 version while cog uses 6405 i dont remember what is the difference between them, can someone remind me?
You mean 6504 (6502 + 2) and 6505 (6504+1).
6502 = the Squeak V3 format with blue-book BlockContext (but _without_ BlockClosure support). 6504 = the Squeak V3 format with blue-book BlockContext /and/ BlockClosure support. 6505 = the Squeak V3 format with BlockClosure support (but _without_ BlockContext support).
One simple approach is to have the SystemTracer write out an image with the format of the VM. This is Smalltalk vmParameterAt: 41
On 31 December 2011 10:49, Luc Fabresse luc.fabresse@gmail.com wrote:
Hi All,
I am forwarding a message from David (Thanks a lot to him) who pointed
that SystemTracer2 should be run with a non-cog VM otherwize, the generated image is not usable.
Does someone know why? Thanks,
#Luc
---------- Forwarded message ---------- From: David T. Lewis lewis@mail.msen.com Date: 2011/12/30
Actually, I think I just spotted the problem. If I use an interpreter VM to run the system tracer, then load the cloned image with an
interpreter
VM, then save the cloned image, then run it under Cog, it works.
If I use Cog to do the system tracing, the cloned image does not work.
If I use the interpreter VM to trace the image, then run the cloned image under Cog, it does not work.
If I run the same cloned image on an interpreter VM, it works.
After the cloned image has been saved from an interpreter VM, it can be used with Cog.
I do not know the reason for this, but that is what I am seeing.
I am using Linux, but on a Mac you can probably use Ian's unix VM for Mac from http://squeakvm.org/unix/ and see if you get the same results.
Dave
-- Best regards, Igor Stasenko.
-- best, Eliot
For us what is really strange is that
if we use Cog we cannot do anything expect Beeper primitiveBeep in our mini kernel (no UI, one single thread….)
If we open the **same** image we can open file and write into them. Since we do not have a debugger, nor a UI. We cannot say why but we suspect that that we could run Beeper primitiveBeep because this is a primitive
Eliot do you have an idea of what would prevent to run something once the image is traced?
Stef
On Jan 1, 2012, at 1:36 AM, David T. Lewis wrote:
For record keeping you can refer to class ImageFormat (package ImageFormat in the VMMaker repository):
(ImageFormat fromInteger: 6504) description ==> 'A 32-bit image with closure support and no native platform float word order requirement (6504)'
(ImageFormat fromInteger: 6505) description ==> 'A 32-bit image with closure support and float words stored in native platform order (6505)'
With respect to the image itself (as opposed to the image file header), the difference is that format 6505 stores 8-byte floats in native platform word order, while the traditional Squeak image format stores them in big-endian word order (hence word-swapped when running on Intel).
Cog also adds some additional information to the image file header, although this is probably not relevant to image tracing.
Dave
On Sat, Dec 31, 2011 at 03:13:23PM -0800, Eliot Miranda wrote:
On Sat, Dec 31, 2011 at 2:37 PM, Igor Stasenko siguctua@gmail.com wrote:
system tracer writes an image 6404 version while cog uses 6405 i dont remember what is the difference between them, can someone remind me?
You mean 6504 (6502 + 2) and 6505 (6504+1).
6502 = the Squeak V3 format with blue-book BlockContext (but _without_ BlockClosure support). 6504 = the Squeak V3 format with blue-book BlockContext /and/ BlockClosure support. 6505 = the Squeak V3 format with BlockClosure support (but _without_ BlockContext support).
One simple approach is to have the SystemTracer write out an image with the format of the VM. This is Smalltalk vmParameterAt: 41
On 31 December 2011 10:49, Luc Fabresse luc.fabresse@gmail.com wrote:
Hi All,
I am forwarding a message from David (Thanks a lot to him) who pointed
that SystemTracer2 should be run with a non-cog VM otherwize, the generated image is not usable.
Does someone know why? Thanks,
#Luc
---------- Forwarded message ---------- From: David T. Lewis lewis@mail.msen.com Date: 2011/12/30
Actually, I think I just spotted the problem. If I use an interpreter VM to run the system tracer, then load the cloned image with an
interpreter
VM, then save the cloned image, then run it under Cog, it works.
If I use Cog to do the system tracing, the cloned image does not work.
If I use the interpreter VM to trace the image, then run the cloned image under Cog, it does not work.
If I run the same cloned image on an interpreter VM, it works.
After the cloned image has been saved from an interpreter VM, it can be used with Cog.
I do not know the reason for this, but that is what I am seeing.
I am using Linux, but on a Mac you can probably use Ian's unix VM for Mac from http://squeakvm.org/unix/ and see if you get the same results.
Dave
-- Best regards, Igor Stasenko.
-- best, Eliot
vm-dev@lists.squeakfoundation.org