[Vm-dev] Interpreter>>isContextHeader: optimization
eliot.miranda at gmail.com
Mon Feb 23 04:36:32 UTC 2009
On Sun, Feb 22, 2009 at 8:08 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> 2009/2/23 Igor Stasenko <siguctua at gmail.com>:
> > 2009/2/22 Eliot Miranda <eliot.miranda at gmail.com>:
> another idea how to make a cleaner slang code , was to introduce a
> special 'C' shared variable.
> So, then instead of writing something like:
> self ioRelinquishProcessorForMicroseconds: xxx.
> or even worse:
> self cCode:' ((sqInt (*) (sqInt, sqInt*, sqInt*, sqInt*,
> (handle, &sourceWidth, &sourceHeight, &sourceDepth,
> you merely write:
> C ioRelinquishProcessorForMicroseconds: xxx.
> C querySurfaceFn: handle with: sourceWidth cReference with:
> sourceHeight cReference ....
this is scarily similar to Alien style FFI's, e.g. Vassili's Newspeak
Windows GUI interface :)
> First , it lets a code generator know, that given message send is raw
> C function call (by taking a first keyword as a function name).
> Second, it can be simulated appropriately by a simulator, since you
> can assign an object to 'C' pool var which having best-match
> implementations for all such calls. And of course it helps greatly in
> finding errors or mistypes!
> Then patterns like 'self foo' be exclusively treated by code generator
> as method which belongs to an instance of class where method which
> containing such code residing, without any exceptions.
> So, if you write
> 'self signalSemaphore: xx' in Interpreter's method
> a code generator should lookup for #signalSemaphore: in Interpreter class.
> And if you write 'self header' in Oop class -- it will lookup
> #header method in Oop class, but nowhere else!
I also think we should do the following:
a) mangle names of selectors so each is prefixed by e.g. the capitals in the
class name, so that e.g. StackInterpreter>>popStack: gets mangled to
SI_popStack, and Cogit>>cog:selector: gets mangled to C_cogselector etc so
one can use super in Slang.
b) handle variables thusly:
Slang should provide unique names for all local variables as it creates
TMethods. These variable names can simply be integers (actually their key
is an integer and their value is their original name). Since they are all
unique there can be no clashes. Variables can safely be substituted by
other variables since when one replaces one variable with another it cannot
posibly accidentally clash with some other variable.
Later, when a TMethod is output, variables are output not as their integer
key but as their value (their original name) provided it doesn't clash. The
same variable renumbering scheme can be used to resolve clashes. i.e. the
renaming is deferred until a TMethod is output, and done once, not every
time one tries to inline a method. Renaming clashes is simple. A
dictionary maps original names to sequences of integer variable keys. The
renamed variable is the original name concatenated with the index of its
integer key in the sequence of keys for the original name.
When inlining a method into another one unifies the formals and actuals
assigning new variable numbers for all new variable bindings. That should
simplify the inline considerably because the horrible variable renaming code
will reduce to mapping old variable keys to new variable keys.
> Best regards,
> Igor Stasenko AKA sig.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev