[Vm-dev] re: Parsing Pharo syntax to C/C++

Ronie Salgado roniesalg at gmail.com
Mon Sep 15 21:37:08 UTC 2014


I am segmenting this mail in several sections.

- On Lowcode and Cog

I have been working in the last week with the Cog VM, implementing the
Lowcode instructions in Cog.

Lowcode is currently a spec of new bytecode instructions. These
instructions can be used for:
- Implementing a C like language compiler.
- Making FFI calls

I am implementing these instructions using a feature of the new bytecode
set for SistaV1, which is called "inline primitives". Because of this,
these new instructions can be mixed freely with the standard VM bytecode
set. This also allows the Sista adaptive optimizer to inline FFI calls.

These instructions provides features for:
- Int32 and Int64 integer arithmetic without type checking.
- Pointers, with arithmetics.
- Memory access and memory manipulation.
- Single and double precision floating point arithmetics.
- Conversion between primitive types.
- Boxing and unboxing of primitive types.
- Unchecked comparisons.
- Native function call. Direct and indirect calls.
- The atomic operation compare and swap.
- Object pin/unpin (requires Spur).
- VM releasing and grabbing for threaded ffi.

Current I have implemented the following backends:
- A C interpreter plugin.
- A LLVM based backend.

Currently I am working in getting this working using the Cog code
generator. So far I am already generating code for
int32/pointer/float32/float64. I am starting to generate C functions calls
and object boxing/unboxing.

During this work I learned a lot about Cog. Specially that Cog is missing a
better Slang generator, that allows to force better inlining and more code
reviews. There is a lot of code duplication in Cog, that can be attributed
to limitations of Slang. In my opinion, if we could use Slang not only for
building the VM we should end with a better code generator. In addition we,
need more people working in Cog. We need people that performs code reviews
and documentation of Cog.

After these weeks, I learned that working in Cogit it is not that hard. Our
biggest problem is lack of documentation. Our second problem could be the
lack of documentation about Slang.

- Smalltalk -> LLVM ?

As for having a Smalltalk -> LLVM code generator. The truth is that we will
not gain anything. LLVM is a C compiler, which is designed to optimize
things such as loops with lot of arithmetics. It is designed to optimize
large sections of code. In Smalltalk, most of our code is composed mostly
of message sends. LLVM cannot optimize a message send.

To optimize a message send, you have to determine which is the method that
is going to respond to the message. Then you have to inline the method. And
then you can start performing the actual optimizations, such as constant
folding, common subexpressions, dead branch elimination, loop unrolling,
and a long etc.

Because we don't have information in the actual language (e.g. static types
a la C/C++/Java/C#) that tells us what is going to be the actual method
invoked by a message send, we have the following alternatives to determine
- Don't optimize anything.
- Perform a costly static global analysis of the whole program.
- Measure in runtime and hope for the best.
- Extend the language.

In other words, our best bet is in the work of Clément in Sista. The only
problem with this bet are real time applications.

Real time applications requires an upper bound guarantee in their response
time. In some cases, the lack of this guarantee can be just an annoyance,
as happens in video games. In some mission critical applications the
results can not be good, if this time constraint is not met. An example of
a mission critical system could the flight controls of an airplane, or the
cooling system of a nuclear reactor.

For these application, it is not possible to rely in an adaptive optimizer
that can be triggered sometimes. In these application you have to either:
- Extend the language to hand optimize some performance critical sections
of code.
- Use another language to optimize these critical section.
- Use another language for the whole project.

And of course, you have to perform lot of profiling.


2014-09-15 16:38 GMT-03:00 Craig Latta <craig at netjam.org>:

>      Hear hear!
> -C
> [1] http://tinyurl.com/m66fx8y (original message)
> --
> Craig Latta
> netjam.org
> +31 6 2757 7177 (SMS ok)
> + 1 415 287 3547 (no SMS)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140915/5ceb3bcb/attachment.htm

More information about the Vm-dev mailing list