Report from a novice VM h4x0r.
John M McIntosh
johnmci at mac.com
Thu Apr 1 00:38:22 UTC 2004
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
========================================================================
===
More information about the Squeak-dev
mailing list
|