Has anyone tried to port Mono to RTEMS

xuelin.tian at qkmtech.com xuelin.tian at qkmtech.com
Fri Jul 14 04:02:08 UTC 2017


OK, thanks a lot.
I will go through Lua today, to see if there is something interesting there.



Best wishes,
xuelin.tian at qkmtech.com
 
From: Russell Haley
Date: 2017-07-14 11:57
To: xuelin.tian; Joel Sherrill
CC: users
Subject: Re: Has anyone tried to port Mono to RTEMS
Just my opinion on the 'or other vm' comment. 

If your requirement is not strictly mono, I highly suggest something small and simple like Lua. It's a a very efficient vm and is cross compatible with all major platforms. The only requirement for Lua is c99. 

The language is very simple and bare bones. You pick your tools from git or a repository manager called luarocks (luarocks.org). That's where the 'hard part' of Lua comes in. It's very hands on because you need to find or write almost everything you need. 

I am putting together a 'lightweight' IoT platform using Lua 5.3 and a very sophisticated polling library called cqueues. There is an http library called lua-http based on cqueues that contains a client and server implementation of most major http standards including http2 and websockets. The requirements for cqueues are a polling library such as epoll or kqueues (or even poll or select). I'm not sure how well that would plug into rtems. ‎At this point I'm cross compatible for most major Nixs' though. 

Nonetheless, the overhead of mono is not really worth it if you are doing simple things. ‎That's why I switched away from DotNet for my project. If you have code to port, or have DotNet developers, mono makes sense. 

‎Just my opinion. 

HTH
Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
From: xuelin.tian at qkmtech.com
Sent: Thursday, July 13, 2017 8:38 PM
To: Joel Sherrill; Russell Haley
Cc: users at rtems.org
Subject: Re: Re: Has anyone tried to port Mono to RTEMS

Yes, I am trying to build it from source according to Russell.

As to .net core, I may not have a deep understanding of it. I think for now, Mono may be the best choice for me, since I need to make it (porting Mono or other VM to rtems) work in a few days. 



Best wishes,
xuelin.tian at qkmtech.com
 
From: Joel Sherrill
Date: 2017-07-13 01:08
To: Russell Haley
CC: xuelin.tian at qkmtech.com; users at rtems.org
Subject: Re: Re: Has anyone tried to port Mono to RTEMS
The reply from Russell is very good advice. Look forward when porting and
make sure you are porting something with a future.

For Mono, I did exactly what he outlined. I built native. I recall it using a 
fairly normal configure script and I just added --target=XXX-rtems. I might
have added some CFLAGS but don't recall. 

I focused on the run-time interpreter and ignored the JIT. The run-time
translated Mono calls into C library and POSIX calls. If there was a 
compilation issue, I tried to fix it where ever it had to be fixed. Always being
open to adding something to either RTEMS or newlib if possible
and needed.

--joel

On Wed, Jul 12, 2017 at 11:03 AM, Russell Haley <russ.haley at gmail.com> wrote:
On Tue, Jul 11, 2017 at 9:31 PM, xuelin.tian at qkmtech.com
<xuelin.tian at qkmtech.com> wrote:
> Dear Joel,
> Recently, I continue to port Mono to RTEMS.
> Porting consists of two parts, according to the Mono documents online, JIT
> engine and OS support.
> JIT part is already done, since I use ARM platform.
> And I am confuesd about OS part and how to build Mono on RTEMS.
> Could you recall any details about how to build Mono on RTEMS? Thank you.

I'm not sure that's quite right. There are really 3 parts: The
application framework, the 'JIT' (Mono Runtime, or Common Language
Runtime in Microsoft .Net) and the OS specific layer. The application
framework and the JIT are common to all platforms. The OS specific
parts are in the Mono Runtime where it translates the Interediate
Language (IL) to machine specific code at ... er ... runtime. The Mono
Runtime is being slowly replaced by the Roslyn compiler, which is open
source from Microsoft (very very cool stuff).

Building Mono requires a number of parts, including boot strapping the
build and downloading binaries from nuget (last time I did it,
anyway). I've never attempted to cross compile Mono. I would assume
you would change the make file to point to a cross compiler such as
arm-unknown-gcc (not sure about the RTEMS specifics).

In my opinion the best bet is to pull the mono repository from GitHub
and build it for your host platform first. Then you could look at
modifying it to build on arm.

That said, Mono is a dead/dying platform. Microsoft has bought
Xamarian (Mono sponsor company). Now the Mono Dev Team is slowly
porting everything over to the Microsoft .Net Core code. Once the
majority of libraries are converted, they can then write Mono specific
modules for legacy applications and then shuffle everyone over to
DotNet Core. It might be wise to look at using the DotNet Core instead
of Mono. There are a number of reasons to prefer the DotNet Core:

- Designed to be small and use a package manager to import required
external libraries. This was done with embedded systems in mind.
- Better interpreter: the new interpreters (Rosylin and the other that
I don't remember the name of) are very efficient compared to the Mono
mc.
- More efficient runtime. The Mono Runtime is known to be slow.

 Here would be a good place to start with the DotNet Core as they have
nightly arm builds.

https://stevedesmond.ca/blog/net-core-on-arm


HTH,

Russ

> ________________________________
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> From: Joel Sherrill
> Date: 2017-05-24 20:19
> To: xuelin.tian
> CC: rtems-users at rtems.org
> Subject: Re: Has anyone tried to port Mono to RTEMS
>
>
> On May 23, 2017 8:58 PM, "xuelin.tian at qkmtech.com" <xuelin.tian at qkmtech.com>
> wrote:
>
> Dear all,
> Is that possible to port Mono to RTEMS? Has anyone tried this before?
> As I notice that there is an open project in RTEMS projects.
>
>
> Sometime ago, I was asked to provide an estimate for this. It had to be
> between five and ten years ago because we were at the old office but after
> we had done a few years of GSoC. I did enough work preparing the estimate
> where I had the code building without too much effort. I saw the challenge
> as getting the test suite running since you would have to create a test
> harness and build/assembly helper that packaged the interpreted code with
> the interpreter in order to run it. At that time, I envisioned having to
> create a base image and a filesystem image per test.
>
> Our POSIX was good enough then to avoid much trouble. It should only be
> easier now since the POSIX support has improved.
>
> There were a lot of Mono tests and I expected most to pass quickly. But
> there was no way to know how many issues would be encountered and how many
> root causes there would be. I expected to fix one or two things and then run
> all the tests. That was where I expected time to be consumed.
>
> FWIW I recall the GSoC date part because they thought we could magically get
> students to do testing for free on a schedule. :)
>
> I hope that helps. It is feasible but the key is testing.
>
> --joel
>
>
> ________________________________
> Best wishes,
> xuelin.tian at qkmtech.com
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170714/aaee362b/attachment-0002.html>


More information about the users mailing list