[squeak-dev] Re: A small idea how to get closer to hardware with small efforts :)

Casey Ransberger casey.obrien.r at gmail.com
Mon Apr 5 20:15:35 UTC 2010


I would think it was great, as long as I could do something like

Smalltalk hasNativeCode

To check if there's any of it in the image, and

Smalltalk purgeNativeCode

(e.g., before a release of the image)

I definitely don't think we should ship any native code in the image in
releases...

On Mon, Apr 5, 2010 at 12:31 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 5 April 2010 15:42, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Mon, Apr 05, 2010 at 03:13:51PM +0300, Igor Stasenko wrote:
> >> Here the proof of concept implementation.
> >
> >
> >> So, here the questions, which i like to be answered:
> >> 1. reserve a numbered primitive
> >
> > Probably a named primitive in the interpreter is best, see comment in
> > John's new primitiveMicrosecondClock. I don't think that there is any
> > performance implication once the primitive name has been resolved once.
> >
> this is true, but numbered primitive could be inlined into an interpret()
> loop.
> Then this will make some difference :)
>
> >> 2. discuss the calling convention
> >> 3. add a 'platform id' code to VMMaker, and let language side know ,
> >> on which platform id VM currently runs on (through additional
> >> primitive)
> >
> > I'm not sure how to handle #3, but there are a lot of different CPUs
> > and operating systems out there, not to mention all the different modes
> > of say an Intel CPU. So it may not be trivial to answer the question
> > "can this snippet of compiled code be executed in my current runtime
> > environment".
> >
> Well, a 2 bytes for code gives us 65536 variants. If this is not
> enough, we could use 32 bits for platform id code.
> Also, i thinking , maybe we could use masks for platform id,
> so, then one could generate/use the same native code for multiple
> kinds of OS-es.
> But then , a number of variants will be much more limited, because
> platform id will be treated as a bit field, instead of integer value.
>
> > Dave
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100405/aeee1b09/attachment.htm


More information about the Squeak-dev mailing list