Interpreter Plugins
jecel at lsi.usp.br
jecel at lsi.usp.br
Sat Apr 11 03:07:19 UTC 1998
My idea for a more modular primitive system is that we should pick
a more object-oriented style and have primitive *objects* instead
of primitive *methods*. These objects would be well known (I
have made their names globals in this example) and would be
invoked using the standard send bytecodes, like this:
ArithmeticUnit add: 12 with: 21
Here are some of the primitive objects that will be needed:
ArithmeticUnit - we met already
LogicUnit - shifts and general bitwise stuff
FloatingPointUnit - for obvious things
Memory - used by basicNew and friends
BitBlitter - in some cases implemented in hardware
Os - files and things
Mac - unique Mac things
Win32 - the little shop of horrors
It should be easy to add new primitive objects with time (a MMX object
would be
popular now), eventually even dynamically. Note that
existing code would not have to be rewritten if the compiler
generated the same bytecodes for this:
+ aNumber
"Primitive. Add the receiver to the argument and answer with the
result
if it is a SmallInteger. Fail if the argument or the result is
not a
SmallInteger Essential No Lookup. See Object documentation
whatIsAPrimitive."
<primitive 1>
^super + aNumber
and this:
+ aNumber
"Primitive. Add the receiver to the argument and answer with the
result
if it is a SmallInteger. Fail if the argument or the result is
not a
SmallInteger Essential No Lookup. See Object documentation
whatIsAPrimitive."
^ArithmeticUnit add: self with: aNumber
ifFail: [^super + aNumber]
or (if we had ANSI exceptions) this would be even better:
+ aNumber
"Primitive. Add the receiver to the argument and answer with the
result
if it is a SmallInteger. Fail if the argument or the result is
not a
SmallInteger Essential No Lookup. See Object documentation
whatIsAPrimitive."
[^ArithmeticUnit add: self with: aNumber] on: BadArgumentType,
OverFlow do: [^super + aNumber]
Actually, in this last case it would be better to rewrite this to
handle the two exceptions separately.
In itself, this idea is pretty stupid. But if the image were modularized
so that objects could be linked in on the fly and we had the ability to
store native machine code inside these image "parcels" (which would come
in handy if there were a Squeak native compiler) then primitive objects
could be loaded dynamically very easily. And this would be done in a
Squeak way, not depending on platform specific DLLs and stuff.
-- Jecel Mattos de Assumpcao Jr -- mailto: jecel at lsi.usp.br
http://www.lsi.usp.br/~jecel/merlin.html
More information about the Squeak-dev
mailing list
|