[squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge
I am trying to make time to post a few articles on some future  
directions I consider interesting for the core system.

First one is up at http://people.squeakfoundation.org/article/89.html 
- do please comment on the relevant page, or even here.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: New classic



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Adrian Lienhard
Hi Tim,

I agree, but I cannot follow with what you see can be done with the  
saved bits. You say "The 10 released bits can be used for a variety of  
purposes including marking immutable objects, fixed address objects,  
proxy objects etc.". However, none of those three examples seem to be  
related as you only spare bits in compiled methods, but not in the  
general object header. What have I missed?

Cheers,
Adrian



On Jun 30, 2008, at 20:34 , tim Rowledge wrote:

> I am trying to make time to post a few articles on some future  
> directions I consider interesting for the core system.
>
> First one is up at http://people.squeakfoundation.org/article/ 
> 89.html - do please comment on the relevant page, or even here.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Oxymorons: New classic
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge

On 30-Jun-08, at 11:52 AM, Adrian Lienhard wrote:

> Hi Tim,
>
> I agree, but I cannot follow with what you see can be done with the  
> saved bits. You say "The 10 released bits can be used for a variety  
> of purposes including marking immutable objects, fixed address  
> objects, proxy objects etc.". However, none of those three examples  
> seem to be related as you only spare bits in compiled methods, but  
> not in the general object header. What have I missed?

Nothing. I am an idiot. I was confusing different headers. Ignore  
everything after "variety of purposes"....


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, as the Vice Squad took his GIFS ..



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Igor Stasenko
In reply to this post by timrowledge
2008/6/30 tim Rowledge <[hidden email]>:
> I am trying to make time to post a few articles on some future directions I
> consider interesting for the core system.
>
> First one is up at http://people.squeakfoundation.org/article/89.html - do
> please comment on the relevant page, or even here.
>

This is not the only things which i don't like.
For instance look into ObjectMemory>>fetchClassOf:
it fetching class depending on object header. Either from compact
classes array (by index), or from slot, reserved for class reference.
I think eliminating compact classes would simplify the access to
object's class and free us some bits again: type mask bit (at least).

It also will make fetching a class oop faster and uniform, so there
will be no branching.
Fetching a class from Compact classes array, requires:  getting oop at
index in special objects array, and then getting oop from this object:

class := fetchPointer: ccIndex - 1 ofObject: (self fetchPointer:
CompactClasses ofObject: specialObjectsOop)

A drawback of getting rid of compact classes is additional memory cost
per each instance of classes which were compact.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge

On 30-Jun-08, at 12:15 PM, Igor Stasenko wrote:

> 2008/6/30 tim Rowledge <[hidden email]>:
>> I am trying to make time to post a few articles on some future  
>> directions I
>> consider interesting for the core system.
>>
>> First one is up at http://people.squeakfoundation.org/article/ 
>> 89.html - do
>> please comment on the relevant page, or even here.
>>
>
> This is not the only things which i don't like.
> For instance look into ObjectMemory>>fetchClassOf:
> it fetching class depending on object header. Either from compact
> classes array (by index), or from slot, reserved for class reference.
> I think eliminating compact classes would simplify the access to
> object's class and free us some bits again: type mask bit (at least).
>
> It also will make fetching a class oop faster and uniform, so there
> will be no branching.
> Fetching a class from Compact classes array, requires:  getting oop at
> index in special objects array, and then getting oop from this object:
>
> class := fetchPointer: ccIndex - 1 ofObject: (self fetchPointer:
> CompactClasses ofObject: specialObjectsOop)
>
> A drawback of getting rid of compact classes is additional memory cost
> per each instance of classes which were compact.

Good points but perhaps for another thread?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Every bug you find is the last one.



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Michael van der Gulik-2
In reply to this post by timrowledge


On Tue, Jul 1, 2008 at 6:34 AM, tim Rowledge <[hidden email]> wrote:
I am trying to make time to post a few articles on some future directions I consider interesting for the core system.

First one is up at http://people.squeakfoundation.org/article/89.html - do please comment on the relevant page, or even here.

Does every numbered prim also have a name or named equivalent?

I'll be rewriting the Kernel -* classes for the next few versions of SecureSqueak, so I could go through and replace these as I find them.

Also, if the compact classes only exist for space concerns, then as far as I'm concerned, they can go. Memory is cheap, and if you really want to save memory then write a 16-bit block-based VM (*)!

Gulik.

(*) http://gulik.pbwiki.com/Block-based+virtual+machine (disclaimer: random ideas only).

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge

On 30-Jun-08, at 6:02 PM, Michael van der Gulik wrote:

>
>
> On Tue, Jul 1, 2008 at 6:34 AM, tim Rowledge <[hidden email]> wrote:
> I am trying to make time to post a few articles on some future  
> directions I consider interesting for the core system.
>
> First one is up at http://people.squeakfoundation.org/article/ 
> 89.html - do please comment on the relevant page, or even here.
>
> Does every numbered prim also have a name or named equivalent?

It's just a prim, ie a function somewhere.

I'm proposing that we name all those prims that are currently numbered  
- primitive 1 would become "primitiveAdd" in a similar manner to say  
"primitiveDisablePowerManager".  This would allow all prims to be  
built as plugin components, thereby allowing on the fly replacement of  
those plugins (making due allowance for handling retained state etc,  
of course). (It's sometihng I've been wanting to see done since 1988;  
I had discussions with Alan Schiffman & Peter Deutsch about it way  
before I even move to ParcPlace). We would lose the primitive table,  
saving a 8 kb or so. Oh and the *really* obsoleteIndexPrimitiveTable,  
saving another 8Kb or so.

Some code gets simplified, some space is saved, some flexibility is  
added, some bits are freed up in the CM header. THe downside is  
someone has to do some work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Advanced design: Upper management doesn't understand it.



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Igor Stasenko
2008/7/1 tim Rowledge <[hidden email]>:

>
> On 30-Jun-08, at 6:02 PM, Michael van der Gulik wrote:
>
>>
>>
>> On Tue, Jul 1, 2008 at 6:34 AM, tim Rowledge <[hidden email]> wrote:
>> I am trying to make time to post a few articles on some future directions
>> I consider interesting for the core system.
>>
>> First one is up at http://people.squeakfoundation.org/article/89.html - do
>> please comment on the relevant page, or even here.
>>
>> Does every numbered prim also have a name or named equivalent?
>
> It's just a prim, ie a function somewhere.
>
> I'm proposing that we name all those prims that are currently numbered -
> primitive 1 would become "primitiveAdd" in a similar manner to say
> "primitiveDisablePowerManager".  This would allow all prims to be built as
> plugin components, thereby allowing on the fly replacement of those plugins
> (making due allowance for handling retained state etc, of course). (It's
> sometihng I've been wanting to see done since 1988; I had discussions with
> Alan Schiffman & Peter Deutsch about it way before I even move to
> ParcPlace). We would lose the primitive table, saving a 8 kb or so. Oh and
> the *really* obsoleteIndexPrimitiveTable, saving another 8Kb or so.
>

err... a primitive names, will add about same or even more space (in
fact it will make VM and image both little bigger ). So its unlikely
that new VM will have less memory footprint, but more likely that it
would be simplified a bit comparing to old ways how it works with
primitives.

> Some code gets simplified, some space is saved, some flexibility is added,
> some bits are freed up in the CM header. THe downside is someone has to do
> some work.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Advanced design: Upper management doesn't understand it.
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge

On 30-Jun-08, at 8:27 PM, Igor Stasenko wrote:
>>
>
> err... a primitive names, will add about same or even more space (in
> fact it will make VM and image both little bigger ). So its unlikely
> that new VM will have less memory footprint, but more likely that it
> would be simplified a bit comparing to old ways how it works with
> primitives.


Well, about 200 methods would get an extra literal (to put the name  
in) and about 200 symbols would be interned (for the names), so yes it  
would cost a little image space there. The VM size would be affected  
by what the C compiler did; sometimes simplifying code a little makes  
for a significant size change as CSE etc comes into play. The plugins  
are obviously different in structure to plain functions in an  
executable - no idea whether they are consistently bigger or smaller.  
Probably depends a bit on the OS? Of course, your image may well not  
use all the ex-numbered prims and thus may not load some of the new  
plugins. If the VM is properly (in my opinion) built to have all  
plugins external then the actual working size might be a fair bit  
smaller.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A)bort, R)etry, I)gnore, V)alium?



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Igor Stasenko
2008/7/1 tim Rowledge <[hidden email]>:

