A crazy suggestion: support google's go programming language on nuttx

[Paul.Y.Zhang]

Hi, Greg, and other guys,

We need look at future, think about 3~5 year later, what will be the
most important requirement for rtos. I guess, it is complicated
application fast development. In next few years, there will be a big
oportunity for RTOS. Because the MCU will become higer performance and
complicated, and its performance will be simular as today's low-end app
processer. At that time, the bare metal form development will be
impossible, and rtos will be "have to". Then, what programming lang?
C++? Maybe, but it is not good solution, because it's memory leakage
issue, and too difficult for many embedded software programers. I DO NOT
like c++, at least. I think golang is a good choice, if possible. Why go
lang?
1. it is BSD license.
2. it support so many modern features
3. simple than C++

It seems unneccesary to support higher programing language now, but
please consider, suppose the mcu's speed become 1Ghz, SRAM become 1MB,
and application is too complex to C.

I know portting the go runtime onto nuttx is very difficult, but it will
be an overkill feature than other rtoses, and will make the embedded
programing easier and fast.

How do you think about it?

[Gregory N]

Hi, Paul,

Post by Paul.Y.Zhang
We need look at future, think about 3~5 year later, what will be the
most important requirement for rtos. I guess, it is complicated
application fast development. In next few years, there will be a big
oportunity for RTOS. Because the MCU will become higer performance and
complicated, and its performance will be simular as today's low-end app
processer. At that time, the bare metal form development will be
impossible, and rtos will be "have to". Then, what programming lang?
C++? Maybe, but it is not good solution, because it's memory leakage
issue, and too difficult for many embedded software programers. I DO NOT
like c++, at least. I think golang is a good choice, if possible. Why go
lang?
1. it is BSD license.
2. it support so many modern features
3. simple than C++
It seems unneccesary to support higher programing language now, but
please consider, suppose the mcu's speed become 1Ghz, SRAM become 1MB,
and application is too complex to C.
I know portting the go runtime onto nuttx is very difficult, but it will
be an overkill feature than other rtoses, and will make the embedded
programing easier and fast.
How do you think about it?

I am in favor of using NuttX in any environment that is possible. But I would have concerns about the logistics and appropriateness of incorporating the Go runtime into the NuttX repository. That really depends upon what the run time consists of and how big it is and how you would envision incorporated the Go runtime into NuttX. For most interpreted languages, the runtime usually consists of the entire interpreter/virtual machine and is quite large. Is that the case here too?

On the other hand, if you are talking about some kind of simple "shim" layer that will allow support for the Go language, I am 100% in favor. If you are talking about a fork of the entire runtime, then I have concerns.

We have been through this same discussion on the forum very recently, but with the Lua language. Mike Smith and Darcy Gong integrated Lua into NuttX and Darcy provided the patches to incorporate Lua into the NuttX apps/ repository. But I was not quite sure what to do with the patches. I am still not sure.

My concerns is that I do not want the NuttX source tree to become a large collection of forks from other repositories. The would dilute and clutter the NuttX source tree, but also:

1) There is no way that I can maintain this foreign code within NuttX. Often these "patches" are as large or larger than the entire NuttX apps/ package. What would I do with all of this foreign code later? Who would support that code? I can't.

2) In a few months, the forked code will be obsolete because no one will be maintaining it. In a year it will be a useless. If there is no on-going maintenance and synchronization with the application repository, then the fork will be become obsolete very quickly.

The correct thing to do, really, is not to incorporate these large applications into NuttX, but rather to incorporate NuttX support into the application in the application's repository. That way, the code is maintained and has a future direction. It would be better if Lua supported NuttX, rather than NuttX supporting Lua. In the same way, it would be better if Go supported NuttX rather than NuttX supporting Go.

What happened to the Lua port? I put it here for now because I still do not know what to do with it: http://tech.groups.yahoo.com/group/nuttx/files/lua/

What can you do if the owners of the application repository are not interested in supporting NuttX? Perhaps we can create our own project that is a fork of other projects for NuttX. But that would be, I think, a different project from NuttX with different administrators and different maintainers. I would be happy to be a developer on that project, but I cannot own those forks. That is much more than I am able or willing to do myself.

I do not want to discourage you. Just the opposite. I want to encourage you, but I simply do not know how to do that. I am open to suggestions from other members of the group. If anyone wants to own a project that consists of forks from other projects, I will help you with that. Any ideas? suggestions?

This same topic comes up repeatedly. What is the solution?

Greg

[Freddie Chopin]

I am in favor of using NuttX in any environment that is possible. But I
would have concerns about the logistics and appropriateness of
incorporating the Go runtime into the NuttX repository. That really
depends upon what the run time consists of and how big it is and how you
would envision incorporated the Go runtime into NuttX. For most
interpreted languages, the runtime usually consists of the entire
interpreter/virtual machine and is quite large. Is that the case here too?
On the other hand, if you are talking about some kind of simple "shim"
layer that will allow support for the Go language, I am 100% in favor.
If you are talking about a fork of the entire runtime, then I have concerns.

