Build Lua with only integer numbers

[Phil Leblanc]

Hi all,

I would like to build Lua with only support for Integer numbers
(32-bit or 64-bit).

I think it used to be possible, but I am not sure.  Is it still
possible today with Lua 5.3+  (since Lua supports an Integer subtype)?

I tried to look at luaconf.h and see how to build with various sizes
of integers and floats but I don't understand how I could build it
without floats (only integers).

Any suggestions or pointers?   Thanks in advance.

Phil

[Egor Skriptunoff-2]

On Fri, Apr 2, 2021 at 1:51 AM Phil Leblanc wrote:

I would like to build Lua 5.3+ with only support for Integer numbers

Is it a 1-April question?

Sorry, I'm answering from another timezone, your letter has arrived on April 2nd :-)

It's not clear, what would be the difference between Lua 5.3 and "integers-only Lua 5.3"?

Even if FP are emulated in software on your system, the C compiler does have FP datatype anyway.

So, just avoid using FP literals/operators/functions in Lua scripts if FP operations are CPU-intensive.

Or your main goal is to warn a user by generating a compile time error?

[Luiz Henrique de Figueiredo]

> I would like to build Lua with only support for Integer numbers

See this thread: http://lua-users.org/lists/lua-l/2015-10/msg00255.html

[Gavin Wraith]

In message <[hidden email]>
          Egor Skriptunoff <[hidden email]> wrote:

>On Fri, Apr 2, 2021 at 1:51 AM Phil Leblanc wrote:
>
>> I would like to build Lua 5.3+ with only support for Integer numbers

Has Phil Leblanc seen Vicente's No Floating-Point Option for Lua 5.3
at http://lua-users.org/wiki/LuaPowerPatches ?

I built a version of Lua 5.3.5 for RISC OS  with no floating point numbers
but with the imath library to provide big integers. It has two integer types
'int32' (32-bit integers) and 'integer' (arbitrary size), informally 'small'
and 'big'. The function 'type' is redefined, and the metatable of the imath
library is given a key __type = "integer" .  A function imath.$ converts
small integers to big ones, and the values $0, ... , $9 are predefined in
a prelude.

For example:

print ($2^($2^10))  -->
179769313486231590772930519078902473361797697894230657273430081157732675805500
963132708477322407536021120113879871393357658789768814416622492847430639474124
377767893424865485276302219601246094119453082952085005768838150682342462881473
913110540827237163350510684586298239947245938479716304835356329624224137216


--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

[Phil Leblanc]

On Fri, Apr 2, 2021 at 10:28 AM Egor Skriptunoff
<[hidden email]> wrote:

>> I would like to build Lua 5.3+ with only support for Integer numbers
>
> Is it a 1-April question?

No, not an Aprill Fool's question! Although I did post on April 1st.
Sorry for the confusion :-)

> It's not clear, what would be the difference between Lua 5.3 and "integers-only Lua 5.3"?
>
> Even if FP are emulated in software on your system, the C compiler does have FP datatype anyway.
> So, just avoid using FP literals/operators/functions in Lua scripts if FP operations are CPU-intensive.

This is a fair point. My goal is to find whether Lua would be a good
fit for a MCU environment with limited RAM and no FP support, and
whether Lua with only Integers as numbers would have better
performance and be less RAM-hungry than a vanilla Lua.

To find out, I guess the best way would be to test. I vaguely
remembered some macros magic in Lua 5.1 days to build a Lua with only
integer numbers. I didn't see how to do it with Lua 5.3+ luaconf.h so
I thought I would ask.

Phil

[Spar]

Take a look at ELua project, they aim at microcontroller architectures

On 2 Apr 2021, 22:24 +0300, Phil Leblanc <[hidden email]>, wrote:

On Fri, Apr 2, 2021 at 10:28 AM Egor Skriptunoff
<[hidden email]> wrote:

I would like to build Lua 5.3+ with only support for Integer numbers

Is it a 1-April question?

No, not an Aprill Fool's question! Although I did post on April 1st.
Sorry for the confusion :-)

It's not clear, what would be the difference between Lua 5.3 and "integers-only Lua 5.3"?

Even if FP are emulated in software on your system, the C compiler does have FP datatype anyway.
So, just avoid using FP literals/operators/functions in Lua scripts if FP operations are CPU-intensive.

This is a fair point. My goal is to find whether Lua would be a good
fit for a MCU environment with limited RAM and no FP support, and
whether Lua with only Integers as numbers would have better
performance and be less RAM-hungry than a vanilla Lua.

To find out, I guess the best way would be to test. I vaguely
remembered some macros magic in Lua 5.1 days to build a Lua with only
integer numbers. I didn't see how to do it with Lua 5.3+ luaconf.h so
I thought I would ask.

Phil

[BogdanM]

eLua uses Lua 5.1 only. I did run Lua 5.3 on a couple of Cortex MCUs, but didn't attempt to port the int-only patches, as those MCUs had enough resources to run the full version.

