Is this project continuted?
snikeguo opened this issue · 3 comments

Last updated four days ago.
This project has not been updated for a long time
In this case, it seems possible to use the C # programming language to develop the MCU
@smaillet
Yes, LLVM.NET is going. LLVMv4 was skipped as a significant rework of the attributes support was needed and V4 (and into v5) that has stabilized into an official C API. At present work is underway to get builds under AppVeyor. Since, this needs full libraries and headers from LLVM that is a tricky task as there are limits on the total run time of a build and the LLVM code alone will generally exceed it. To manage that the LLVM libs and headers are being packaged with NUGET, though even that requires some care as the public NUGET feeds all limit the max size of any package so they need to be split down into more manageable chunks. That part seems to be solved at this point.
it seems possible to use the C # programming language to develop the MCU
While this is the primary use case for this library it isn't the only possible use. Nor is it something that just works stand alone. LLVM.NET is a managed wrapper/projection of the LLVM libraries which are a set of building blocks for creating compiler back-ends, interpreters and JIT runtimes. On it's own it isn't capable of converting from C# to an MCU.
That said, Llilum is a working proof of how it can be used for that. I am also working on a project (not yet published as it isn't really very useable yet - no ref objects, or exceptions, just by value types) that is based on the latest LLVM.NET and takes all the things learned from working on MCU projects, NETMF, and Llilum to make a new AOT compilation tool that is efficient in space/performance at run time as well as fast at compile time. Furthermore, a major goal is in enabling low level hardware register access in a type safe verifiable manner. This generally involves generating register level descriptions in code with tool specific attribute annotations from a hardware description like CMSIS-SVD.
If this is something you are interested in helping contribute to in some way let me know and I will endeavor to make it a public repo sooner. There's a ton of work to do that isn't super low level code gen, like defining proper SDK and project support in msbuild. The new CPS csproj system with extensible SDKs helps this case. Unfortunately the mechanics of the extensions, VSIX packaging, NUGET packaging, framework and platform specific libraries etc.. aren't particularly well documented at this stage of things so that's a good chunk of work to decipher and plan out how to leverage it properly for MCUs.
You say that you want to create a new AOT compiler tool, I do not know what kind of function can be achieved.
In any case, I would like to use C # language to develop MCU (AOT, not JIT).
Here are some of my views:
You said the exception. In fact, we are in the debugging phase, using a similar "ASSERT" approach. I think, here should be the C # exception it Once an exception has occurred, it should be stopped at while (1), so that developers to fix BUG.
/********************************************/
The most important thing, how can I do something for this project? In this project, I can do what kind of work?
Right now there isn't an open list of up for grabs work - once the AppVeyor automated build is up and going and PRs can be validated with an automated BuddyBuild we'll be better set up for contributions.