RiscLua

I play around last Days. I have “convert” any of my little basic programms to lua. It works. Lua remember me a little bit on the Pascal language.
On the examples I see where is read and write usable for in and out. But I not found this in the manual. Sorry, I lost the overview because I can not automatic search over the complete online manual. And additional my english is not so good.
Any mathematical function I found. A INT like in Basic not.
Is anywhere a short overview with the usable commands and funktions?
Next time I “play” a little bit more.
Many thanks.

Hello Raik,

I use (for normal Lua) one of these short references To be exact enrico’s original version at the bottom of this site. It seems not so cluttered than the others.
You could also ask questions about lua at arcsite or forum.acorn.de in german and I will try to answer these. I use Lua at work (sadly not RiscLua)

Up until recently the RiscLua application, !lua contained within it the standard Lua 5.2 manual in one big html file (!lua.doc.manual/html). That made looking up information slow and clumsy. So I have now split that up into four html files. Not as good as a StrongHelp manual, but slightly better than before.

You have to understand that RiscLua and Lua are not completely the same, especially when it comes to numbers. RiscLua uses 32-bit integers for its number type, for technical reasons to do with RISC OS, whereas standard Lua (usually) uses doubles, 64-bit floating point numbers. RiscLua also provides, in its bc library, arbitrary precision fixed-point numbers. So RiscLua does not have the standard libraries math and bit32. RiscLua has bit operations built into the virtual machine on the same footing as the arithmetic operations.

The documentation for RiscLua really needs the NetSurf browser – or at least a browser as capable with CSS. Doubleclick !lua to see it. It contains the standard Lua manual, plus extra bits to describe the parts of RiscLua that are not standard: the riscos, final, and bc libraries. There are also some tutorial parts to the documentation, in which example programs have pop-up tooltips to explain which words are variables (choosable by you) and which are reserved (not choosable by you) etc – but these will only work on browsers that are sufficiently modern. Not NetSurf yet, alas.

I am anxious to have as much feedback as possible to improve the documentation (mailto:gavin@wra1th.plus.com). The documentation and examples are evolving all the time, so you need to get the latest versions from http://lua.riscos.org.uk/ from time to time.

Raik might find http://www.wra1th.plus.com/lua/rlua_basic/contents.html of interest. It is a short comparison of BBC Basic and RiscLua on those parts which are fairly similar in syntax.

Many thanks to both.
I will change to arcside and I will check all of the documentation. It takes a little time…

RiscLua uses 32-bit integers for its number type, for technical reasons to do with RISC OS, whereas standard Lua (usually) uses doubles, 64-bit floating point numbers. RiscLua also provides, in its bc library, arbitrary precision fixed-point numbers.

I can see fixed point potentially being quicker, especially on older hardware where the FP was an emulation and not real hardware…

…however now that the ARM SoCs will usually have some sort of FP hardware on chip, I wonder if you had considered checking for the existence of VFP or NEON and switching to one of those instead of fixed point if the hardware is available?

Does Lua not have a hard distinction between real and int? I’m not sure I’d want all the overheads of dealing with an FP number for an array offset or a loop counter – surely that is more computationally expensive than it needs to be?

Standard Lua does not have a hard distinction between real and integer. That has been a problem for ports to some platforms (among which are the older RISC OS machines). For quite a while the Lua sources have abstracted the internal number type with a macro (LUA_NUMBER) which the implementor can set in luaconf.h; RiscLua sets it to 32-bit integers for the reasons Rick remarks on. The whole question of number typing, to coerce or not to coerce, is under current review I believe. There certainly used to be a belief that coercion was easier for non-programmers, which is why, I suspect, it was the choice adopted for Lua to begin with. However there is a growing belief that adopting coercion only stores up problems for future development – I think LuaJIT’s development was an example – so some people are thinking harder about how far along the road to strong-typing can you go with a dynamically typed language?

The advantage of the bc-number library for RiscLua is that its implementation is independent of hard-float provision. But if people need, say VFP on the RPi, or NEON on Cortex machines, then there will have to be special versions adapted for each.

But if people need, say VFP on the RPi, or NEON on Cortex machines, then there will have to be special versions adapted for each.

Why?

Look at any video transcoder on Windows (prob. X86 Linux too). The options are MMX, MMX2, SSE, SSE2, SSSE and several others I forget right now. At start-up, the code most likely has a jump table and it will probe to see what is available and set up branches accordingly.

Thus, to RISCLua. You could hold a branch table to the fixed point routines. If VFP is available, rewrite the table to VFP routines. If NEON, to NEON routines. In this way, the library will use the best of what’s on the available hardware. If you also indirect the routines to transfer data in and out of FP registers, you don’t even need to worry about what the internal format of a “single” or “double” looks like in the context of the rest of Lua…

There is another aspect of this, and I may have given the wrong impression by using the phrase fixed point incorrectly. It is important for the way the virtual machine uses a stack that the internal numbers be a datatype of constant size (4 bytes for RiscLua, 8 bytes for standard Lua). bc-numbers take up an indefinite number of bytes and so have to be allocated in the heap.

But I take your point that one could accommodate lots of different hard-floats in the one distribution.