>
> On 30-Jun-08, at 8:27 PM, Igor Stasenko wrote:
>>>
>>
>> err... a primitive names, will add about same or even more space (in
>> fact it will make VM and image both little bigger ). So its unlikely
>> that new VM will have less memory footprint, but more likely that it
>> would be simplified a bit comparing to old ways how it works with
>> primitives.
>
>
> Well, about 200 methods would get an extra literal (to put the name in) and
> about 200 symbols would be interned (for the names), so yes it would cost a
> little image space there. The VM size would be affected by what the C
> compiler did; sometimes simplifying code a little makes for a significant
> size change as CSE etc comes into play.

You forgot , that primitive names are appear in VM as literals too.
Just to be able to lookup for a primitive function by its name instead
of index.
But forget it.. Size is really not an issue, if we can focus on making
VM more clean without obsolete stuff.
The worst thing is image compatibility: you can't run images which
using numbered primitives anymore. Or again, you would need to keep an
index->name translation table for backward compatibility :)

> The plugins are obviously different
> in structure to plain functions in an executable - no idea whether they are
> consistently bigger or smaller. Probably depends a bit on the OS? Of course,
> your image may well not use all the ex-numbered prims and thus may not load
> some of the new plugins. If the VM is properly (in my opinion) built to have
> all plugins external then the actual working size might be a fair bit
> smaller.
>