As GO's idea seems nice I did some googling and on their mailing list
there are many post stating that golang is intended as a general purpose
language and that it means "not-embedded" and "not-real-time", many
people think it would be impossible to use that in a constrained
environment of an embedded target.

https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/95BJqJvb7I0
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/H_OnTfQGKIs

Golang uses garbage collection and dynamic typing, so I guess that the
runtime is pretty huge (for embedded standards).

As for the optimism about the power of microcontrollers I think that
Moore's law doesn't apply to this area. LPC2xxx were introduced almost
ten years ago (don't know the exact date, but I think it's pretty close)
- these devices were running at 60-70MHz and had quite a lot or memory
(LPC2148 has 512kB or flash and 40kB of RAM, LPC2106 [one of the first
devices?] has 64kB of RAM). There are also devices with external bus
(LPC22xx) if you need more memory.

It's 2013 now, one of the most powerful MCUs are NXP LPC43xx and STM32F4
- these can have about 1MB of flash and ~200kB or RAM, they run at
~200MHz. So for ten years the speed (clock) and capacity of POPULAR MCUs
has just tripled. I just don't think we'll see a device with built-in
1MB of RAM or a 1GHz clock very soon...

Of course I'm not talking about Cortex-A, ARM9 and ARM11 or some other
application processors - let's say that I'm talking about devices that
cost ~10$ and are "microcontrollers", not "microprocessors" (however
blurry the distinction may be).

4\/3!!

[Paul.Y.Zhang]

Post by Freddie Chopin
there are many post stating that golang is intended as a general purpose
language and that it means "not-embedded" and "not-real-time", many
people think it would be impossible to use that in a constrained
environment of an embedded target.
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/95BJqJvb7I0
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/H_OnTfQGKIs

Thanks for you links. I dose not mean to let Go on nuttx support
REALTIME, that is uncessary. As the discussion thread in above links,
said, "gccgo has been ported to RTEMS", so it is also possible to be
ported to NUTTX, right?

Post by Freddie Chopin
Golang uses garbage collection and dynamic typing, so I guess that the
runtime is pretty huge (for embedded standards).

FYI, Golang is a static typing language.

Post by Freddie Chopin
As for the optimism about the power of microcontrollers I think that
Moore's law doesn't apply to this area. LPC2xxx were introduced almost
ten years ago (don't know the exact date, but I think it's pretty close)
- these devices were running at 60-70MHz and had quite a lot or memory
(LPC2148 has 512kB or flash and 40kB of RAM, LPC2106 [one of the first
devices?] has 64kB of RAM). There are also devices with external bus
(LPC22xx) if you need more memory.
It's 2013 now, one of the most powerful MCUs are NXP LPC43xx and STM32F4
- these can have about 1MB of flash and ~200kB or RAM, they run at
~200MHz. So for ten years the speed (clock) and capacity of POPULAR MCUs
has just tripled. I just don't think we'll see a device with built-in
1MB of RAM or a 1GHz clock very soon...
Of course I'm not talking about Cortex-A, ARM9 and ARM11 or some other
application processors - let's say that I'm talking about devices that
cost ~10$ and are "microcontrollers", not "microprocessors" (however
blurry the distinction may be).

The main different point between microcontroller and microprocessor is
the memory system, so the key is malloc of the runtime for different
develop way. So, the key problem is the memory requirment of Go runtime.
Whether or not Go can run at less 100KB ram, this maybe the stone.

[Paul.Y.Zhang]

Hi, Greg,

I am in favor of using NuttX in any environment that is possible. But
I would have concerns about the logistics and appropriateness of
incorporating the Go runtime into the NuttX repository. That really
depends upon what the run time consists of and how big it is and how
you would envision incorporated the Go runtime into NuttX. For most
interpreted languages, the runtime usually consists of the entire
interpreter/virtual machine and is quite large. Is that the case here too?

Go is not a interpreted language, it is totally a compiled language.
Quoted from http://golang.org/doc/ : "Go compiles quickly to machine
code yet has the convenience of garbage collection and the power of
run-time reflection. It's a fast, statically typed, compiled language
that feels like a dynamically typed, interpreted language. "

On the other hand, if you are talking about some kind of simple "shim"
layer that will allow support for the Go language, I am 100% in favor.
If you are talking about a fork of the entire runtime, then I have
concerns.

Go runtime on bare metal is impossible, because its current runtime
assumes running on unix kernel, so if nuttx is posix compatible, the go
runtime may be ported on nuttx kernel thru a shim layer. Actually, i
have no idea for thisI am not a programming expert, just a product
manger, so i do not know the detailed below the language magic.

We have been through this same discussion on the forum very recently,
but with the Lua language. Mike Smith and Darcy Gong integrated Lua
into NuttX and Darcy provided the patches to incorporate Lua into the
NuttX apps/ repository. But I was not quite sure what to do with the
patches. I am still not sure.
My concerns is that I do not want the NuttX source tree to become a
large collection of forks from other repositories. The would dilute
1) There is no way that I can maintain this foreign code within NuttX.
Often these "patches" are as large or larger than the entire NuttX
apps/ package. What would I do with all of this foreign code later?
Who would support that code? I can't.
2) In a few months, the forked code will be obsolete because no one
will be maintaining it. In a year it will be a useless. If there is no
on-going maintenance and synchronization with the application
repository, then the fork will be become obsolete very quickly.
The correct thing to do, really, is not to incorporate these large
applications into NuttX, but rather to incorporate NuttX support into
the application in the application's repository. That way, the code is
maintained and has a future direction. It would be better if Lua
supported NuttX, rather than NuttX supporting Lua. In the same way, it
would be better if Go supported NuttX rather than NuttX supporting Go.

