Hi Dan,

	Many thanks for sharing. I have a few questions 
	and comments below.
 
> 
> A while ago I promised a status report on the 64-bit project. 
>  Well, here it is.
> 
> The first thing I learned is that this is actually much 
> harder than I thought.  The good news is that it's definitely 
> doable, and the VM will be much better for the changes.  
>

	Great to know that it's doable.

>
> Moreover, we've already made good progress.  I say "we" 
> because, Ian Piumarta has been of great help, and has 
> actually done half the work so far.
>

	Aren't we lucky !
 
> 
> What Ian has done
> 
> Ian is strongly rooted in the world of C and C compilers (I 
> am not), and he has performed a wonderful service that I 
> could not.  If you are not familiar with the Slang code for 
> the interpreter, I will tell you that it has always been full 
> of coercions that allow complete anarchy to rein.  This was 
> never elegant, but it also never caused a lot of trouble when 
> almost everything was 32-bit pointers.  Now, however, in 
> addition to bytes (and halfwords), there are things that are 
> supposed to be 32 bits, things that are either 32 or 64 bits 
> depending on the machine, and things that are supposed to be 64 bits.
> 
> Ian's great contribution was to re-cast the basic operations 
> in the Interpreter and ObjectMemory in terms of these 
> different types, in a way that is consistent and that isn't 
> everywhere undermined by coercions to 'char *'.  This has 
> produced two results of immediate value.  The first is that, 
> with these changes and a few load and store macros, it is now 
> possible to build a VM that will run a 32-bit image on a 
> 64-bit machine.  The second is that now, if you make a 
> mistake in usage, e.g., between 32-bit quantities and things 
> that are the size of a native machine word, the compiler will 
> diagnose it before you crash and have to debug it.  Ian's 
> work was done almost entirely by eliminating the damaging 
> coercions, and then using well-typed access routines until 
> the compiler errors went away.  Ian's goal is that, simply by 
> changing load and store macros, it should be possible to 
> generate VMs that will run any of the 4 combinations of 32- 
> or 64-bit images on 32- or 64-bit platforms.
>
>

	This is tres cool !

	Thanks, Ian.
>
> 
> In addition to the Interpreter and ObjectMemory changes, Ian 
> has also rewritten parts of his Unix support code to make it 
> all 64-bit clean.
> The end result of all of these changes is that Ian is now 
> able to generate and compile a 32-bit VM that runs on both 
> 32- and 64-bit platforms.
> 
>

	What are these 64-bit platforms ? 
	(IA64, AMD64 and 64-bit PowerPC...)

>
> What I have done
> 
> On my side, I have written a true 64-bit image in a format 
> that makes the minimum possible changes that can possibly 
> work.  I have also made changes equivalent to Ian's 
> throughout the Simulator and Interpreter, but mine have to 
> address all the changes related to different word sizes in 
> the image.  While some of these details were anticipated in 
> symbolic constants, many are pragmatic.  There are no 
> automatic ways to find the problems, other than, e.g., 
> searching for the integer 4.
> Or 32.  Or 2 (the amount by which something may have been 
> shifted to get a word offset).  Or 3 (a baaad folding of 
> wordsize-1).  And so on.
> Then run the simulator and see where it breaks.  It is a deep 
> immersion in the debugger.  That said, today I can run over 
> 12000 bytecodes, up from only 300 a couple of days ago, so I 
> think I'm getting close.
>

	Hey, that's already 80 percent of the whole image
	(3plus4.image is just barely 15 KB ;-).

	I guess by now you already got a 3 + 4 running ;-)
	 
> 
> What is yet to be done
> 
> I am now in the process of merging Ian's and my changes, 
> after which I will verify that the result works as well as 
> before in both environments (running 32 on 64 natively and 
> running 64 on 64 in the Simulator).  After this, I need to 
> finish finding the 64-bit offset bugs, and produce a VM that 
> will run 64 on 64 natively.
> 

> 
> The Plugins
>
>

	Do you really mean plugins or you-know-what-i-mean ;-)

> 
> The VM that Ian has made to run on a 64 host, and the 
> Simulations that I have made of running a 64-bit image, are 
> both "kernel" VMs.  
> That is, they include the kernel primitives 
>

	In the terminology of MobVM, that's the PrimitivesPlugin 
	(together with InterpreterPlugin and ObjectMemoryPlugin ;-)

>
> and a couple of the heavily used plugins, 
>

	Can you be specific about this.

	What are these two. Are they anything like
	MobVM's PlatformPlugin and WindowPlugin ;-)

>
> but there are a number of large and important plugins that have 
> not yet been touched by our conversions.  We simply let them 
> fail, and they run the failure code as an emulation.
> 
> 
> Calling All Cars
> 

	and don't forget the Cdrs ;-)

>
> We are coming to a time when the 64-bit image runs, and we 
> will have finished the kernel conversion, but there will 
> still be much work to do on the plugins.  It is my hope to 
> enlist some help from the larger Squeak community to complete 
> this task.  Ian and I will document precisely the new 
> conventions for data access in the VM, along with an example 
> conversion of a couple of simple plugins.  As a test-bed, we 
> will produce a 64-on-32 release whose kernel works, but whose 
> plugins need conversion.  A 64-on-32 is a Simulator and VM 
> that can run a 64-bit image on a 32-bit machine.  It is 
> important because it can be tested on any old 32-bit machine, 
> and yet, because the image word size is different from the 
> machine word size, we believe that if code works in that 
> configuration, it is very likely to work in any of the other 
> combinations.
> 
> So stay tuned.  If you know any of the plugins well, or if 
> you know the VM generally and would like to help us finish 
> the job, please let us know (reply to me) and we'll plan to 
> include you in the big plugin party, probably in about a month.
> 
> 
> Version 4
> 
> Remember the Version 4 format changes?  Well, I haven't even 
> thought about them since I wrote my first 64-bit image.  But 
> I can tell you that they are mostly small compared to this 
> task, and it should be easy to fold them into this project 
> toward the end.  My plan is to work on these during the 
> period after the kernel works fully and before all the 
> plugins have been converted.
> 
> We talked about this all getting folded into the 3.8 changes so that
> 3.8 could essentially be the same as 4.0 except for the VM changes for
> 64 bits and associated image-side tweaks.  I originally 
> thought that we might have to rush 3.8 to sync the two 
> schedules, but it now looks like a fairly consistent time 
> frame.  I think it will take until the end of August, and 
> maybe even into the fall for the last of the plugin 
> conversions to be done and the bug tail to have died down.
> 
> 
> Onward and upward...
> 

	Indeed !

	I am really very excited to see all Cars and Cdrs
	put their heads together to make kernels a reality.

	Opportunity like this don't come very often.

	It will be another few decades before there is another 
	chance to break away and move onward and upward to bring
	micro kernel Squeaky thingys to the 128bit platforms.

	Best wishes and I am looking forward to play with the new
	kernel VMs and images for 64-bit platforms.

	We are about to witness TAE televised.
	Yes, it's TAE like Tae Kwondo, 
	not TEA like "Coffee, Tea or Me" 
	or whatever Tea you care to fancy.


	Cheers,

	PhiHo.


	P.S:  Oh, I almost forgot. 
		TAE stands for "The August Evolution".

		I hope I will have some time this summer to play
		with the bleeding edge kernel VM.
 		(and a kernel image as a package ;-)