Why external?
If you declare a primitive like:

<primitive: 'foo' module: ''>

it will look for a primitive in VM itself. No need in putting things
in standalone plugin. There are many primitives which assume that they
are in VM code, and also many others that assume that they built as
internal only. There will be a lot of C discrepancy if you try to
compile some plugins/primitives either as standalone plugin or
external plugin :)


> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> A)bort, R)etry, I)gnore, V)alium?
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

stephane ducasse
In reply to this post by timrowledge
I thought I was the only one to have watched the prisoner :)
I'm not a compiler - I'm a free programmer (Context was C++)

Stef

On Jun 30, 2008, at 8:34 PM, tim Rowledge wrote:

> I am trying to make time to post a few articles on some future  
> directions I consider interesting for the core system.
>
> First one is up at http://people.squeakfoundation.org/article/ 
> 89.html - do please comment on the relevant page, or even here.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Oxymorons: New classic
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

stephane ducasse
In reply to this post by timrowledge
>>
>
> It's just a prim, ie a function somewhere.
>
> I'm proposing that we name all those prims that are currently  
> numbered - primitive 1 would become "primitiveAdd" in a similar  
> manner to say "primitiveDisablePowerManager".  This would allow all  
> prims to be built as plugin components, thereby allowing on the fly  
> replacement of those plugins (making due allowance for handling  
> retained state etc, of course). (It's sometihng I've been wanting to  
> see done since 1988; I had discussions with Alan Schiffman & Peter  
> Deutsch about it way before I even move to ParcPlace). We would lose  
> the primitive table, saving a 8 kb or so. Oh and the *really*  
> obsoleteIndexPrimitiveTable, saving another 8Kb or so.