Agree!

What happened to the Lua port? I put it here for now because I still
http://tech.groups.yahoo.com/group/nuttx/files/lua/
What can you do if the owners of the application repository are not
interested in supporting NuttX? Perhaps we can create our own project
that is a fork of other projects for NuttX. But that would be, I
think, a different project from NuttX with different administrators
and different maintainers. I would be happy to be a developer on that
project, but I cannot own those forks. That is much more than I am
able or willing to do myself.
I do not want to discourage you. Just the opposite. I want to
encourage you, but I simply do not know how to do that. I am open to
suggestions from other members of the group. If anyone wants to own a
project that consists of forks from other projects, I will help you
with that. Any ideas? suggestions?
This same topic comes up repeatedly. What is the solution?

There is really a requirement for this in the market, and there is still
no answer. Someone need take a try.

Thanks, I have got your thought.

[Gregory N]

Hi, Paul,

Post by Paul.Y.Zhang

Post by Gregory N
On the other hand, if you are talking about some kind of simple "shim"
layer that will allow support for the Go language, I am 100% in favor.
If you are talking about a fork of the entire runtime, then I have
concerns.

Go runtime on bare metal is impossible, because its current runtime
assumes running on unix kernel, so if nuttx is posix compatible, the go
runtime may be ported on nuttx kernel thru a shim layer. Actually, i
have no idea for thisI am not a programming expert, just a product
manger, so i do not know the detailed below the language magic.

I would be happy to support a shim layer for the Go language in the source tree. I am not sure exactly how the build would be done, but it seems that NuttX would be built with its "shim" interfaces; Go would be built separately and they would be linked together in the end to generate the executable.

If Go builds on Linux, then it should also build on NuttX. There are only a few areas of incompatibility:

1) fork() and exec() logic may have to change (see Note).
2) If Go has dependencies on other Linux libraries, that could be problem.
3) There could be some issues with NuttX's simply networking (NuttX lacks some host name support and socket options that are often used).

In my experience, if a program builds on Linux, I can get it to build on NuttX in a couple of days worth of work. Getting usable in the embedded environment, however, can take lot more work.

Greg

*I have been thinking about a simple implementation of vfork() lately and can probably implement that if needed. vfork() is not too difficult if the user follows all of the standard caveat that go with it. NuttX already supports form of exec().

[Paul.Y.Zhang]

Hi, Greg,

Post by Gregory N
I would be happy to support a shim layer for the Go language in the
source tree. I am not sure exactly how the build would be done, but it
seems that NuttX would be built with its "shim" interfaces; Go would
be built separately and they would be linked together in the end to
generate the executable.
If Go builds on Linux, then it should also build on NuttX. There are
1) fork() and exec() logic may have to change (see Note).
2) If Go has dependencies on other Linux libraries, that could be problem.
3) There could be some issues with NuttX's simply networking (NuttX
lacks some host name support and socket options that are often used).
In my experience, if a program builds on Linux, I can get it to build
on NuttX in a couple of days worth of work. Getting usable in the
embedded environment, however, can take lot more work.

Great! Is Nuttx so powerfull? Go is a compiled language, and it support
some two compiler, one called gc, the other is gccgo (which is part of
gcc). I heard that gccgo supports cross compile. I think it is valuable
for you to spend some time to see Go, if you has no other more important
thing.

-- Paul

[Michael Smith]

Great! Is Nuttx so powerfull? Go is a compiled language, and it support some two compiler, one called gc, the other is gccgo (which is part of gcc). I heard that gccgo supports cross compile. I think it is valuable for you to spend some time to see Go, if you has no other more important thing.

