Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Marius Ungureanu
    @Therzok
    I don’t think there’s a concept like private branches on github
    so yeah, that should be accessible!
    Ludovic Henry
    @luhenry
    @kaby76 did you make sure to add git@github.com:lambdageek/mono.git as a remote to your local git repo? Once you have that you should be able to check it out with git fetch lambdageek mjit && git checkout -b mjit FETCH_HEAD.
    Ken Domino
    @kaby76
    @luhenry Thanks, that was the problem--git gui in the way. The correct commands to view the repo: git clone https://github.com/lambdageek/mono.git
    cd mono
    git remote add git@github.com https://github.com/lambdageek/mono.git
    git fetch https://github.com/lambdageek/mono.git mjit
    git checkout -b mjit FETCH_HEAD
    Ken Domino
    @kaby76
    I do not see the complete source in the mjit branch. For example, I cannot find the definition for "IOperationProcessor" within any CS file within the entire "mono" source tree. Further, the file Mono.Compiler/Mono.Compiler.csproj contains a reference to CompilerInformation.cs, and other files, which are missing in the branch. Please check in all files and verify that what I'm doing in the above commands is correct. Thanks.
    I think the csproj needs to be regenerated from the .dll.sources
    Aleksey Kliger (λgeek)
    @lambdageek
    I don't think any of us used the csproj during hack week. one of the first follow-up tasks that we'd talked about was to move the compiler implementation out of the Mono repo - keep just the interfaces in Mono but do all the managed work out in a separate repo with proper visual studio support and everything.
    there should really be three separate components: the managed-native-managed compiler interface (in Mono's repo), common utilities built on top of it (ecma type system, common algorithms, convenience methods atop the compiler interfaces; Ming's stack types code), and finally an example compiler implementation like BigStep
    Jan Kotas
    @jkotas
    I have just read your blog post. Nice hackathon project!
    It is very similar to what we have been doing in CoreRT.
    https://github.com/lambdageek/mono/tree/mjit/mcs/class/Mono.Compiler/Mono.Compiler.BigStep = https://github.com/dotnet/corert/tree/master/src/ILCompiler.WebAssembly/src/CodeGen (even though the name says WebAssembly, it is a LLVM IL frontend for the most part, minimal WebAssembly specific code)
    The CoreRT repo has 3 different compilers hooked up to this as examples: RyuJIT, CppCodeGen and LLVM/WebAssembly. With various level of completeness - RyuJIT is the most complete one.
    Aleksey Kliger (λgeek)
    @lambdageek
    Well that makes sense since we're solving roughly the same problem. :smile:
    From my point of view this was an exercise to find out how much refactoring would have to go into Mono to get a managed compiler hooked up
    And what the interface to the runtime might look like - there were different design decisions made in Mono so it wasn't entirely obvious that it would match up exactly with what we saw in CoreRT
    Aleksey Kliger (λgeek)
    @lambdageek
    There's also some tension between some existing EE design in Mono and what we could do from managed with LLVMSharp in a short amount of time. For example Mono's code manager is a component that manages pages of JITed code. It really wants to own that memory. But it turns out it's difficult to get LLVM to hand off JITed code without subclassing a couple of LLVM's C++ classes - not something that LLVMSharp does today. So we'll need either to generalize Mono's code manager or LLVMSharp.
    Jan Kotas
    @jkotas
    Agree that the interface to the runtime is custom. It is hard to reuse it between different runtimes or execution environments.
    Our experience has been that the type system object model (ClassInfo/MethodInfo/FieldInfo in mjit, TypeDesc/MethodDesc/FieldDesc in CoreRT) and algorithms built on top of it can be shared between different runtimes or execution environments pretty naturally.
    Aleksey Kliger (λgeek)
    @lambdageek
    agree completely. it was frustrating reinventing that wheel - much better to share.
    Bernhard Urban-Forster
    @lewurm
    damn it :smile: that looks very similar indeed
    @jkotas how is IlToWebAssemblyImporter hooked into the runtime? is there some equivalent to ICompiler?
    Ken Domino
    @kaby76
    Starting with the BigStep example, and following the discussion, there seems to be a bit missing for a real compiler framework. While there is a meta system within Mono.Compiler that I can call at JIT time, e.g., to convert a token into field in ldsfld, etc, I'm not sure what you intend to provide to support that at runtime, e.g, the generated code for ldfld or call/callvirt need to do a lookup with a meta system. I can and do do this with my own meta system, but that's the crux of the problem for my GPU compiler.
    Aleksey Kliger (λgeek)
    @lambdageek
    @kaby76 that's exactly the part that is very incomplete at the moment - our intention was to add methods to RuntimeInformation (https://github.com/lambdageek/mono/blob/mjit/mcs/class/Mono.Compiler/Mono.Compiler/RuntimeInformation.cs#L55) such as ComputeStaticFieldAddress that call into the runtime to get the required info. A more involved example (that we didn't get to during hack week) might be for a call from one method to another - in that case we would need to provide an internal call method where we could query the runtime for the address of the callee if it has already been JITed, or else cooperate on setting up a trampoline to JIT the callee the first time it is needed.
    Jan Kotas
    @jkotas
    @lewurm https://github.com/dotnet/corert/blob/635cf21aca11265ded9d78d216424bd609c052f5/src/JitInterface/src/CorInfoImpl.cs#L144 is the specific bridge for RyuJIT. There are no 1:1 equivalents of mjit ICompiler or IRuntimeInformation interfaces in CoreRT. It is broken into multiple pieces in CoreRT.
    The execution-model neutral methods are directly on the type system objects. For example, the equivalent of MethodInfo IRuntimeInformation.GetMethodInfoFor is MethodDesc TypeDesc.GetMethod.
    We have not found a good way to unify the different types of compilation. They differ a lot. For example: To access a field with RyuJIT, you need an offset. To access a field with CppCodeGen, you need mangled field name that gets printed into cpp output.
    Bernhard Urban-Forster
    @lewurm
    that's an interesting example. my naive answer would be "can't it provide both offset and mangled field name?", but I assume there are more things like that :slight_smile:
    so... for RyuJIT. is it used as a JIT or rather as an AOT compiler @jkotas ?
    Jan Kotas
    @jkotas
    (JIT prototype in CoreRT is very rough/incomplete.)
    Bernhard Urban-Forster
    @lewurm
    interesting. thank you for all the pointers! :smile:
    Michal Strehovský
    @MichalStrehovsky
    I've restored the JIT prototype for CoreRT in dotnet/corert#6327 - once that's merged, it should be possible to step through all the managed parts that directly talk to RyuJIT in a debugger and see it compile "return 100", publish the bytes, and see AOT compiled managed code call into the generated method body. We use RyuJIT as the backend, but the execution strategy is pretty pluggable in CoreRT too
    Ken Domino
    @kaby76
    For the sake of brevity here, I've written out some of my observations from Campy and the GPU perspective: https://1drv.ms/w/s!Atb3HX_AxX9ZgaZqXV1bF6fB-ms3sA
    Morgan Brown
    @morganbr
    @kaby76, that's an interesting set of observations. WRT finding liveness, one of the "interesting" constraints of WebAssembly is that it's not possible to get a pointer to the stack and there's no concept of registers. That means that we have to maintain a separate "shadow stack " that contains all of our GC references rather than relying on built-in mechanisms (phis, arguments, allocas, etc). It's true that we could use potentially use phis for non-gc references.
    Alexander Kyte
    @alexanderkyte
    Is there any plan to make the current JIT/AOT compiler/runtime implement the ICompiler interface? I think that would be great for code quality.
    There’s a ton of implicit contracts that we could refine and make explicit that way
    It would make unit testing a lot easier too
    Aleksey Kliger (λgeek)
    @lambdageek
    @alexanderkyte it's already done. but in a way you may find unsatisfying: https://github.com/lambdageek/mono/blob/mjit/mcs/class/Mono.Compiler/Mini/MiniCompiler.cs
    Ken Domino
    @kaby76
    @morganbr Please look at this example https://1drv.ms/w/s!Atb3HX_AxX9ZgahHi4Fq0UtPufWPDw .
    Alexander Kyte
    @alexanderkyte
    @lambdageek so this is for the JIT I imagine. Has AOT or interp been shoehorned into this?
    Aleksey Kliger (λgeek)
    @lambdageek
    Not yet. for hack week we just focused on the jit.
    Aleksey Kliger (λgeek)
    @lambdageek
    the mjit branch is starting to fall behind master a fair bit. I'm going to try to merge the latest master changes into the branch. will push if looks clean.
    Miguel de Icaza
    @migueldeicaza
    Love it
    I would love to get the interface merged