So do it.

Stef

>
>
> Some code gets simplified, some space is saved, some flexibility is  
> added, some bits are freed up in the CM header. THe downside is  
> someone has to do some work.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Advanced design: Upper management doesn't understand it.
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

stephane ducasse
In reply to this post by Igor Stasenko
>>
>
> You forgot , that primitive names are appear in VM as literals too.
> Just to be able to lookup for a primitive function by its name instead
> of index.
> But forget it.. Size is really not an issue, if we can focus on making
> VM more clean without obsolete stuff.

please this is important to move on and remove dust.

> The worst thing is image compatibility: you can't run images which
> using numbered primitives anymore. Or again, you would need to keep an
> index->name translation table for backward compatibility :)

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Eliot Miranda-2
In reply to this post by stephane ducasse
Sorry to reply to Steph's reply to Tim's original.  I didn't get the original (because I had Anouncements checked by mistake inj my squeak-dev mail settings).  I'm really replying to Tim's message here.

On Tue, Jul 1, 2008 at 9:27 AM, stephane ducasse <[hidden email]> wrote:


It's just a prim, ie a function somewhere.

I'm proposing that we name all those prims that are currently numbered - primitive 1 would become "primitiveAdd" in a similar manner to say "primitiveDisablePowerManager".  This would allow all prims to be built as plugin components, thereby allowing on the fly replacement of those plugins (making due allowance for handling retained state etc, of course). (It's sometihng I've been wanting to see done since 1988; I had discussions with Alan Schiffman & Peter Deutsch about it way before I even move to ParcPlace). We would lose the primitive table, saving a 8 kb or so. Oh and the *really* obsoleteIndexPrimitiveTable, saving another 8Kb or so.

