Dan,

> 
> First the good news:
> We can now generate, from a single set of sources, four 
> different VMs...
> 
> 	One that will run a 32-bit image on a 32-bit host
> 		same old VM
> 	One that will run a 32-bit image on a 64-bit host
> 		needed to run on 64-bit machines
> 	One that will run a 64-bit image on a 32-bit host
> 		great for testing 64-bit VM on 32-bit machines
> 	One that will run a 64-bit image on a 64-bit host
> 		the thing we were after
> 
> ... and all of them work!
> 
> Ian and I worked together on this, with Ian focused on issues 
> of C translation rules, and me focused on properly 
> generalizing all the occurrences of 4 (bytes per word), 2 
> (shift count), and lots of other things derived therefrom.  I 
> also wrote a tracer subclass that will write images in a 
> 64-bit format, and Ian also contributed the brilliant 
> framework that enabled this four-way compatibility.
> 

	Thanks for sharing the good news ...

> 
> Now the fine print...
> The 64-bit format is the simplest change that could work, not 
> the simplest format that could work.  

 	... and the fine prints. 
	(good to know that there are no bad news ;-)

> For those who understand the object current format, 
> here is the change:
> 
> 	All object pointers are 64 bits as you'd expect.
> 
> 	SmallIntegers are still 31-bits, although stored 
> 	sign-extended to 63 bits (plus tag bit).
> 
> 	32-bit Object header:
> 	3 bits	reserved for gc (mark, old, dirty)
> 	12 bits	object hash (for HashSets)
> 	5 bits	compact class index
> 	4 bits	object format (includes low bits of size in bytes)
> 	6 bits	object size in 32-bit words
> 	2 bits	header type (0: 3-word, 1: 2-word, 2: 
> 					forbidden, 3: 1-word)
> 

	I guess there is no changes from the current 32-bit header ?

	I've been wondering why header type  wasn't like this:

		1 : 1-word
		2 : 2-word
		3 : 3-word
		0 : reserved (this is for headless objects only ;-)

> 	64-bit Object header:
> 	32 bits	all zero
> 	3 bits	reserved for gc (mark, old, dirty)
> 	12 bits	object hash (for HashSets)
> 	5 bits	compact class index
> 	4 bits	object format (includes low bits of size in bytes)
> 	5 bits	object size in 64-bit words
> 	1 bit	extra 4-bit of size in bytes or 32-bit words
> 	2 bits	header type (0: 3-word, 1: 2-word, 2: 
> 					forbidden, 3: 1-word)
> 
> 	The object size field had to be in units of 8 bytes, 
> 	and therefore three
> 	low-order bits are required instead of the 2 that are 
> 	in the current format field.
> 	I simply used the vacated bit of the word size field 
> 	for the 3rd low bit.
> 	It's Byzantine, but it works with few changes.
> 

	How much bigger is the 64-bit image compared to
	32-bit image for, say, the 3.7 gamma ?

>	
> We have only converted the core interpreter and 3 plugins 
> (BitBlt, BalloonEngine and FilePlugin).  This is enough to 
> run Squeak and test it.    Moreover we now have a lot of 
> experience with the conversion process, and we will write 
> down a set of guidelines for converting the remaining 
> plugins. We may ask for help from the Squeak community in 
> converting the remaining plugins, and also image segment 
> code.  In some case there is clearly someone who knows the 
> code much better than us, and for the rest, there may simply 
> be others who want a complete 64-bit system.
>
	Is BalloonEngine just B2DPlugin or it also includes
	B3DAcceleratorPlugin ?

	I am interested to know how FilePlugin is implemented.

>
> We have not done *any* of the Version 4 changes.  The first 
> reason is that we need to release this work soon before we 
> get out of phase with other Squeak progress.  The second is 
> some discussion in our group about the possibility of making 
> *much* more major changes.  As soon as we get clearer about 
> this and confirm our intention, we'll have more to say about 
> it.  If were to go ahead with such a rethink, then any time 
> spent of Version 4 would have been wasted.
>
	This sounds good. Can you disclose what are these
	*much* more major changes that are being discussed ?

>
> We have not done any testing beyond the point of bringing up 
> a morphic screen with Squeak mouse, opening a browser and 
> running the benchmarks.  There is lots to test, and surely a 
> number of bugs yet to be found.  The Squeak community can be 
> of enormous help here.
> 

	I hope you did test " 3 + 4 " ;-)

> 
> Next steps...
> Ian and I are both pretty busy, but it is our hope to test 
> the build process some more, and put out a complete source 
> tree with this work in the course of the next month.  At that 
> point others can help us to convert the remaining plugins and 
> to test the system as a whole.
> 

	My next months are kind of busy, summer is over.

	Please drop me a note if there is an opportunity for
	an earlybird preview of Windows (IA32/IA64) ports.


	Cheers,

	PhiHo.