Lua on RTEMS (was Re: Has anyone tried to port Mono to RTEMS)

Sat Jul 15 20:05:01 UTC 2017

It means use the Lua build system and pass.it the proper configure options
to cross compile for RTEMS. Lua is supposed to be simple enough code that
you shouldn't trip any code issues.

Ideally, it gets an RSB recipe so anyone can easily reproduce the build on
any RTEMS BSP.

On Jul 15, 2017 3:22 PM, "Russell Haley" <russ.haley at gmail.com> wrote:

> Sorry for the top post.
>
> Doe 'rtems-friendly' mean integrated with the build system or setting
> specific compiler flags for rtems?
>
> I typically build lua for arm from git and (from memory and my C is poor)
> set -fPic‎. I don't remeber if it was necessary for debian or just freebsd.
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
> *From: *Gedare Bloom
> *Sent: *Saturday, July 15, 2017 5:17 AM
> *To: *Russell Haley
> *Cc: *users at rtems.org
> *Subject: *Re: Lua on RTEMS (was Re: Has anyone tried to port Mono to
> RTEMS)
>
> As I recall, the Lua integration did not take much effort. A GSoC student
> worked on this a few years back and spent the most time tinkering with
> Lua's Makefile to get the library built in a "RTEMS-friendly" way, but it
> should be possible to compile/link Lua as an application-level product
> without difficulty.
>
> Unfortunately, the files produced by the student appear to be lost for now.
>
> On Sat, Jul 15, 2017 at 1:30 AM, Russell Haley <russ.haley at gmail.com>
> wrote:
>
>> Ha ha rtfm Russell. I thought I had seen that somewhere...
>>
>> https://devel.rtems.org/wiki/Packages/LUA
>>
>> Unfortunately the link to the setup file is missing. Does anyone have
>> more information?  I'll keep googling.
>>
>> I have a week off and my family is away so I'm really keen to get this
>> working on my bbb.
>>
>> Cheers,
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> *From: *Russell Haley
>> *Sent: *Thursday, July 13, 2017 9:44 PM
>> *To: *xuelin.tian at qkmtech.com; Joel Sherrill
>> *Cc: *users at rtems.org
>> *Subject: *Re: Has anyone tried to port Mono to RTEMS
>>
>> Thinking about it, Lua is designed to be statically linked into C
>> applications and your scripts are loaded and executed by your application
>> at runtime. This is how lua is plugged into many video games like world or
>> warcraft and roblox.
>>
>> From my simplistic understanding of rtems (and everything I just said),
>> that would be the way you would statically link lua into rtems?
>>
>> Russ
>>
>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>> *From: *xuelin.tian at qkmtech.com
>> *Sent: *Thursday, July 13, 2017 9:03 PM
>> *To: *Russell Haley; Joel Sherrill
>> *Cc: *users at rtems.org
>> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>>
>> 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 <russ.haley at gmail.com>
>> *Date:* 2017-07-14 11:57
>> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
>> <joel at rtems.org>
>> *CC:* users <users at rtems.org>
>> *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 <joel at rtems.org>
>> *Date:* 2017-07-13 01:08
>> *To:* Russell Haley <russ.haley at gmail.com>
>> *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
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170715/bc8c3e07/attachment-0002.html>