On Mar 31, 2004, at 2:47 PM, Alan Grimes wrote:

> om,
>
> I've been obsessed with hacking the VM for the last 5 days or so,  
> often staying up till 3AM watching builds compile....

XCode from Apple allows you to distribute builds using GCC 3.3 to all  
the machines in your house, couldn't say how that is supported
on Linux or other platforms sorry. This helps immensely if you've 4 or  
5 macs about the house and you call also steal cycles from your's son's  
laptop to boot.

> In the meantime, I have made a number of findings that may be of  
> interest:
>
> 1. Many of the computations in the VM involve simple integer pointer  
> arithmetic.
> I propose that instead of being addressed by only "char * memory",  
> there be several pointers,
> char[] = int[] = &x  which will simplify the VM code greatly...  
> Furthermore, making all integer values word-aligned (are they  
> already?) will tremendously improve memory access times on many  
> architectures.a

I have a change set that ensures the returned type from smalltalk Slang  
code matches the returned type extruded by Slang for the C code.
This ensures all those warnings about int foo() returns void.  However  
as Tim and I discovered with a bit of horror is that the official VM  
API headers actually have many calls which have explicit definitions  
indicating they return int, for which plugin developers have written  
things like  return VMCallbackFoo(...);  However VMCallbackFoo() really  
returns void. Changing the VM header file then of course breaks lots of  
plugins.

Mind if you are interested then email me and I will send you the change  
set for your enjoyment.

Certainly have an OOPS address be an oops address (a lot of work) would  
allow us to tackle a 32bit clean VM. Right now you are limited
to the first 2GB of virtual memory. Under os-x if you attempt to  
allocate Squeak in a 1GB memory slot, and conditions are just right,  
then for
some reason the BSD virtual memory mgr will start you at the 2GB  
boundary, which causes immediate failure.


>
> 5. I started experamenting with replacing long-coded block moves with  
> calls to C's " memmove" and "memcpy" where appropriate. The motovation  
> is that the 386 has an ungodly fast "rep movsb " compound instruction  
> which does the  operation at the speed of the FSB. It would be even  
> better to use an inline assembly command for this but to remain  
> portable I started trying to insert the C library calls mentioned.

You should ensure you use mem move functions that provide safety, see  
OpenBSD forums for information on this topic.

> 17. The last major revision to the interpreter was 5 years ago. =\
>
> om

Ooh, I see Tim commented already.

Actually the big change recently was switching to a global construct  
for the VM global variables.
This make a significant change to performance on the PowerPC. It was  
'easy' because of Slang,
although it took me quite awhile to figure out exactly how to make the  
change and not bust things...
That and not forcing every VM developer to stand on their heads...


--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===