Go is a fairly bad fit for NuttX as it stands - the runtime is too large for all but the very largest NuttX configurations (several megabytes) - and embedded systems in general (due to the unpredictable nature of the GC. The one attempt I've seen to build a lightweight Go runtime for embedded systems died several years ago now, and even it was still around a megabyte of code (with lots of omissions).

There are far more interesting languages to be thinking about in the embedded space.
Rust (http://www.rust-lang.org) may turn out well in a few years, depending on where the Mozilla team takes it.
ESL (http://code.google.com/p/esl/) has a lot of potential to supplant C as a low-level implementation language, but it's on the wrong side of the uptake curve still and development seems to be fairly closed.
Clay (https://github.com/jckarter/clay/wiki) is another evolving systems language that has potential.
D (http://dlang.org) has been on the cusp of relevance for quite a while; now that the compiler and community issues are largely sorted, an embedded dialect is a very real possibility. It is far more mature as a language than any of the above.
= Mike

[Freddie Chopin]

* D (http://dlang.org) has been on the cusp of relevance for quite a
while; now that the compiler and community issues are largely
sorted, an embedded dialect is a very real possibility. It is far
more mature as a language than any of the above.

Do you know whether D can be used for an ARM MCU? In other words - is
there a working cross-compiler for bare-metal ARM target?

4\/3!!

[srd_128]

Hi Greg,

At the risk of hijacking this subject (Google's GO on Nuttx), let me respond to a few of your comments with respect to Lua and its Nuttx patch.

Paul sees great potential in Go on Nuttx. Mike, Darcy et al see great potential in Lua on Nuttx (I happen to also be in their camp as a longtime Lua user in embedded platforms). What we all see is the great potential Nuttx has to host these powerful scripting languages and unlock the gate that has traditionally separated MCUs from the POSIX apps/tools developed on and for MMU-based OSs.

The work of integrating Lua has begun, has been demo'd, and it should be finished in a way that models how future 3rd party packages (scripting langs, etc.) could/should be handled. Lua is not the first (Greg, you've already done great work in supporting Pascal), Lua won't be the last, but Lua is a great choice for today's MCUs and offers a treasure trove of libs and apps. And it's a great choice to work out the challenges in paving that path.

IMHO the problem with the "Lua Patch" is it's not a Lua patch, it's a Nuttx tree patch. And that makes it impossible to maintain. I think it would be a lot easier to manage if Lua were to be applied in the following way and steps:
0) create a Makefile that will:
1) Download the Lua src version (5.1.4, 5.2.1, etc.) This is easy to script with wget and drop a Makefile cookie.
2) Untar the src into the Nuttx apps tree, drop a cookie.
3) move and copy header files around with mv/cp in Makefile, drop a cookie.
4) apply a patch to the resultant Lua src. This patch contains only the edits to Lua source files necessary to compile that version of Lua for that version of Nuttx.
5) compile/link the gestalt.

Step 4 is the key point. The patch should contain only the delta from Lua-5.1.4 (let's say) to Lua-5.1.4-running-on-Nuttx. Since both the Lua and Nuttx OS APIs are stable, this patch shouldn't be difficult for the community to modify (dare I say maintain?) as both Nuttx and Lua each evolve. Given this baseline, it would be trivial to then create a similar patch for Lua-5.2.0 or Lua-5.2.1 (kdiff3 with a little oversight and done).

The same approach would work with Go.

Welcome thoughts, comments, flames ;)


Cheers,
-david

Post by Paul.Y.Zhang
Hi, Greg,

I am in favor of using NuttX in any environment that is possible. But
I would have concerns about the logistics and appropriateness of
incorporating the Go runtime into the NuttX repository. That really
depends upon what the run time consists of and how big it is and how
you would envision incorporated the Go runtime into NuttX. For most
interpreted languages, the runtime usually consists of the entire
interpreter/virtual machine and is quite large. Is that the case here too?

Go is not a interpreted language, it is totally a compiled language.
Quoted from http://golang.org/doc/ : "Go compiles quickly to machine
code yet has the convenience of garbage collection and the power of
run-time reflection. It's a fast, statically typed, compiled language
that feels like a dynamically typed, interpreted language. "

On the other hand, if you are talking about some kind of simple "shim"
layer that will allow support for the Go language, I am 100% in favor.
If you are talking about a fork of the entire runtime, then I have
concerns.

Go runtime on bare metal is impossible, because its current runtime
assumes running on unix kernel, so if nuttx is posix compatible, the go
runtime may be ported on nuttx kernel thru a shim layer. Actually, i
have no idea for thisI am not a programming expert, just a product
manger, so i do not know the detailed below the language magic.

We have been through this same discussion on the forum very recently,
but with the Lua language. Mike Smith and Darcy Gong integrated Lua
into NuttX and Darcy provided the patches to incorporate Lua into the
NuttX apps/ repository. But I was not quite sure what to do with the
patches. I am still not sure.
My concerns is that I do not want the NuttX source tree to become a
large collection of forks from other repositories. The would dilute
1) There is no way that I can maintain this foreign code within NuttX.
Often these "patches" are as large or larger than the entire NuttX
apps/ package. What would I do with all of this foreign code later?
Who would support that code? I can't.
2) In a few months, the forked code will be obsolete because no one
will be maintaining it. In a year it will be a useless. If there is no
on-going maintenance and synchronization with the application
repository, then the fork will be become obsolete very quickly.
The correct thing to do, really, is not to incorporate these large
applications into NuttX, but rather to incorporate NuttX support into
the application in the application's repository. That way, the code is
maintained and has a future direction. It would be better if Lua
supported NuttX, rather than NuttX supporting Lua. In the same way, it
would be better if Go supported NuttX rather than NuttX supporting Go.

Agree!

What happened to the Lua port? I put it here for now because I still
http://tech.groups.yahoo.com/group/nuttx/files/lua/
What can you do if the owners of the application repository are not
interested in supporting NuttX? Perhaps we can create our own project
that is a fork of other projects for NuttX. But that would be, I
think, a different project from NuttX with different administrators
and different maintainers. I would be happy to be a developer on that
project, but I cannot own those forks. That is much more than I am
able or willing to do myself.
I do not want to discourage you. Just the opposite. I want to
encourage you, but I simply do not know how to do that. I am open to
suggestions from other members of the group. If anyone wants to own a
project that consists of forks from other projects, I will help you
with that. Any ideas? suggestions?
This same topic comes up repeatedly. What is the solution?

