docstring patches for RB*, STCompiler optimizing?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

docstring patches for RB*, STCompiler optimizing?

S11001001
On the compiler/ code:

Would you accept patches (no commitments here, but) that add
docstrings to the public interface of the Refactory parsing and
scanning classes?

Does STCompiler currently perform the optimizations performed by the
primitive compiler accessible by Behavior>>#compileString:,
Stream>>#fileIn etc.?  I cannot find any code that would suggest it
would, but I am perhaps overlooking something.

--
Stephen Compall
http://scompall.nocandysw.com/blog


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: docstring patches for RB*, STCompiler optimizing?

Paolo Bonzini
Stephen Compall wrote:

> On the compiler/ code:
>
> Would you accept patches (no commitments here, but) that add
> docstrings to the public interface of the Refactory parsing and
> scanning classes?
>
> Does STCompiler currently perform the optimizations performed by the
> primitive compiler accessible by Behavior>>#compileString:,
> Stream>>#fileIn etc.?  I cannot find any code that would suggest it
> would, but I am perhaps overlooking something.
>  
If you refer to peephole optimizations and combining multiple bytecodes
in one, that 's done automatically when you create a CompiledMethod.  
Methods such as #compileWhileLoop: take care of optimizing #whileTrue:
etc.  The only missing optimization is the inlined version of #to:do:
and #to:by:do:.

Paolo



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk