RISC OS LUAJIT (1 Viewer)

[GavinW]

Alas I never managed to compile LuaJIT for RISC OS. I don't think there is any profound reason why not, as after all it is just a question of ARM32 assembler and ANSI C. But I found the instructions for compiling LuaJIT hurt my head and the tools were not available (why should they be?). It is a shame because LuaJIT would be really useful on RISC OS, where there is a dearth of alternatives to C for speedy programs. So help in this area would be much appreciated.

 

[dinsdale247]

So I have FreeBSD running on a beaglebone black. If I downloaded gcc and built LuaJIT, would that "just work'?

 

[GavinW]

I doubt it. The C-runtime systems that gcc compiles for, are they the same in RISC OS and FreeBSD? Surely not. The days when one loaded in machine code and simply jumped to an entry address are very long gone.In any case, I think ELF files contain a flag indicating what OS they are to run in, but how it is used by an OS I do not know. What do cross-compilers do about this?

 

[dinsdale247]

It looks like you're correct, that wouldn't work at all.

So I'm a dilettante, not an expert, but this is what I know: Compilers indicate the target by the "triplet". Typically architecture-platform-abi (Application Binary Interface), which could also be thought of as the standard library. So, I cross compile on FreeBSD for windows and use an llvm-mingw compiler: i686-w64-mingw32-gcc.

i686 - 32 bit intel
w64 - 64 bit windows
mingw32 - The mingw ABI
gcc - Mimics a gcc compiler front end

I do some embedded work and we use the GNU GCC variant arm-none-eabi-gcc
arm - Arm. :-/
none - no platform
eabi - embedded

The triplet isn't always three, and the "rules" get complicated. BUT, what happens is the compiler then knows what flags to use to create the binaries.

I looked on the RiscOS site (I fear being sucked into this awesome little project. I LOVE operating systems) and it seems they have their own compiler toolchain (RISC OS Open: Desktop Development Environment). I looked briefly at the "Building Images" page and there doesn't seem to be any cross build provisions.

So I think you would need to have a copy of the DDE on your RiscOS machine. LuaJIT uses a Makefile which is problematic. You would need to have a copy of GNU Make compiled to work on your RiscOS machine... Okay, maybe we are in luck. This site here seems to indicate a GCC Cross compile environment: SteveFryatt.org.uk » RISC OS » Build Tools...

Okay, I'm deep in the guts about creating a cross compiler (damn you!) and here is our triplet: arm-unknown-riscos-gcc. Very cool. It's getting late so I'll cut this post off here. I'll look into building a cross compiler but no promises, I have three kids and very little time on each thing that sucks me in.

GCCSDK - RISC OS

www.riscos.info

Using GCCSDK - RISC OS

www.riscos.info

Cross-compiling software with GCCSDK - RISC OS

www.riscos.info

 

[GavinW]

Well, RISC OS was designed for dilettantes. The OS consists of a kernel, plus independently replaceable modules (what an overloaded word that is!) which provide *commands and software interrupts, which user software can exploit. If you don't like the way something works, replace the relevant module with one of your own. That is the theory. Acorn envisaged that modules would be written in ARM assembler, but other languages are possible, and there is currently a move to rewrite as many modules as possible in C. I have even implemented Lua as a module.

It is great that you should be interested. My first microcomputer was an Acorn Atom, bought in 1979. This was followed by an Acorn BBC B, then an Archimedes. I have stuck with RISC OS ever since. My lazy excuse for not getting into other OSes was that one was enough. When I started compiling Lua for RISC OS, in 2002, I used the only C compiler then available (Norcroft, DDE). But a few years ago some talented RISC OS users began improving gcc for RISC OS and so I started to use that too (with particular thanks to Lee Noar). In fact, if you want to use hard floats and exploit VFP, Neon, etc, gcc is the only choice. I believe there has been some discussion about building RISC OS with gcc, but I suspect that there is still some way to go. It is only recently that RISC OS applications could use the ELF format. The old Acorn Image Format (AIF) does not cater for dynamic linking.

What I like most about RISC OS is the handiness of its GUI. I have the ROX-filer on my Raspbian machine, but sadly the ROX project, to bring the virtues of the RISC OS GUI to Linux, seems to have become abeyant, and is currently somewhat emasculated compared to earlier versions.

 

[dinsdale247]

I tried building GCCSDK last night on FreeBSD and it was a disaster. I launched it on my Linux PC at work and it was compiling without issue when I left. We shall see tomorrow.

The old Acorn Image Format (AIF) does not cater for dynamic linking.

And why would it if you were writing everything in assembly? Especially if there is no filesystem. A link library makes no sense; I think it's brilliant.

Anyway, you had me at "small niche operating system" with lots of history. I LOVE operating systems. While the story is not at the tip of my memory I do remember that Acorn was a pioneer in early computing.

I'm going to go geek out. Cheers!

 

[GavinW]

In that case I expect you browse OSNews. I always found Thom Holwerda's pieces interesting.

Have you come across linear logic? The linear lambda calculus does for operating systems what the ordinary one does for general programming - that is to say it restricts to resource-preserving algorithms. All a bit abstract, I am afraid. Operating systems are unlikely targets for professional experimentation, let alone for amateurs to play with, alas.

 

[dinsdale247]

The compiler built!


It's my mothers birthday tonight but I'll try and get LuaJIT to build asap.

 

[dinsdale247]

So here is the hocus-pocus you need to get it started:

make "HOST_CC=gcc -m32" "CROSS=arm-unknown-riscos-"

But it didn't go well.

[email protected] ~/l/LuaJIT-2.0.5> make "HOST_CC=gcc -m32" "CROSS=arm-unknown-riscos-"
==== Building LuaJIT 2.0.5 ====
make -C src
make[1]: Entering directory '/home/osboxes/lua/LuaJIT-2.0.5/src'
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
lj_arch.h:336:2: error: #error "Only ARM EABI or iOS 3.0+ ABI is supported"
HOSTCC    host/minilua.o
In file included from /usr/lib/gcc/x86_64-linux-gnu/9/include/limits.h:194,
                 from /usr/lib/gcc/x86_64-linux-gnu/9/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-gnu/9/include/limits.h:34,
                 from host/minilua.c:33:
/usr/include/limits.h:26:10: fatal error: bits/libc-header-start.h: No such file or directory
   26 | #include <bits/libc-header-start.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:665: host/minilua.o] Error 1
make[1]: Leaving directory '/home/osboxes/lua/LuaJIT-2.0.5/src'
make: *** [Makefile:110: default] Error 2
[email protected] ~/l/LuaJIT-2.0.5 [2]>

Question answered: no, it's not officially supported. I went rogue and hacked at the code a little and pushed things further by removing the error macro:

#if !(__ARM_EABI__ || LJ_TARGET_IOS)
//#error "Only ARM EABI or iOS 3.0+ ABI is supported"
#warning "****RIDEM' COWBOY!****"
#endif
#elif LJ_TARGET_PPC || LJ_TARGET_PPCSPE

For some reason minilua.c has to be 32bit, which forced me to install gcc-multilib (for the 32 bit library/headers). Once I did that, the files compiled but it failed on linking:

...
In file included from lib_init.c:16:0:
lj_arch.h:337:2: warning: #warning "****RIDEM' COWBOY!****" [-Wcpp]
AR        libluajit.a
CC        luajit.o
In file included from luajit.c:20:0:
lj_arch.h:337:2: warning: #warning "****RIDEM' COWBOY!****" [-Wcpp]
BUILDVM   jit/vmdef.lua
DYNLINK   libluajit.so
LINK      luajit
libluajit.a(lj_ir.o):(.rodata+0x1c0): undefined reference to `__aeabi_d2lz'
libluajit.a(lj_ir.o):(.rodata+0x1c8): undefined reference to `__aeabi_d2ulz'
libluajit.a(lj_ir.o):(.rodata+0x1d0): undefined reference to `__aeabi_f2lz'
libluajit.a(lj_ir.o):(.rodata+0x1d8): undefined reference to `__aeabi_f2ulz'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:685: luajit] Error 1
make[1]: Leaving directory '/home/osboxes/lua/LuaJIT-2.0.5/src'
make: *** [Makefile:110: default] Error 2

Soooo... ya. Now we are playing in the guts of the arm application binary interface (ABI). I looked up those library calls in arm documentation and they are very standard conversions, so I don't know why they would be missing? Unless those conversions are implemented in a different way by the RiscOS compiler? LuaJIT is very low level, that's how they get the raw speed. (No idea though, that's just me guessing).

Documentation – Arm Developer

developer.arm.com

Name and type signature	Description
int __aeabi_d2iz(double)	double to integer C-style conversion [3]
unsigned __aeabi_d2uiz(double)	double to unsigned C-style conversion [3]
long long __aeabi_d2lz(double)	double to long long C-style conversion [3]
unsigned long long __aeabi_d2ulz(double)	double to unsigned long long C-style conversion [3]
int __aeabi_f2iz(float)	float (single precision) to integer C-style conversion [3]
unsigned __aeabi_f2uiz(float)	float (single precision) to unsigned C-style conversion [3]
long long __aeabi_f2lz(float)	float (single precision) to long long C-style conversion [3]
unsigned long long __aeabi_f2ulz(float)	float to unsigned long long C-style conversion [3]

Anyway, at that point I'm starting to get pretty far out of my depth. If you really wanted LuaJIT to happen, you'd have to strike up a conversation with the RiscOS GCCSDK team and maybe even the LuaJIT community. This isn't an impossible hurdle, but it requires "stick handling" and time that I don't have.

On a related note, I just freed up a 4 gb SD card for my beaglebone black. I should be able to flash it with RiscOS soon.

OMG. so tired. zzzzzzzzzzzz

 

[GavinW]

Many thanks for your heroic efforts. Floating point was always a weak point for Acorn. Early ARM CPUs simply did not have it. RISC OS does not use it, I think. So matters like saving and restoring FP contexts are murky corners. By contrast gcc is super finicky on these things. Compilers need to be, even when the software they produce have no need for it.

Incidentally, my recent attempts to use gcc keep producing the error File 'uname' not found.It is probably down to my ineptitude using gnu make.

 

[dinsdale247]

Many thanks for your heroic efforts.

Heroic is maintaining a Lua distribution on a platform nobody has ever heard of. It is I that thank you with a tiny token of effort.

Floating point was always a weak point for Acorn. Early ARM CPUs simply did not have it. RISC OS does not use it, I think. So matters like saving and restoring FP contexts are murky corners. By contrast gcc is super finicky on these things. Compilers need to be, even when the software they produce have no need for it.

Incidentally, my recent attempts to use gcc keep producing the error File 'uname' not found.It is probably down to my ineptitude using gnu make.

I dislike make[1]; or rather, make dislikes me. If you give some context we might be able to help? uname is the posix command that outputs OS information. Here is the FreeBSD man reference: uname . Note at the bottom:

STANDARDS
The uname command is expected to conform to the IEEE Std 1003.2
("POSIX.2") specification.

[1] I dislike everything. As I learn more build systems, I begrudgingly put up with the abrasive friend that is `make`.

 

[GavinW]

RISC OS uses '.' as directory separator symbol. So anybody translating between Unix and RISC OS filenaming is faced with certain problems. The usual, and simplest arrangement, is simply to exchange the symbols '.' and '/'. So change foo.c to foo/c. However, back in the mists of Acorn's early days, some bright spark decided to write foo.c as c.foo, so that if you are using the Norcroft C compiler you expect to have directories c, h, o and s if you have some assembler sources. I think gcc will cope with both styles of translation, but I am not sure about make. Norcroft had their own version of make called amu. One of my favourite text books is Aho, Kernighan and Weinberger's The AWK Programming Language. Section 7.4 is a minimal make program written in AWK, stripped of all the grotesque accretions that it has gathered over the decades.

I gather that in Unix make expects to use uname to find out more about the platform. I cannot see any corresponding command in RISC OS. However, I have used gcc and make successfully in the past, without the uname complaint. Maybe the makefile I am using is not complete.

 

[dinsdale247]

RISC OS uses '.' as directory separator symbol. So anybody translating between Unix and RISC OS filenaming is faced with certain problems. The usual, and simplest arrangement, is simply to exchange the symbols '.' and '/'. So change foo.c to foo/c. However, back in the mists of Acorn's early days, some bright spark decided to write foo.c as c.foo, so that if you are using the Norcroft C compiler you expect to have directories c, h, o and s if you have some assembler sources. I think gcc will cope with both styles of translation, but I am not sure about make. Norcroft had their own version of make called amu. One of my favourite text books is Aho, Kernighan and Weinberger's The AWK Programming Language. Section 7.4 is a minimal make program written in AWK, stripped of all the grotesque accretions that it has gathered over the decades.

I gather that in Unix make expects to use uname to find out more about the platform. I cannot see any corresponding command in RISC OS. However, I have used gcc and make successfully in the past, without the uname complaint. Maybe the makefile I am using is not complete.

hmmm... I don't think make has any requirement for uname? Could your makefile be including another file that DOES use uname? Or perhaps it's running a configuration script. Sometimes if the win32 symbol is not present people assume unix and would call uname to determine mac/linux/bsd platforms.

You could always mimic uname by creating a "program" that returns the riscOS information?

[email protected] /u/h/russellh> uname
FreeBSD

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

Loading personal and system profiles took 622ms.
C:\Users\russh> bash

[email protected] MINGW64 ~
$ uname
MINGW64_NT-10.0-18363

 

[GavinW]

A friend has pointed out where uname appears in the makefile. It comes in a swathe of stuff to determine what platform is being used, so I can simply comment it all out and insert the answer. This exposes the next layer of the problem for me: the confusion caused by the overlapping of contradictory solutions to the problem of converting Unix filenaming conventions with RISC OS ones. You see, the RISC OS directory separator symbol is a period '.'. RISC OS has a filetype attribute that is not part of a file's name, so has no use for extensions. The logical solution is to interchange '.' and '/' in translating back and forth between Unix and RISC OS filepaths. That would be fine, except for a decision made long ago by those writing C compilers for Acorn, to interpret the extensions c,h,o,s,... as directories. Thus the Unix foo.c becomes the RISC OS c.foo. This works OK so long as the makefile used refers only to stuff in a single directory, which LuaJIT's makefile does not. I suspect that, to get LuaJIT to compile with the GNU make that I am lumbered with, I shall have to do some wholesale renaming of the source files, and put them in a different directory structure. A messy kludge. I wrote a comment on the ROOL forum about it: Abuse of Filenaming and Portability .