There is really a requirement for this in the market, and there is still
no answer. Someone need take a try.
Thanks, I have got your thought.
--
Paul

[Paul.Y.Zhang]

David,

Lua is a choice for improving the production efficiency. But, I concern
its performance. Refer to this link:
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=go

As for pasical, there is already C, why pasical?

Anyway, it will be pretty to support some higher efficient language to
make the app development faster, than C. C is too low level for
complicated application. Lua, Go or something else, is expected!

BTW, What's the difference between Lua an "eLua"?


- Paul

Post by srd_128
Hi Greg,
At the risk of hijacking this subject (Google's GO on Nuttx), let me
respond to a few of your comments with respect to Lua and its Nuttx patch.
Paul sees great potential in Go on Nuttx. Mike, Darcy et al see great
potential in Lua on Nuttx (I happen to also be in their camp as a
longtime Lua user in embedded platforms). What we all see is the great
potential Nuttx has to host these powerful scripting languages and
unlock the gate that has traditionally separated MCUs from the POSIX
apps/tools developed on and for MMU-based OSs.
The work of integrating Lua has begun, has been demo'd, and it should
be finished in a way that models how future 3rd party packages
(scripting langs, etc.) could/should be handled. Lua is not the first
(Greg, you've already done great work in supporting Pascal), Lua won't
be the last, but Lua is a great choice for today's MCUs and offers a
treasure trove of libs and apps. And it's a great choice to work out
the challenges in paving that path.
IMHO the problem with the "Lua Patch" is it's not a Lua patch, it's a
Nuttx tree patch. And that makes it impossible to maintain. I think it
would be a lot easier to manage if Lua were to be applied in the
1) Download the Lua src version (5.1.4, 5.2.1, etc.) This is easy to
script with wget and drop a Makefile cookie.
2) Untar the src into the Nuttx apps tree, drop a cookie.
3) move and copy header files around with mv/cp in Makefile, drop a
cookie.
4) apply a patch to the resultant Lua src. This patch contains only
the edits to Lua source files necessary to compile that version of Lua
for that version of Nuttx.
5) compile/link the gestalt.
Step 4 is the key point. The patch should contain only the delta from
Lua-5.1.4 (let's say) to Lua-5.1.4-running-on-Nuttx. Since both the
Lua and Nuttx OS APIs are stable, this patch shouldn't be difficult
for the community to modify (dare I say maintain?) as both Nuttx and
Lua each evolve. Given this baseline, it would be trivial to then
create a similar patch for Lua-5.2.0 or Lua-5.2.1 (kdiff3 with a
little oversight and done).
The same approach would work with Go.
Welcome thoughts, comments, flames ;)
Cheers,
-david

Post by Paul.Y.Zhang
Hi, Greg,

I am in favor of using NuttX in any environment that is possible. But
I would have concerns about the logistics and appropriateness of
incorporating the Go runtime into the NuttX repository. That really
depends upon what the run time consists of and how big it is and how
you would envision incorporated the Go runtime into NuttX. For most
interpreted languages, the runtime usually consists of the entire
interpreter/virtual machine and is quite large. Is that the case

here too?

Post by Paul.Y.Zhang
Go is not a interpreted language, it is totally a compiled language.
Quoted from http://golang.org/doc/ : "Go compiles quickly to machine
code yet has the convenience of garbage collection and the power of
run-time reflection. It's a fast, statically typed, compiled language
that feels like a dynamically typed, interpreted language. "

On the other hand, if you are talking about some kind of simple

"shim"

Post by Paul.Y.Zhang

layer that will allow support for the Go language, I am 100% in

favor.

Post by Paul.Y.Zhang

If you are talking about a fork of the entire runtime, then I have
concerns.

Go runtime on bare metal is impossible, because its current runtime
assumes running on unix kernel, so if nuttx is posix compatible, the go
runtime may be ported on nuttx kernel thru a shim layer. Actually, i
have no idea for thisI am not a programming expert, just a product
manger, so i do not know the detailed below the language magic.

We have been through this same discussion on the forum very recently,
but with the Lua language. Mike Smith and Darcy Gong integrated Lua
into NuttX and Darcy provided the patches to incorporate Lua into the
NuttX apps/ repository. But I was not quite sure what to do with the
patches. I am still not sure.
My concerns is that I do not want the NuttX source tree to become a
large collection of forks from other repositories. The would dilute
1) There is no way that I can maintain this foreign code within

NuttX.

Post by Paul.Y.Zhang

Often these "patches" are as large or larger than the entire NuttX
apps/ package. What would I do with all of this foreign code later?
Who would support that code? I can't.
2) In a few months, the forked code will be obsolete because no one
will be maintaining it. In a year it will be a useless. If there

is no

Post by Paul.Y.Zhang

on-going maintenance and synchronization with the application
repository, then the fork will be become obsolete very quickly.
The correct thing to do, really, is not to incorporate these large
applications into NuttX, but rather to incorporate NuttX support into
the application in the application's repository. That way, the

