18 Mar

Detect Mono running in AOT mode

So, for MoonSharp (which is evolving a lot more than it was suggested by posts on this blog – heck I should write MORE), I needed to know if my library was running in FullAOT or not.

For those not knowing, AOT means “ahead of time”. Under a FullAOT execution, JITting is disabled and code is compiled “ahead of time”; this means all those scenarios which involve creating code on the fly at runtime will not work. This can be used for some optimizing scenario or for embedded systems and such, but the real use case is iOS, as apps on iOS cannot (due to licensing) create code at runtime – weird Apple rules.

Now, while an app usually knows whether it’s running on AOT or not, a class library might not now beforehand and yet that information might be useful.

For example MoonSharp userdata do a lot of reflection and back-and-forth calls between script and native code. As an optimization, it uses LambdaExpression.Compile calls to create wrappers at runtime and have performances which are orders of magnitude faster than reflection. However those calls break with an ExecutionEngineException on Mono FullAOT.

Now, here we have a little weird Mono thing which comes to help us.. don’t know if it’s a bug or intentional.

As per MSDN documentation, managed code cannot catch an ExecutionEngineException. Turns out that Mono behaves differently – at the very least regarding those EEEs which are thrown due to a JIT request in FullAOT.

Then the detection code gets simple enough:

private static void AttemptJit()
 Expression e = Expression.Constant(5, typeof(int));
 var lambda = Expression.Lambda<Func<int>>(e);

private static bool IsRunningOnAOT()
 return false;
 catch (ExecutionEngineException)
 return true;

Hope this fact that EEE can be caught is not a Mono bug (or at least, it doesn’t get fixed ;) ).

Filed under: Uncategorized

01 Oct

Moon# 0.5.0 released!

I’ve released MoonSharp 0.5.0 (Moon#) the brand new Lua interpreter written entirely in C# for the best compatibility over .NET, Mono, Unity and Xamarin versions.

Many things have changed since the plans detailed in this blog.. for the best. Check it out.

Head to http://www.moonsharp.org


Filed under: Uncategorized

20 May

Moon# is online!

Moon# has its own website on GitHub : https://github.com/xanathar/moonsharp

Also, if you want to peek at the current backlog: https://www.pivotaltracker.com/s/projects/1082626


BTW, I’m moving all my open source efforts – however weak they might be – from various sources (mainly, here or google code) to GitHub, to have everything in one place.


[This post has been edited, as originally the project was hosted on CodePlex]

13 May

MoonSharp : operator precedence and associativity revised

Quite soon, I found the Lua grammar on the ANTLR github to skip operator precedence.

The old grammar is:

    : ...
    | exp binop exp | unop exp

    : '+' | '-' | '*' | '/' | '^' | '%' | '..'
    | '<' | '<=' | '>' | '>=' | '==' | '~='
    | 'and' | 'or'

    : '-' | 'not' | '#'

Obviously, there is no trace of operator precedence. A quick check to the Lua reference  tells us the precedence and also specifies operator associativity.  So I went with this:

    : ...
    | <assoc=right> exp operatorPower exp 
    | operatorUnary exp
    | exp operatorMulDivMod exp 
    | exp operatorAddSub exp 
    | <assoc=right> exp operatorStrcat exp 
    | exp operatorComparison exp 
    | exp operatorAnd exp 
    | exp operatorOr exp 
    | ...

    : 'or';

    : 'and';

    : '<' | '>' | '<=' | '>=' | '~=' | '==';

    : '..';

    : '+' | '-';

    : '*' | '/' | '%';

    : 'not' | '#' | '-';

    : '^';

Curiously, ANTLR syntax for <assoc=right> has changed somewhere between ANTRL 4.0 and 4.2, rendering the ANLTR4 reference wrong on that aspect. The manual says to write it like

rule : exp '^'<assoc=right> exp;

while now the <assoc=right> should be applied to the ‘:’ or ‘|’ :

rule :<assoc=right> exp '^' exp;

If using the first syntax (the manual one) the build emits a warning AC0157: rule ‘exp’ contains an ‘assoc’ terminal option in an unrecognized location

References to this peculiarity: TheAntlrGuy wiki and an helpful StackOverflow post.

Filed under: MoonSharp, Programming