On Fri, Apr 2, 2021 at 10:26 PM Spar <[hidden email]> wrote:

Take a look at ELua project, they aim at microcontroller architectures

On 2 Apr 2021, 22:24 +0300, Phil Leblanc <[hidden email]>, wrote:

On Fri, Apr 2, 2021 at 10:28 AM Egor Skriptunoff
<[hidden email]> wrote:

I would like to build Lua 5.3+ with only support for Integer numbers

Is it a 1-April question?

No, not an Aprill Fool's question! Although I did post on April 1st.
Sorry for the confusion :-)

It's not clear, what would be the difference between Lua 5.3 and "integers-only Lua 5.3"?

Even if FP are emulated in software on your system, the C compiler does have FP datatype anyway.
So, just avoid using FP literals/operators/functions in Lua scripts if FP operations are CPU-intensive.

This is a fair point. My goal is to find whether Lua would be a good
fit for a MCU environment with limited RAM and no FP support, and
whether Lua with only Integers as numbers would have better
performance and be less RAM-hungry than a vanilla Lua.

To find out, I guess the best way would be to test. I vaguely
remembered some macros magic in Lua 5.1 days to build a Lua with only
integer numbers. I didn't see how to do it with Lua 5.3+ luaconf.h so
I thought I would ask.

Phil

[Phil Leblanc]

On Fri, Apr 2, 2021 at 10:31 AM Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> See this thread: http://lua-users.org/lists/lua-l/2015-10/msg00255.html

Thanks for the great link. I read the thread and I will at least try
Roberto's suggestion in post [1]
[1] http://lua-users.org/lists/lua-l/2015-10/msg00321.html

I am wondering,  was removing the "number type selection macros" (or
rather limiting them to float vs double if I get it right) a decision
of the Lua team because of the increased complexity of Lua 5.3?  or
was it a decision to "give up" MCus as a potential target and focus on
larger and more "modern" platforms (x86, ARM)?

Phil

[Phil Leblanc]

On Fri, Apr 2, 2021 at 7:26 PM Spar <[hidden email]> wrote:
>
> Take a look at ELua project, they aim at microcontroller architectures
> On 2 Apr 2021, 22:24 +0300, Phil Leblanc <[hidden email]>, wrote:

Thanks. Yes I have looked at eLua, and also at NodeMCU.

AFAIK, NodeMCU has a Lua5.3 version. But I don't know yet if this is a
vanilla Lua, with respect to numbers.

Phil

[Phil Leblanc]

On Fri, Apr 2, 2021 at 7:34 PM Bogdan Marinescu
<[hidden email]> wrote:
>
> eLua uses Lua 5.1 only. I did run Lua 5.3 on a couple of Cortex MCUs, but didn't attempt to port the int-only patches, as those MCUs had enough resources to run the full version.

I was a big fan of eLua, although I had at the time no opportunity to
contribute.

Is the project dead/asleep, nowadays?

A target I am interested in is the new Raspberry Pi Pico.  The MCU is
a Cortex M0+ with no FP support, and with 260 KB on-chip RAM.

The Raspberry foundation proposes MicroPython as an on-board scripting
option. I am certain that Lua aficionados would love to see Lua as an
alternative option for this nice board!

A recent Lua (5.3+) might be a bit big or RAM-hungry for many
Arduino-like devices, but I think would be the best fit for the Pico.

Phil

[BogdanM]

Hi,

On Fri, Apr 2, 2021 at 11:06 PM Phil Leblanc <[hidden email]> wrote:

On Fri, Apr 2, 2021 at 7:34 PM Bogdan Marinescu
<[hidden email]> wrote:
>
> eLua uses Lua 5.1 only. I did run Lua 5.3 on a couple of Cortex MCUs, but didn't attempt to port the int-only patches, as those MCUs had enough resources to run the full version.

I was a big fan of eLua, although I had at the time no opportunity to
contribute.

Is the project dead/asleep, nowadays?

It's in (low) maintenance-only mode, not actively developed anymore. I am working with Lua (5.3) in a different embedded project, but one which is not backward compatible with eLua. It targets MCUs with more resources, but it's better in any other way than I can think of. I might be able to open source it one day.

 

A target I am interested in is the new Raspberry Pi Pico.  The MCU is
a Cortex M0+ with no FP support, and with 260 KB on-chip RAM.

260KB on-chip RAM is good enough for a lot of use cases. The project that I mentioned above starts vanilla Lua 5.3 with some supporting Lua code (including a coroutine scheduler) in ~70KB of RAM IIRC. You should have enough room to play with Lua in the remaining RAM. The lack of an FPU will impact your speed, but should have very little to no impact of the RAM usage. And running vanilla Lua has obvious benefits, although I do wish that the Lua team would look more closely to MCU-specific use cases. Maintaing patches between various Lua versions can be a very frustrating experience. At the same time, I understand that MCU-specific use cases are somtimes at odds with Lua's excellent cross-platform portability.

 