code is

Post by Paul.Y.Zhang

maintained and has a future direction. It would be better if Lua
supported NuttX, rather than NuttX supporting Lua. In the same

way, it

Post by Paul.Y.Zhang

would be better if Go supported NuttX rather than NuttX supporting Go.

Agree!

What happened to the Lua port? I put it here for now because I still
http://tech.groups.yahoo.com/group/nuttx/files/lua/
What can you do if the owners of the application repository are not
interested in supporting NuttX? Perhaps we can create our own project
that is a fork of other projects for NuttX. But that would be, I
think, a different project from NuttX with different administrators
and different maintainers. I would be happy to be a developer on that
project, but I cannot own those forks. That is much more than I am
able or willing to do myself.
I do not want to discourage you. Just the opposite. I want to
encourage you, but I simply do not know how to do that. I am open to
suggestions from other members of the group. If anyone wants to own a
project that consists of forks from other projects, I will help you
with that. Any ideas? suggestions?
This same topic comes up repeatedly. What is the solution?

There is really a requirement for this in the market, and there is

still

Post by Paul.Y.Zhang
no answer. Someone need take a try.
Thanks, I have got your thought.
--
Paul

[David Alessio]

Hi Paul,

Good questions. Please see in-line responses below.

Regards,
-david

Post by Paul.Y.Zhang
**
David,
Lua is a choice for improving the production efficiency. But, I concern
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=go

On the plus side, Lua offers much (from sockets, to RPC, to http server
with Ajax/Jason). Arguably its greatest offer to the Nuttx/MCU space is
that it's interpreted and fast, no compiler needed. For many applications
it can be the "glue logic" that ties together other drivers (written in C).

Go is compiled. The benchmark is interesting, but a bit unfair. In any
case, Lua is tiny, flexible, and one of the fastest scripting languages
around (if not the fastest).

Post by Paul.Y.Zhang
As for pasical, there is already C, why pasical?

pcode. pcode is smaller than C.

Post by Paul.Y.Zhang
Anyway, it will be pretty to support some higher efficient language to
make the app development faster, than C. C is too low level for complicated
application. Lua, Go or something else, is expected!
BTW, What's the difference between Lua an "eLua"?

Lua it "the" language target to run on POSIX OSs. eLua is a gallant effort
to support Lua on the bare metal of MCUs. The eLua team is doing a great
job, in particular with supporting event-driven cooperative multitasking,
but there remains a vast chasm between what eLua can do on the bare metal
and a full-blown MMU-based OS (QNX, NetBSD, Linux). Where the MCU is
capable, that gap can be filled by Nuttx + Lua.

Post by Paul.Y.Zhang
- Paul
Hi Greg,
At the risk of hijacking this subject (Google's GO on Nuttx), let me
respond to a few of your comments with respect to Lua and its Nuttx patch.
Paul sees great potential in Go on Nuttx. Mike, Darcy et al see great
potential in Lua on Nuttx (I happen to also be in their camp as a longtime
Lua user in embedded platforms). What we all see is the great potential
Nuttx has to host these powerful scripting languages and unlock the gate
that has traditionally separated MCUs from the POSIX apps/tools developed
on and for MMU-based OSs.
The work of integrating Lua has begun, has been demo'd, and it should be
finished in a way that models how future 3rd party packages (scripting
langs, etc.) could/should be handled. Lua is not the first (Greg, you've
already done great work in supporting Pascal), Lua won't be the last, but
Lua is a great choice for today's MCUs and offers a treasure trove of libs
and apps. And it's a great choice to work out the challenges in paving that
path.
IMHO the problem with the "Lua Patch" is it's not a Lua patch, it's a
Nuttx tree patch. And that makes it impossible to maintain. I think it
would be a lot easier to manage if Lua were to be applied in the following
1) Download the Lua src version (5.1.4, 5.2.1, etc.) This is easy to
script with wget and drop a Makefile cookie.
2) Untar the src into the Nuttx apps tree, drop a cookie.
3) move and copy header files around with mv/cp in Makefile, drop a cookie.
4) apply a patch to the resultant Lua src. This patch contains only the
edits to Lua source files necessary to compile that version of Lua for that
version of Nuttx.
5) compile/link the gestalt.
Step 4 is the key point. The patch should contain only the delta from
Lua-5.1.4 (let's say) to Lua-5.1.4-running-on-Nuttx. Since both the Lua and
Nuttx OS APIs are stable, this patch shouldn't be difficult for the
community to modify (dare I say maintain?) as both Nuttx and Lua each
evolve. Given this baseline, it would be trivial to then create a similar
patch for Lua-5.2.0 or Lua-5.2.1 (kdiff3 with a little oversight and done).
The same approach would work with Go.
Welcome thoughts, comments, flames ;)
Cheers,
-david

Post by Paul.Y.Zhang
Hi, Greg,

I am in favor of using NuttX in any environment that is possible. But
I would have concerns about the logistics and appropriateness of
incorporating the Go runtime into the NuttX repository. That really
depends upon what the run time consists of and how big it is and how
you would envision incorporated the Go runtime into NuttX. For most
interpreted languages, the runtime usually consists of the entire
interpreter/virtual machine and is quite large. Is that the case here