Gettng rid of both obsolete tables is a really good thing (and I've already done it).

Getting rid of indexed primitives for the core does not save anything.  There still has to be a table somewhere that maps the primitive name to the primitive function.  All you do is replace a table mapping indices to functions with one mapping strings to functions. You can't reply on the OS to do the lookup because you won't be able to strip VM executables if you do and that really costs space.

But more importantly I think its pointless.  The bulk of primitives in the system are named, and they're in plugins and that all works fine, even though lookup is a little involved and slow.  But I see nothing wrong with the core language primitives being indexed.  They are pretty well fixed with unchanged semantics and unchanged references in the system (e.g. SmallInteger>>#+ is where you find <primitive: 1> and has always been where you find it).  The table is quick to index and simple.

That said I think its worth cutting down the set of indexed primitives to a minimum:

Object primtives (class, ==, ~~, become: 
Control primitives (blocks, perform, executeMethod, findUnwind, terminateTo)
Process primitives (signal, wait, resume, suspend, yield)
Accessing primitives (at:, at:put:, size, instVarAt:, instVarAt:put:)
Instantiation primitives (new, new:, shallowCopy)
SmallInteger primitives, Float primitives, LargeInteger primitives (although LargeInteger prims are arguable)
Mirror primitives (_object:instVarAt:, _objectClass: etc which the executuon simulation machinery needs to use instead of instVarAt: & class etc to be able to simulate proxy execution correctly)

Primitives that absolutely should not be indexed primitives include things like
(90 primitiveMousePoint)
(91 primitiveTestDisplayDepth) "Blue Book: primitiveCursorLocPut"
(92 primitiveSetDisplayMode) "Blue Book: primitiveCursorLink"
(93 primitiveInputSemaphore)
(94 primitiveGetNextEvent) "Blue Book: primitiveSampleInterval"
(95 primitiveInputWord)
(98 primitiveStoreImageSegment)
(99 primitiveLoadImageSegment)
(101 primitiveBeCursor)
(102 primitiveBeDisplay)
(103 primitiveScanCharacters)
(105 primitiveStringReplace)
(106 primitiveScreenSize)
(107 primitiveMouseButtons)
(108 primitiveKbdNext)
(109 primitiveKbdPeek)
(126 primitiveDeferDisplayUpdates)
(127 primitiveShowDisplayRect)
(133 primitiveSetInterruptKey)
(134 primitiveInterruptSemaphore)
(140 primitiveBeep)
(141 primitiveClipboardText)
(142 primitiveVMPath)
(231 primitiveForceDisplayUpdate)
(232 primitiveFormPrint)
(233 primitiveSetFullScreen)

as these are to do with the broader context, not the core execution engine.

I would go further and rip out support for named primitives from the VM and put it up in the image where it belongs.  I would build the machinery for looking up named primitives in the image and have a primitive that allowed one to slam a function address into a method.

For me the VM should include an execution engine, a small and fast FFI and nothing else.  One needs some VM support to bootstrap the FFI.  i.e. the VM must include a primitive to load a platform library and another to lookup a name in it.  But other than that everything can be up in the image.  When one invokes a method with a primitive that has not been bound to a function yet then the primitive fails and the image's primitive failure code looks up the primitive's name and retries the call or reports an error if the library or name can't be found.

The indexed primitive table should then come down to under 256 entries, (512 if you include primitiveLoadInstVar) leaving those bits to be used for more useful things like a larger literal range.

But that's just my opinion.




So do it.

Stef


Some code gets simplified, some space is saved, some flexibility is added, some bits are freed up in the CM header. THe downside is someone has to do some work.

:)  back to my day job...

 


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Advanced design: Upper management doesn't understand it.









Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Bert Freudenberg
Am 01.07.2008 um 21:25 schrieb Eliot Miranda:

> I would go further and rip out support for named primitives from the  
> VM and put it up in the image where it belongs.  I would build the  
> machinery for looking up named primitives in the image and have a  
> primitive that allowed one to slam a function address into a method.
>
> For me the VM should include an execution engine, a small and fast  
> FFI and nothing else.  One needs some VM support to bootstrap the  
> FFI.  i.e. the VM must include a primitive to load a platform  
> library and another to lookup a name in it.  But other than that  
> everything can be up in the image.  When one invokes a method with a  
> primitive that has not been bound to a function yet then the  
> primitive fails and the image's primitive failure code looks up the  
> primitive's name and retries the call or reports an error if the  
> library or name can't be found.

Well, until now FFI was intentionally optional. Making it mandatory  
would immensely widen the Smalltalk-System interface, in fact, there  
would be no clearly defined interface anymore. Until now, Squeak is a  
relatively safe place, bad crashes are rare etc. Whenever you deal  
with FFI the next crash is only minutes away. Also, you could expect  
that the image would soon fill up with lots of platform-specific code.  
But more importantly, it would make sand-boxing impossible, as any  
code in the image can do anything to your machine if it has access to  
FFI.

So it would simplify the VM at the expense of added complexity in the  
image. Which may of course fit the bill for Croquet which already  
relies on FFI, and except for Etoys nobody really uses the sand boxing  
anyway.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Eliot Miranda-2


On Tue, Jul 1, 2008 at 12:49 PM, Bert Freudenberg <[hidden email]> wrote:
Am 01.07.2008 um 21:25 schrieb Eliot Miranda:

I would go further and rip out support for named primitives from the VM and put it up in the image where it belongs.  I would build the machinery for looking up named primitives in the image and have a primitive that allowed one to slam a function address into a method.

For me the VM should include an execution engine, a small and fast FFI and nothing else.  One needs some VM support to bootstrap the FFI.  i.e. the VM must include a primitive to load a platform library and another to lookup a name in it.  But other than that everything can be up in the image.  When one invokes a method with a primitive that has not been bound to a function yet then the primitive fails and the image's primitive failure code looks up the primitive's name and retries the call or reports an error if the library or name can't be found.

Well, until now FFI was intentionally optional. Making it mandatory would immensely widen the Smalltalk-System interface, in fact, there would be no clearly defined interface anymore. Until now, Squeak is a relatively safe place, bad crashes are rare etc. Whenever you deal with FFI the next crash is only minutes away. Also, you could expect that the image would soon fill up with lots of platform-specific code. But more importantly, it would make sand-boxing impossible, as any code in the image can do anything to your machine if it has access to FFI.

So it would simplify the VM at the expense of added complexity in the image. Which may of course fit the bill for Croquet which already relies on FFI, and except for Etoys nobody really uses the sand boxing anyway.

One doesn't have to *use* the FFI.   If the FFI isn't exposed via a primitive then no FFI.  One can still have named primitives supported by the image and not by the VM and not use the FFI.  To call a named primitive in a primitive plugin the following sequence occurs:

the method containing a named primitive spec is activated and the primitive call fails because its function pointer is null.
the failure code extracts the plugin name and invokes a primitive to load the plugin library
the failure code extracts the primitive name and uses the lookup primitive to find the function in the loaded plugin library
the failure code uses a primitive to slam the function pointer into the method
the failure code uses the executeMethodWithArgs primitive to retry the bound named primitive method

So the FFI is an optional extra.  One needs four primitives, load library, lookup name in library, insert primitive function pointer. and executemethodWithArgs (thanks Tim!).  Slamming the function into the method could also be done using, say, objectAt:.

So one can still have a nice small safe VM and have no direct support for named primitives in the VM.
 


- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge
In reply to this post by Eliot Miranda-2

On 1-Jul-08, at 12:25 PM, Eliot Miranda wrote:
> [snip]
>
> Gettng rid of both obsolete tables is a really good thing (and I've  
> already done it).
Good
>
> Getting rid of indexed primitives for the core does not save  
> anything.  There still has to be a table somewhere that maps the  
> primitive name to the primitive function.  All you do is replace a  
> table mapping indices to functions with one mapping strings to  
> functions. You can't reply on the OS to do the lookup because you  
> won't be able to strip VM executables if you do and that really  
> costs space.
Sure; there's always got to be some way of looking up things. It will  
always take some space and time. But surely trading space/time for  
more flexible and smarter is what Smalltalk is all about?

>
> But more importantly I think its pointless.  The bulk of primitives  
> in the system are named, and they're in plugins and that all works  
> fine, even though lookup is a little involved and slow.  But I see  
> nothing wrong with the core language primitives being indexed.  They  
> are pretty well fixed with unchanged semantics and unchanged  
> references in the system (e.g. SmallInteger>>#+ is where you find  
> <primitive: 1> and has always been where you find it).  The table is  
> quick to index and simple.
The downside in my opinion is that you have an early bound lookup that  
also requires a different mechanism to support it. Named prims allow  
for a later binding, replacement dynamically, and removes one of the  
lookup mechanisms. As an example, we could put the at: & at:put: prims  
into a plugin; then have one version that uses a cache of recently  
at:'d objects and one that doesn't. It would be possible to swap  
between them at runtime. Why? No idea, it's just an example, damnit!

[snip]

>
> Primitives that absolutely should not be indexed primitives include  
> things like
> (90 primitiveMousePoint)
> (91 primitiveTestDisplayDepth) "Blue Book: primitiveCursorLocPut"
> (92 primitiveSetDisplayMode) "Blue Book: primitiveCursorLink"
> (93 primitiveInputSemaphore)
> (94 primitiveGetNextEvent) "Blue Book: primitiveSampleInterval"
> (95 primitiveInputWord)
> (98 primitiveStoreImageSegment)
> (99 primitiveLoadImageSegment)
> (101 primitiveBeCursor)
> (102 primitiveBeDisplay)
> (103 primitiveScanCharacters)
> (105 primitiveStringReplace)
> (106 primitiveScreenSize)
> (107 primitiveMouseButtons)
> (108 primitiveKbdNext)
> (109 primitiveKbdPeek)
> (126 primitiveDeferDisplayUpdates)
> (127 primitiveShowDisplayRect)
> (133 primitiveSetInterruptKey)
> (134 primitiveInterruptSemaphore)
> (140 primitiveBeep)
> (141 primitiveClipboardText)
> (142 primitiveVMPath)
> (231 primitiveForceDisplayUpdate)
> (232 primitiveFormPrint)
> (233 primitiveSetFullScreen)
>
> as these are to do with the broader context, not the core execution  
> engine.
I'd certainly agree with the principle.

>
> I would go further and rip out support for named primitives from the  
> VM and put it up in the image where it belongs.  I would build the  
> machinery for looking up named primitives in the image and have a  
> primitive that allowed one to slam a function address into a method.
>
> For me the VM should include an execution engine, a small and fast  
> FFI and nothing else.

An interesting idea in a completely different direction. I like a lot  
about it, though I still think that the core prims ought to be named  
and live in plugins, including the FFI. Obviously there is a gnarly  
bit where you can't load the FFI plugin if you rely on FFI to do the  
plugin loading, but what the hell, there's a bunch of us and we're  
smart[1].

A system built as you describe would be extremely nice. No argument  
there. Nonetheless I think that late-bound and rebindable prims along  
with replaceable VM internals would also have some interesting value.  
I doubt it's impossible to do both.

tim
[1] sideways reference to a .sigline "The theorists tell us that this  
isimpossible, but what hell, there are three of us and we're smart"
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Watchmakers does it take to change a lightbulb?" "One.  
Four to change the lightbulb and seventeen to convert the old bulb  
into an escape capsule for all the others."



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

timrowledge
In reply to this post by Eliot Miranda-2

On 1-Jul-08, at 1:20 PM, Eliot Miranda wrote:

>
> One doesn't have to *use* the FFI.   If the FFI isn't exposed via a  
> primitive then no FFI.  One can still have named primitives  
> supported by the image and not by the VM and not use the FFI.  To  
> call a named primitive in a primitive plugin the following sequence  
> occurs:
>
> the method containing a named primitive spec is activated and the  
> primitive call fails because its function pointer is null.
> the failure code extracts the plugin name and invokes a primitive to  
> load the plugin library
> the failure code extracts the primitive name and uses the lookup  
> primitive to find the function in the loaded plugin library
> the failure code uses a primitive to slam the function pointer into  
> the method
> the failure code uses the executeMethodWithArgs primitive to retry  
> the bound named primitive method
>
> So the FFI is an optional extra.  One needs four primitives, load  
> library, lookup name in library, insert primitive function pointer.  
> and executemethodWithArgs (thanks Tim!).  Slamming the function into  
> the method could also be done using, say, objectAt:.
>
> So one can still have a nice small safe VM and have no direct  
> support for named primitives in the VM.
>


Leaving aside my like of all-named-prims, I *like* this enhancement to  
the support for named prims.

It would slightly complicate the post-prim-call code in each method  
because you would need to handle the failed-to-find-prim case as well  
as all the prim-failed cases. It would be helped by an old idea that  
I'm pretty sure eliot has plans for anyway (as indeed I have written  
about a few times) to add primitive error return values. For those  
that haven't heard of them, this is just a way of having the first  
temp in a context involved in a prim call be a slot for a return value  
from the prim if any error occurs. This means you can actually know  
wtf went wrong instead of guessing - "ooh, was the first arg a  
SmallInteger? Um, if not, was it a Float that might round nicley? Err,  
was the second arg a ByteArray with the first byte = 255?" etc.  
Instead you get "ah, errorValue was 1, so we have to explode the  
reactor core in order to stop the Dreen from eating the children".  
Much nicer.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
CITOKATE - Criticism is the Only Known Antidote to Error



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Eliot Miranda-2
In reply to this post by timrowledge


