[Vm-dev] Putting internal and external generated plugins in a common directory (was: VMMaker-oscog issues on RISC OS)

David T. Lewis lewis at mail.msen.com
Sun Apr 14 13:00:24 UTC 2013


Hi Eliot,

Sorry I missed this email, I did not mean to ignore you.

Yes I'll look into this, thanks for the explanation.

Dave

On Wed, Apr 10, 2013 at 02:09:34PM -0700, Eliot Miranda wrote:
>  
> David,
> 
>     when you make this change (if you haven't already) you might also
> integrate the Cog-style plugin glue, e.g. instead of using
> interpreterProxy->foo the generator always uses foo and either links
> directly to foo or keeps it's own local function pointer to foo which is
> initialized in setInterpreter:.  It's faster for internal plugins and a
> little faster for external plugins.  ANSI C removed the need for a
> syntactic difference between a direct function call and a call through a
> function pointer hence...
> 
> towards the start of the file you see e.g.
> 
> #if !defined(SQUEAK_BUILTIN_PLUGIN)
> static sqInt (*byteSizeOf)(sqInt oop);
> ...
> static sqInt (*storeIntegerofObjectwithValue)(sqInt index, sqInt oop, sqInt
> integer);
> #else /* !defined(SQUEAK_BUILTIN_PLUGIN) */
> extern sqInt byteSizeOf(sqInt oop);
> ...
> extern sqInt storeIntegerofObjectwithValue(sqInt index, sqInt oop, sqInt
> integer);
> 
> extern
> #endif
> struct VirtualMachine* interpreterProxy;
> ...
> 
> in the middle you see
>         destBitsSize = byteSizeOf(destBits);
> 
> and in setInterpreter: you see
> 
> #if !defined(SQUEAK_BUILTIN_PLUGIN)
>         byteSizeOf = interpreterProxy->byteSizeOf;
>         ...
>         storeIntegerofObjectwithValue =
> interpreterProxy->storeIntegerofObjectwithValue;
> #endif /* !defined(SQUEAK_BUILTIN_PLUGIN) */
> 
> 
> 
> On Tue, Apr 9, 2013 at 8:41 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> >
> > On Tue, Apr 09, 2013 at 03:25:52PM -0700, tim Rowledge wrote:
> > >
> > > I'm making a start at building the RISC OS StackVM and running into some
> > fun problems.
> > >
> > > First one was the code in VMMaker class>generateConfiguration that
> > builds directory names by means of evil URI related methods. Strange and
> > ugly results occur for RISC OS and tracing the code reveals many strange
> > and ugly things happening for every platform - it's just that on an OS
> > where something like / is  acceptable as a root directory it sort of ends
> > up ok. RISC OS does not do that and I'm a little surprised that it doesn't
> > cause problems on Windows too. My perfectly nice SDFS:RISCOSPi.$ root gets
> > mangled to something like /SDFS%3ARISCOSPi%2F%2a/ or whatever. A simple fix
> > for that is to change to "(FileDirectory default directoryNamed:'foo/bar')
> > fullName"
> > >
> >
> > On a related (?) note, I would like to ask if the RISC OS build could be
> > changed to allow all plugins (whether internal or external) to be generated
> > to a single source directory, i.e.
> >
> >   src/plugins/FilePlugin/
> >   src/plugins/OSProcessPlugin/
> >
> > Instead of:
> >
> >   src/vm/intplugins/FilePlugin/
> >   src/plugins/OSProcessPlugin/
> >
> > I think that we have had agreement from Eliot and Andreas (who moved to
> > this
> > structure for the Cog work) as well as Ian (who also strongly encouraged
> > it and plans to make the change in trunk). But I don't know if the
> > flattened
> > directory structure might cause problems for RISC OS.
> >
> > The VMM support is in place if we are ready to make this change:
> >
> >   VMMaker class>>useSinglePluginsDirectory:
> >
> > So, question to Tim - would it cause problems for you if we move to a
> > single
> > directory for internal and external generated plugins?
> >
> > Dave
> >
> >
> 
> 
> -- 
> best,
> Eliot



More information about the Vm-dev mailing list