too?

Post by Paul.Y.Zhang
Go is not a interpreted language, it is totally a compiled language.
Quoted from http://golang.org/doc/ : "Go compiles quickly to machine
code yet has the convenience of garbage collection and the power of
run-time reflection. It's a fast, statically typed, compiled language
that feels like a dynamically typed, interpreted language. "

On the other hand, if you are talking about some kind of simple "shim"
layer that will allow support for the Go language, I am 100% in favor.
If you are talking about a fork of the entire runtime, then I have
concerns.

Go runtime on bare metal is impossible, because its current runtime
assumes running on unix kernel, so if nuttx is posix compatible, the go
runtime may be ported on nuttx kernel thru a shim layer. Actually, i
have no idea for thisI am not a programming expert, just a product
manger, so i do not know the detailed below the language magic.

We have been through this same discussion on the forum very recently,
but with the Lua language. Mike Smith and Darcy Gong integrated Lua
into NuttX and Darcy provided the patches to incorporate Lua into the
NuttX apps/ repository. But I was not quite sure what to do with the
patches. I am still not sure.
My concerns is that I do not want the NuttX source tree to become a
large collection of forks from other repositories. The would dilute
1) There is no way that I can maintain this foreign code within NuttX.
Often these "patches" are as large or larger than the entire NuttX
apps/ package. What would I do with all of this foreign code later?
Who would support that code? I can't.
2) In a few months, the forked code will be obsolete because no one
will be maintaining it. In a year it will be a useless. If there is no
on-going maintenance and synchronization with the application
repository, then the fork will be become obsolete very quickly.
The correct thing to do, really, is not to incorporate these large
applications into NuttX, but rather to incorporate NuttX support into
the application in the application's repository. That way, the code is
maintained and has a future direction. It would be better if Lua
supported NuttX, rather than NuttX supporting Lua. In the same way, it
would be better if Go supported NuttX rather than NuttX supporting Go.

Agree!

What happened to the Lua port? I put it here for now because I still
http://tech.groups.yahoo.com/group/nuttx/files/lua/
What can you do if the owners of the application repository are not
interested in supporting NuttX? Perhaps we can create our own project
that is a fork of other projects for NuttX. But that would be, I
think, a different project from NuttX with different administrators
and different maintainers. I would be happy to be a developer on that
project, but I cannot own those forks. That is much more than I am
able or willing to do myself.
I do not want to discourage you. Just the opposite. I want to
encourage you, but I simply do not know how to do that. I am open to
suggestions from other members of the group. If anyone wants to own a
project that consists of forks from other projects, I will help you
with that. Any ideas? suggestions?
This same topic comes up repeatedly. What is the solution?

There is really a requirement for this in the market, and there is still
no answer. Someone need take a try.
Thanks, I have got your thought.
--
Paul

--
Paul

[Paul.Y.Zhang]

Hi David, and Greg,

Thanks for your explanation, I got more info these days. Because i just
want to find a solution balanced between fast development and enought
running performance. I know, it's a tradeoff. Based on the past
discussions, it seems that Lua is the good solution. So, maybe, I need
spend sometime to study Lua and do some evaluation in future.

What about the status of Lua + Nuttx now? Does it work? What about its
maturity?

- Paul

Post by David Alessio
Hi Paul,
Good questions. Please see in-line responses below.
Regards,
-david
On Mon, Jan 7, 2013 at 6:40 PM, Paul.Y.Zhang
David,
Lua is a choice for improving the production efficiency. But, I
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=go
On the plus side, Lua offers much (from sockets, to RPC, to http
server with Ajax/Jason). Arguably its greatest offer to the Nuttx/MCU
space is that it's interpreted and fast, no compiler needed. For many
applications it can be the "glue logic" that ties together other
drivers (written in C).
Go is compiled. The benchmark is interesting, but a bit unfair. In
any case, Lua is tiny, flexible, and one of the fastest scripting
languages around (if not the fastest).
As for pasical, there is already C, why pasical?
pcode. pcode is smaller than C.
Anyway, it will be pretty to support some higher efficient
language to make the app development faster, than C. C is too low
level for complicated application. Lua, Go or something else, is
expected!
BTW, What's the difference between Lua an "eLua"?
Lua it "the" language target to run on POSIX OSs. eLua is a gallant
effort to support Lua on the bare metal of MCUs. The eLua team is
doing a great job, in particular with supporting event-driven
cooperative multitasking, but there remains a vast chasm between what
eLua can do on the bare metal and a full-blown MMU-based OS (QNX,
NetBSD, Linux). Where the MCU is capable, that gap can be filled by
Nuttx + Lua.

[Gregory Nutt]

Hi, Paul,

Post by Paul.Y.Zhang
As for pasical, there is already C, why pasical?

This is interpreted Pascal p-code.  The reason is because I wrote the p-code compiler a long time ago and decided to do something with it.  See http://tech.groups.yahoo.com/group/nuttx/message/245

Greg

[Gregory Nutt]

Hi, David,

