Re: luac to create 32bit Lua byte code

[Tom Sutcliffe <tomsci@...>]

Hi Roger,

> On 30 Sep 2023, at 11:11, Roger Leigh <rleigh@codelibre.net> wrote:
> 
> I know this is anecdotal, but just as a datapoint, I have successfully run Lua code byte-compiled on Windows on an STM32.  The versions were matched, of course.  There may have been subtle defects, but I didn’t encounter them while testing if there were.

Yes I've made it work too (on a different embedded platform), but my point was more that it's a bad idea to rely on this working given there are no guarantees from Lua itself that it'll work, and it's an easy way to shoot yourself in the foot. I spent quite some time staring at hexdumps in a diff tool to reach that conclusion, after discovering one particular construct that wasn't the same size in the two environments I was using, even though nearly everything else was :-D My memory of the details are hazy and it may have been with an older Lua version, but as far as I know the lack of guarantee is the same in 5.4, even if the exact issue I was having is no longer present.

> Were one to do this properly, I would suggest running the compiler within an ARM emulator or simulator, such as qemu or C-Spy.  They support semihosting, which allows for host filesystem access, so that you have a convenient way of writing out the compiled bytecode, and reading in the Lua code to byte-compile.  This will ensure you are using the exact same Lua code on the same platform for both compiling and execution.

If you're using an SDK then that might provide you a cross-compile-supporting version of luac which does add those guarantees. For example NodeMCU builds a version called luac.cross specifically for you to use to compile bytecode targeting the esp32.

For all I know there might be an STM32 SDK out there which specifically ensures its bytecode format is the same as eg the 32-bit Windows LuaBinaries build, in the same way the Windows ABI adds additional guarantees about function pointer casts on top of what the C standard specifies. But unless it explicitly says that, it's only working by happy coincidence :D

Maybe I'm being excessively paranoid and it's a non-issue in practice for this particular combination of platforms. But I've been stung by this before, so I thought it was a pitfall that's worth being aware of.

Cheers,

Tom


>> On 29 Sep 2023, at 17:44, Tom Sutcliffe <tomsci@me.com> wrote:
>> 
>> It is very unlikely that the windows version of luac from something like LuaBinaries will produce bytecode that works on an STM32. As I said, Lua bytecode is not some sort of standard format that is compatible across different environments (except by happy coincidence or careful planning). You will have to use the Lua compiler from the STM32 SDK that produced the firmware that is running on your STM32, whatever that is.
>> 
>> This is starting to sound like a "how do I do STM32 development with SDK xyz on a Windows PC" question, which is not something I know anything about, and will also vary wildly depending on exactly what 'xyz' is :-)
>> 
>> Regards,
>> 
>> Tom
>> 
>>> On 29 Sep 2023, at 15:49, bil til <biltil52@gmail.com> wrote:
>>> 
>>> Thank you Tom
>>> 
>>> Just loading Lua 5.4 for Win32 really sounds like a good idea, then I
>>> hope luac54.exe there also the 32bit version.
>>> 
>>> My problem is, that I use Lua on my Windows 10 development PC for
>>> different applications:
>>> - for Windows c++ software as an "inlet script parser". This works
>>> fine - for this I do NOT need luac54.exe / no Lua bytecode needed.
>>> - for STM32 32bit microcontroller development. There I want to check
>>> bytecode load to controller, and to create this bytecode I need 32bit
>>> version of luac54. I will download the Win32 version of Lua and then
>>> check this luac54.exe from this download... .
>>> 
>>> ... it will need some time... I will report later