The Raspberry foundation proposes MicroPython as an on-board scripting
option. I am certain that Lua aficionados would love to see Lua as an
alternative option for this nice board!

A recent Lua (5.3+) might be a bit big or RAM-hungry for many
Arduino-like devices, but I think would be the best fit for the Pico.

I think so too. While targetting smaller MCUs have been my goal for a long time, that goal doesn't seem that useful anymore. More and more MCUs have more than 200K of on-chip SRAM, the one that I'm using right now has 512K and I've seen parts with 1M (I think they use one of those on the Arduino Potenta). The transition to parts with larger RAM isn't very fast, but it's happening and will likely be accelerated by the current "Edge AI on MCUs" trend. Things are looking good.

 

Phil

[Roberto Ierusalimschy]

> I am wondering,  was removing the "number type selection macros" (or
> rather limiting them to float vs double if I get it right) a decision
> of the Lua team because of the increased complexity of Lua 5.3?  or
> was it a decision to "give up" MCus as a potential target and focus on
> larger and more "modern" platforms (x86, ARM)?

What do you mean by 'removing the "number type selection macros"'?

-- Roberto

[Phil Leblanc]

On Fri, Apr 2, 2021 at 11:14 PM Roberto Ierusalimschy
<[hidden email]> wrote:
>
> > I am wondering,  was removing the "number type selection macros" (or
> > rather limiting them to float vs double if I get it right) a decision
> > of the Lua team because of the increased complexity of Lua 5.3?  or
> > was it a decision to "give up" MCus as a potential target and focus on
> > larger and more "modern" platforms (x86, ARM)?
>
> What do you mean by 'removing the "number type selection macros"'?

What I mean by 'removing "number type selection macros" (or rather
limiting them to float vs double if I get it right)" ' is the
following:

My (limited) understanding at the moment is that it was possible to
build Lua5.1 with numbers being either floats or integers only by
changing a few macros in luaconf.h, and that it is no longer possible
to do this with Lua 5.3+:

   Lua5.1/luaconf.h:  @@ LUA_NUMBER is the type of numbers in Lua.

   Lua5.4/luaconf.h:  @@ LUA_NUMBER is the floating-point type used by Lua.

Thanks to the link kindly provided by Luiz, I read your suggestion on
the list in 2015 [1] but didn't have time to test it. -- [1]
http://lua-users.org/lists/lua-l/2015-10/msg00321.html

So, maybe I am wrong on this, and just by editing a few #define in
luaconf.h it is possible to build a Lua where all numbers are
integers, and my question is moot.

If not, I guess my question boils down to: do you consider that
building Lua without floats is now out of scope for the Lua team?

Hope it was more clear,

Phil

[Jorge Visca]

For completeness, there's also Lua-RTOS-ESP32, which uses Lua 5.3 and
supports ESP32, ESP8266 and PIC32MZ.

https://github.com/whitecatboard/Lua-RTOS-ESP32


Jorge


On 4/2/21 4:40 PM, Phil Leblanc wrote:
> On Fri, Apr 2, 2021 at 7:26 PM Spar <[hidden email]> wrote:
>> Take a look at ELua project, they aim at microcontroller architectures
>> On 2 Apr 2021, 22:24 +0300, Phil Leblanc <[hidden email]>, wrote:
> Thanks. Yes I have looked at eLua, and also at NodeMCU.
>
> AFAIK, NodeMCU has a Lua5.3 version. But I don't know yet if this is a
> vanilla Lua, with respect to numbers.
>
> Phil

[Phil Leblanc]

On Mon, Apr 5, 2021 at 5:04 PM Jorge <[hidden email]> wrote:
>
> For completeness, there's also Lua-RTOS-ESP32, which uses Lua 5.3 and
> supports ESP32, ESP8266 and PIC32MZ.
>
> https://github.com/whitecatboard/Lua-RTOS-ESP32

I didn't know about this project. Thanks for the link!

Phil

[Roberto Ierusalimschy]

> So, maybe I am wrong on this, and just by editing a few #define in
> luaconf.h it is possible to build a Lua where all numbers are
> integers, and my question is moot.
>
> If not, I guess my question boils down to: do you consider that
> building Lua without floats is now out of scope for the Lua team?

The current status quo is as it was. *Allowing* Lua to be built without
floats is (as it has been for a long time) in our scope, but actually
building Lua without floats is (as it always was) out of our scope.

-- Roberto

[Phil Leblanc]

On Mon, Apr 5, 2021 at 5:42 PM Roberto Ierusalimschy
<[hidden email]> wrote:
>
> The current status quo is as it was. *Allowing* Lua to be built without
> floats is (as it has been for a long time) in our scope, but actually
> building Lua without floats is (as it always was) out of our scope.

Okay, thanks.

Phil

> -- Roberto