VM improvement: speeding up failing calls of functions in missing modules

Stephan Rudlof sr at evolgo.de
Mon Feb 14 01:47:13 UTC 2000


Do you think there are only advantages to the current InterpreterPlugin
approach, or are there any drawbacks?

Do you think the RTOSmalltalk codegenerator could replace the Squeak
CCodeGenerator (followed by a C compiler) in the near future?

Stephan


Tim Rowledge wrote:
> 
> Stephan Rudlof wrote:
> 
> > If I understand you correctly the RTOSmalltalk codegenerator compiles
> > directly from ST to Assembler without intermediate C code. This is
> > interesting, but leads to some questions:
> >
> > How difficult is it to call the OS by ANSI-C functions?
> Not at all - you need to make the last stage object code generator
> understand the OS calling conventions. It would be very like the glue
> code that Ian's jitter uses for the same purpose
> 
> > How difficult is it to ensure compatibility between different platforms?
> Not sure. The design was intended to be quite flexible and have
> pluggable back ends for different CPUs. It builds a parse tree and then
> generates code from that; curently I think C, ARM assembler source or
> ARM object code directly to an object file or even directly into memory.
> >
> > What about the performance of the generated code compared with
> > ST->C->Assembler generation by Squeak C codegenerator followed by gcc?
> In the only case I can remember, the full VM generated by the
> PurdyTranslator was something like 10% faster than the CCodeGenerator->C
> VM.
> >
> > Last but not least: What about license issues?
> Craig & I were given permission to put it all under the Squeak license.
> 
> tim

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3





More information about the Squeak-dev mailing list