montyscoconut/moco

The Monty to LLVM compiler

Moco

moco is a Monty to LLVM compiler built using Java, ANTLR4 and LLVM.

Please read the language specification for details on the Monty programming language and refer to the feature overview for a list of implemented features.

Installing Dependencies

Linux (Ubuntu)

Install LLVM and a JRE 7.

sudo apt-get install llvm
sudo apt-get install default-jre

If you want to build moco yourself you'll need to install the following dependencies and a JDK 7.

sudo apt-get install git
sudo apt-get install maven
sudo apt-get install default-jdk

You can also install Graphviz to generate class diagrams. This is optional.

sudo apt-get install graphviz

Mac OS X

Note: Please make sure you have homebrew and a JRE 7 installed.

Install LLVM using homebrew:

brew install llvm

If you want to build moco yourself you'll need to install the following dependencies and a JDK 7.

brew install git
brew install maven

Please make sure to set the JAVA_HOME environment variable for maven.

export JAVA_HOME=$(/usr/libexec/java_home)

You can also install Graphviz to generate class diagrams. This is optional.

brew install graphviz

Windows

To use LLVM you'll need to download and install the following executables. In addition you'll need to download and extract the llvm-3.4-tools-windows.7z archive into the bin\ directory of your LLVM installation. To run the executable .jar file you'll also need a JRE 7.

• http://www.microsoft.com/de-DE/download/details.aspx?id=40784 (the x86 and the x64 version)
• http://llvm.org/releases/3.4/LLVM-3.4-win32.exe
• https://github.com/CRogers/LLVM-Windows-Binaries/releases/download/v3.4/llvm-3.4-tools-windows.7z

If you want to build moco yourself you'll need to install the following dependencies and a JDK 7. These examples use the chocolatey package manager.

choco install maven
choco install java.jdk
choco install git.commandline

You can also install Graphviz to generate class diagrams. This is optional.

choco install graphviz

Building

Note: Instead of building your own version you can always get a precompiled .jar file at the releases page.

For building your own version based on the most recent commit clone the git repository:

git clone https://github.com/MontysCoconut/moco.git

After that you can change into the directory and build the executable .jar file. Now you can find the executable jar in the target/ directory.

cd moco
mvn package

If you want to generate the class documentation make sure to have graphviz installed and run the following command. After that you can find the generated HTML-files in the target/site directory.

mvn site

For some background information and a guide to submit merge requests please read hacking.

Usage

To use moco you'll either need to compile your own version or fetch a precompiled .jar file at the releases page.

You can just pass moco a Monty-file and it will be compiled and executed.

➤ cat hello.monty
print("Hello World!")
➤ java -jar moco-0.6.jar hello.monty
Hello World!

Please see the help text for information about the command-line switches. usage: moco [--help] [-S] [-c] [-e] [-p] [-d] [-o ] [file]

The Monty compiler.

positional arguments:
file                   Monty file to run.

optional arguments:
--help                 Print this help and exit.
-S, --emit-assembly    Emit the LLVM assembly and stop.
-c, --compile-only     Only compile the executable without running it.
-e, --stop-on-first-error
                        Stop the compilation on the first encountered error.
-p, --print-ast        Print the AST.
-d, --debug-parsetree  Debug the parsetree without running anything.
-o <file>              Write output to <file>.

Without -S or -c the program is compiled and directly executed.

moco's Issues

Returning from if-Statement

Code generation for if-Statements seems broken. The following code produces the lli error

lli: C:\Users\Simon\Documents\Java\moco\target\test-classes\testPrograms\if.ll:110:1: error: expected instruction opcode

print(foo(true))
print(foo(false))

String foo(Bool cond):
    if cond:
        return "a"
    else:
        return "b"

Generated code:

define i8* @M.if.F.foo$M.std.C.String$M.Bool.C.Bool(%M.Bool.C.Bool* %M.if.V.cond$M.Bool.C.Bool)  {
    entry:
    %_unnamed_0 = getelementptr inbounds %M.Bool.C.Bool* %M.if.V.cond$M.Bool.C.Bool, i32 0,i32 1
    %_unnamed_1 = load i1* %_unnamed_0
    br i1 %_unnamed_1, label %if0.true, label %if0.false
    if0.true:
    ret i8* getelementptr inbounds ([2 x i8]* @.0, i32 0, i32 0)
    br label %if0.end
    if0.false:
    ret i8* getelementptr inbounds ([2 x i8]* @.1, i32 0, i32 0)
    br label %if0.end
    if0.end:
}

I'm not sure wether this applies to the current master but the code generation for if-statements seems not to have changed recently.

Error reporting

In many cases the exception classes do not receive an ASTNode object, therefore the error reporting can not provide a line number of the error (which is not very helpful in many cases):

ResolveVisitor caught error in null: ...

instead of

ResolveVisitor caught error in line 7, char 13: ...

The problem is that those exceptions are thrown inside the Scope class, which does not have any node objects associated, thus there is no node to pass to the exception object.

Any suggestions are appreciated.

EmptyStackException when using Expressions without assigning their value to a variable

I encountered a bug in the current master revision of the Monty compiler (although this also seems to be broken in earlier versions). The following Monty input program produces an EmptyStackException in the CodeGenerationVisitor:

class Person:
    + Int age():
        return 8

Int x := Person().age()

While the following Monty program works fine:

class Person:
    + Int age():
        return 8

Person p := Person()
Int x := p.age()

It seems like expressions which are not assigned to a variable are not correctly pushed to the stack. The corresponding stack trace looks like the following:

java.util.EmptyStackException
        at java.util.Stack.peek(Stack.java:102)
        at java.util.Stack.pop(Stack.java:84)
        at de.uni.bremen.monty.moco.visitor.CodeGenerationVisitor.visit(CodeGenerationVisitor.java:200)
        at de.uni.bremen.monty.moco.ast.statement.Assignment.visit(Assignment.java:84)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visitDoubleDispatched(BaseVisitor.java:72)
        at de.uni.bremen.monty.moco.visitor.CodeGenerationVisitor.visit(CodeGenerationVisitor.java:191)
        at de.uni.bremen.monty.moco.ast.Block.visit(Block.java:106)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visitDoubleDispatched(BaseVisitor.java:72)
        at de.uni.bremen.monty.moco.ast.declaration.ModuleDeclaration.visitChildren(ModuleDeclaration.java:99)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visit(BaseVisitor.java:128)
        at de.uni.bremen.monty.moco.ast.Package.visitChildren(Package.java:77)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visit(BaseVisitor.java:425)
        at de.uni.bremen.monty.moco.visitor.CodeGenerationVisitor.visit(CodeGenerationVisitor.java:179)
        at de.uni.bremen.monty.moco.ast.Package.visitChildren(Package.java:74)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visit(BaseVisitor.java:425)
        at de.uni.bremen.monty.moco.visitor.CodeGenerationVisitor.visit(CodeGenerationVisitor.java:174)
        at de.uni.bremen.monty.moco.ast.Package.visit(Package.java:68)
        at de.uni.bremen.monty.moco.visitor.BaseVisitor.visitDoubleDispatched(BaseVisitor.java:72)
        at de.uni.bremen.monty.moco.Main.visitVisitors(Main.java:127)
        at de.uni.bremen.monty.moco.Main.main(Main.java:246)

LLVM update (3.5 -> 3.7)

For some time now a new LLVM version is available: http://llvm.org/releases/.

We might need to update to that version (LLVM 3.7).

I started some time ago, but am not doing it actively right now. See https://github.com/lummax/moco/tree/llvm-upgrade.