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

tim Rowledge tim at rowledge.org
Tue Jul 1 20:21:28 UTC 2008


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; tim at rowledge.org; 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."





More information about the Squeak-dev mailing list