On Tue, Jul 1, 2008 at 1:21 PM, tim Rowledge <[hidden email]> wrote:

On 1-Jul-08, at 12:25 PM, Eliot Miranda wrote:
[snip]


Gettng rid of both obsolete tables is a really good thing (and I've already done it).
Good


Getting rid of indexed primitives for the core does not save anything.  There still has to be a table somewhere that maps the primitive name to the primitive function.  All you do is replace a table mapping indices to functions with one mapping strings to functions. You can't reply on the OS to do the lookup because you won't be able to strip VM executables if you do and that really costs space.
Sure; there's always got to be some way of looking up things. It will always take some space and time. But surely trading space/time for more flexible and smarter is what Smalltalk is all about?

Smalltalk is about a lot of things.  One is minimality (everything's an object).  Use Occam's razor.  Named primitives for the core prims is a flourish one doesn't need.  As my first wife was fond of saying "Don't sweat the petty stuff.  Pet the sweaty stuff."

More seriously, the VM should be as minimal as possible and I've shown (I think) that e.g. named primitive support can be lifted into the image and be much more flexible and extensible there.  But the same can't be done with the core primitives.  We can't have a circularity were the system needs to use core primitives to bind core primitives.   So (I tell myself) keep it simple stupid.  Just use an index.



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Eliot Miranda-2
In reply to this post by timrowledge


On Tue, Jul 1, 2008 at 1:34 PM, tim Rowledge <[hidden email]> wrote:

On 1-Jul-08, at 1:20 PM, Eliot Miranda wrote:

One doesn't have to *use* the FFI.   If the FFI isn't exposed via a primitive then no FFI.  One can still have named primitives supported by the image and not by the VM and not use the FFI.  To call a named primitive in a primitive plugin the following sequence occurs:

the method containing a named primitive spec is activated and the primitive call fails because its function pointer is null.
the failure code extracts the plugin name and invokes a primitive to load the plugin library
the failure code extracts the primitive name and uses the lookup primitive to find the function in the loaded plugin library
the failure code uses a primitive to slam the function pointer into the method
the failure code uses the executeMethodWithArgs primitive to retry the bound named primitive method

So the FFI is an optional extra.  One needs four primitives, load library, lookup name in library, insert primitive function pointer. and executemethodWithArgs (thanks Tim!).  Slamming the function into the method could also be done using, say, objectAt:.

So one can still have a nice small safe VM and have no direct support for named primitives in the VM.



Leaving aside my like of all-named-prims, I *like* this enhancement to the support for named prims.

It would slightly complicate the post-prim-call code in each method because you would need to handle the failed-to-find-prim case as well as all the prim-failed cases. It would be helped by an old idea that I'm pretty sure eliot has plans for anyway (as indeed I have written about a few times) to add primitive error return values. For those that haven't heard of them, this is just a way of having the first temp in a context involved in a prim call be a slot for a return value from the prim if any error occurs. This means you can actually know wtf went wrong instead of guessing - "ooh, was the first arg a SmallInteger? Um, if not, was it a Float that might round nicley? Err, was the second arg a ByteArray with the first byte = 255?" etc. Instead you get "ah, errorValue was 1, so we have to explode the reactor core in order to stop the Dreen from eating the children". Much nicer.

I did primitive error codes at Cadence and they'll very probably b making it into Cog real soon now.  They're simpler than VisualWorks', being only symbols.  So extracting more information, such as a related error code requires a subsequent call.  But I think the work I'm doing right now on eliminating pushRemappableOop:/popRemappableOop will enable me to have a structured object with a name and parameters, which is more generally useful.

A nice thing is that the code is forwards and backewards compatible.  One can use the VM to run older images.  One can run images that contain the primitive error code on older VMs, where one simply gets a nil error code on primitive failure.



123