This is the same approach that I used for the Forth interpreter (FICL) that can be found at apps/interpreters/ficl.  I did not automate the download, but other it is as you describe.

On of the problems with FICL, and possibly the other languages, is that having the interpreter in place is only half of the problem.  The other half is how do expose the interpreter in some way so that you can use it meaningfully.

Greg

Post by srd_128
At the risk of hijacking this subject (Google's GO on Nuttx), let me respond to a few of your comments with respect to Lua and its Nuttx patch.
Paul sees great potential in Go on Nuttx.  Mike, Darcy et al see great potential in Lua on Nuttx (I happen to also be in their camp as a longtime Lua user in embedded platforms).  What we all see is the great potential Nuttx has to host these powerful scripting languages and unlock the gate that has traditionally separated MCUs from the POSIX apps/tools developed on and for MMU-based OSs.
The work of integrating Lua has begun, has been demo'd, and it should be finished in a way that models how future 3rd party packages (scripting langs, etc.) could/should be handled.  Lua is not the first (Greg, you've already done great work in supporting Pascal), Lua won't be the last, but Lua is a great choice for today's MCUs and offers a treasure trove of libs and apps.  And it's a great choice to work out the challenges in paving that path.
1)  Download the Lua src version (5.1.4, 5.2.1, etc.)  This is easy to script with wget and drop a Makefile cookie.
2)  Untar the src into the Nuttx apps tree, drop a cookie.
3)  move and copy header files around with mv/cp in Makefile, drop a cookie.
4)  apply a patch to the resultant Lua src.  This patch contains only the edits to Lua source files necessary to compile that version of Lua for that version of Nuttx.
5)  compile/link the gestalt.
Step 4 is the key point.  The patch should contain only the delta from Lua-5.1.4 (let's say) to Lua-5.1.4-running-on-Nuttx.  Since both the Lua and Nuttx OS APIs are stable, this patch shouldn't be difficult for the community to modify (dare I say maintain?) as both Nuttx and Lua each evolve.  Given this baseline, it would be trivial to then create a similar patch for Lua-5.2.0 or Lua-5.2.1 (kdiff3 with a little oversight and done).
The same approach would work with Go.

[Michael Smith]

On of the problems with FICL, and possibly the other languages, is that having the interpreter in place is only half of the problem. The other half is how do expose the interpreter in some way so that you can use it meaningfully.

Both FICL and Lua are easily callable from user code. I include a wrapper command with the Lua patches that lets you call it from nsh as well. Beyond this, you're looking for an event framework of some sort, which is well out of bounds for NuttX and into application framework space, I think.

= Mike

[Paul.Y.Zhang]

Hi everyone,

Is there someone used lua with nuttx in real production? Is it
stable/robust enough for real application?

- Paul

[Paul.Y.Zhang]

Is there no one usiing lua with nuttx? Pardon me, I ask again.

- paul

Post by Paul.Y.Zhang
Hi everyone,
Is there someone used lua with nuttx in real production? Is it
stable/robust enough for real application?
- Paul

[Michael Smith]

Paul,

Last time I did anything with it, it was working OK. It ran most of the Lua 5.2 test suite (some tests edited to reduce memory consumption). Performance might be better using the granule allocator as Greg suggested.

I have not heard from anyone that's using my patches, so I don't have any more information for you.

= Mike

Post by Paul.Y.Zhang
Is there no one usiing lua with nuttx? Pardon me, I ask again.
- paul

Post by Paul.Y.Zhang
Hi everyone,
Is there someone used lua with nuttx in real production? Is it
stable/robust enough for real application?
- Paul

--
Paul

[Paul.Y.Zhang]

Mike, got it, thanks.

- Paul

Post by Michael Smith
Paul,
Last time I did anything with it, it was working OK. It ran most of
the Lua 5.2 test suite (some tests edited to reduce memory
consumption). Performance might be better using the granule allocator
as Greg suggested.
I have not heard from anyone that's using my patches, so I don't have
any more information for you.
= Mike

Post by Paul.Y.Zhang
Is there no one usiing lua with nuttx? Pardon me, I ask again.
- paul

Post by Paul.Y.Zhang
Hi everyone,
Is there someone used lua with nuttx in real production? Is it
stable/robust enough for real application?
- Paul

--
Paul

[Gong Darcy]

hi Paul.

Post by Paul.Y.Zhang
Hi, Greg, and other guys,
It seems unneccesary to support higher programing language now, but
please consider, suppose the mcu's speed become 1Ghz, SRAM become 1MB,
and application is too complex to C.

CPU>=1G SRAM>=1M ...

Why not consider port of Python? JavaScript V8 engine?

[Paul.Y.Zhang]

We should consider the performance, because Python/JS are all dynamic
type programing, so the performance is a problem.

- Paul

Post by Gong Darcy
hi Paul.
<mailto:yzhang.shanghai%40gmail.com>>

Post by Paul.Y.Zhang
Hi, Greg, and other guys,
It seems unneccesary to support higher programing language now, but
please consider, suppose the mcu's speed become 1Ghz, SRAM become 1MB,
and application is too complex to C.

CPU>=1G SRAM>=1M ...
Why not consider port of Python? JavaScript V8 engine?