[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349
siguctua at gmail.com
Thu May 7 04:35:22 UTC 2009
2009/5/7 David T. Lewis <lewis at mail.msen.com>:
> On Wed, May 06, 2009 at 08:28:13AM -0700, Andreas Raab wrote:
>> One thing we could do is for the next generation of VMs which have a new
>> image format won't be referred to as Squeak 3x etc. to up the
>> interpreter proxy major number and use only that mechanism. Thoughts?
> I don't have a clear idea of what the roadmap to next generation VM's
> looks like. We have a lot of interesting projects and new ideas (Hydra,
> iPhone, Cog, Exupery, Croquet, ...).
> I have a general sense that it is the responsibility of the image to
> identify its image format (hence what it requires of a VM) by means of
> an imageFormatVersionNumber known to the image and saved in the file
> header when saving the image. And it is the responsibility of a VM to
> know its capabilities in order to determine if it can interpret an image
> of some declared imageFormatVersionNumber.
> My guess would be that yes, we will soon be due for a new interpreter proxy
> major number, but no that mechanism is not sufficient to identify the next
> generation VM(s). Specifically, knowing the major/minor interpreter proxy
> numbers will not tell you if a VM has the necessary capabilities to support
> the requirements of an image with a given imageFormatVersionNumber.
Right it doesn't. The interpreterProxy version numbers could only
serve for indication, what version of external API is supported by VM
, or not.
But in Hydra, i eliminated that too.
Interpreterproxy structure v.2.1 contains only 3 function pointers:
* The rest of functions can be obtained by plugin by calling a
* The need in defining additional functions in this struct is gone forever
void * (*getVMFunctionPointerBySelector)(char * selector);
as you see, in case of Hydra, going past v.2.1. is quite pointless. :)
Igor Stasenko AKA sig.
More information about the Vm-dev