Has anyone tried to port Mono to RTEMS

Wed Jul 12 17:08:19 UTC 2017

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/20170712/7b0aae7e/attachment-0002.html>