Linux Port

Which makes me want to ask the question: how do I tell the Linux port of RISC OS to use more than 16 MB memory?

Even I was puzzled by that at the weekend. Edit line 4579 of castle/RiscOS/Sources/Kernel/s/ChangeDyn. I think I will change that to 1GB

Interesting.. the max wimpslot is 16MB. However starting an app with 16MB yields 16MB free.

No, it will happily allocate a wimpslot to 2GB from the command line, which is a bug as there is only 512MB-32K address space for it to fit in. It’s only the Taskmanager user interface that is so limited.

As for performance, I have some changes that make ROM builds about twice as fast. I measured 36,692,221 RISC OS SWI calls in an IOMD ROM build, each taking about 6 microseconds. So I have paravirtualised most of the SWI instructions in the Kernel, Fileswitch and the shared C library reducing that count to 442,550.

Now, according to perf, it’s spending 42% of it’s time in v7_coherent_kern_range in Linux. This is not entirely explained by the 19696 calls to OS_SynchroniseCodeArea requesting a full sync.

I can conform that StrongEd 4.69f9 works provided you extract it from the zip file. It crashes if Filer booted from the distribution zip file using SparkFS. It also crashes if you try to load it’s own wimpslot.

This is not entirely explained by the 19696 calls to OS_SynchroniseCodeArea requesting a full sync.

That’s a lot of full syncs. Have you done any analysis on where they’re coming from? OS_FSControl for example does a full sync after loading an Absolute or addressed code, instead of just the affected range.

I had a lot of performance issues in ADFFS around OS_SynchroniseCodeArea full syncs, in the end I had to ignore them as they were killing JIT performance¹ unnecessarily. OS_FSControl was in the end paravirtualized and now doesn’t perform a full cache flush.

¹ A full cache flush requires code already interpreted by the JIT to be dropped along with any associated codelets.

That’s a lot of full syncs. Have you done any analysis on where they’re coming from? OS_FSControl for example does a full sync after loading an Absolute or addressed code, instead of just the affected range.

That shouldn’t be too tricky to fix; it should be able to skip the call if the service call wasn’t claimed, and although it won’t know the exact range of memory that the service call altered it can at least limit it to within application space.

I did a grep on todays source tar (22-02-17) and turned up the following full syncs:

/FileSys/FileSwitch/s/FSControl
/HWSupport/Podule/s/Interface
/Lib/RISC_OSLib/kernel/s/k_body
/Lib/RISC_OSLib/s/initmodule
/Lib/RISC_OSLib/s/overmgr
/Programmer/BASIC/s/Assembler
/Utilities/Patches/Patch/s/UnSqueeze #1
/Utilities/Patches/Patch/s/UnSqueeze #2

Some even state the programmer was too lazy to narrow down the address range.

I added one of syncs in OS_FSControl, and am working on removing them.

The full syncs are all OS_FSControl and CLib then?

I added one of syncs in OS_FSControl, and am working on removing them.

I removed them completely from OS_FSControl, which I could get away with as I don’t support StrongARM code patching, the JIT being ARM3. I instead sync in the MemCopy routine (covers code coming direct from a floppy image) and OS_File etc sync any areas they touch. A JIT’s syncing requirements are a lot more rigid than a CPU though, as data is always in the cache unless explicitly removed – you can think of the JIT’s memory range as one huge cache with no replacement policy.

If I understand the documentation correctly, OS_FSControl shouldn’t need to do a final sync as its the responsibility of the SA patcher to sync anything it’s patched. If there’s no claim of the decompression stage it should sync the range code was loaded into.

Full syncs should rarely be necessary in the OS, possibly only once when the cache is enabled during POST; I expect most if not all of those listed above could be ranged. The decision to do a full sync should be left to the ARMOps which can determine if ranged or full is quicker/required on the platform it’s running on.

Jan Rinze, with respect to the problem you had building it are the C library stubs not located at exactly AcornC.C++/Libraries/CLib/o/stubs,ffd ?

Has ROOL moved them since DDE 24?

I have not looked into this Linux project at all so forgive me if there’s a setup script moving files around… but there is no “Libraries” directory in DDE 27, and I don’t recall one in 25 either. The “stubs” file is in AcornC.C++/Export/APCS-32/Lib/CLib/o.

Timothy is quite right about the location in DDE24 for the stubs file.

The DDE had various re-arrangements in that period and since with various macros files for example moving or plain disappearing. The Original NutPi DDE and the full DDE 24 for example have different layouts and from descriptions on the forums the DDE25 was different again.

I’ve uploaded changes to my Makefile which should work with either AcornC.C++/Export/APCS-32/Lib/CLib/o/stubs and AcornC.C++/Libraries/CLib/o/stubs.

I have also changed it to be case insensitive and work with or without filetype suffixes.

git clone https://github.com/TimothyEBaldwin/RISC_OS_Dev.git
cd RISC_OS_Dev
git checkout Linux

This part will get me the proper tree from your git repo.
However it assumes Acorn C++ in ../DDE and some linux kernel tree elsewhere.
Then it assumes kernel 4.9 and uses the headerfile from that.
So I had to setup some tricks to go around the assumptions.

(Textile is quite stubborn when it needs to do verbatim text..)

make ACORN_CPP=../DDE/AcornC.C++ check
rm "Images/Linux_rom" || true
find * -depth -exec ./comma2attr -- '{}' + 9<../DDE/AcornC.C++ || true
RISC_OS_Alias_IXFSBoot='Exec IXFS:$.dev.fd.4'  mixed/Linux/Support/RISC_OS --nofork \
8<. 9<'../DDE/AcornC.C++' 4< <(
echo '*BASIC
*FX 3 2
*Dir IXFS:$.dev.fd.8
PRINT TIME$
TIME$="Sat,25 Feb 2017.13:57:06"
QUIT
*Obey -c mixed.Linux.Support.Build Linux Linux export_hdrs export_libs resources rom install_rom join
' )
chmod +x "Images/Linux_rom"
ln -f Images/Linux_rom RISC_OS || true
rm: cannot remove 'Images/Linux_rom': No such file or directory
Hello World
...............
...............
15 of 15 interrupts counted.
Starting kernel...
H

And it remains sitting there with the cursor.
So the checkout from feb 18th I can build but need to investigate what is going on with the latest commits.

apparently commit c75a9ae833a4d38bec80e655f372508038c408e0 broke building on my ARMLinux machine.

The RISC_OS binary in github used to run Acorn binaries under Linux apparently no longer is compatible with my system. Not sure what changed.

And it remains sitting there with the cursor.

I’m seeing the same hang with ARM linux. (debian Jessie)

Still works OK with QEmu on Intel Linux. (debian Stretch)

I also tried it on a Chromebook (debian Jessie) which has an aarch64 kernel but it doesn’t recognize ‘RISC_OS’ as being a valid executable.

After replacing with the older RISC_OS binary it still never creates a valid LinuxSyscalls header file or can find where it is located. So the makefiles are not yet in a state where it can be built ‘out-of-the-box’.

 HAL_Linux (mixed.Linux.HAL)...
objasm -depend !Depend    -g -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"Linux\"" -pd "UserIF SETS \"Sovereign\"" -APCS 3/nofp/noswst -pd "ro_size * 0x33004000 - 0x33000000" -o o.Tests s.Tests
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: File "Hdr:LinuxSyscalls" could not be opened
Error: Bad GET or INCLUDE at line 33 in file s.Tests
   33 00000000         GET     Hdr:LinuxSyscalls
Assembly terminated: 
2 Errors, 0 Warnings
AMU: *** exit (1) ***

objasm -depend !Depend    -g -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"Linux\"" -pd "UserIF SETS \"Sovereign\"" -APCS 3/nofp/noswst -pd "ro_size * 0x33004000 - 0x33000000" -o o.Top s.Top
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: File "Hdr:LinuxSyscalls" could not be opened
Error: Bad GET or INCLUDE at line 36 in file s.Top
   36 00000000         GET     Hdr:LinuxSyscalls
Assembly terminated: 
2 Errors, 0 Warnings
AMU: *** exit (1) ***

Also since the complexity and dependencies in the makefiles are so big it’s almost not traceable how or why things get built or fail to build.

Most large projects I know of build in sequence using make -C ./module/submodule and have a config.mk to ensure that all can be found properly while building. But here it’s all a bit of a mixed bag.

Ofcourse the RISC OS build tree by itself is already quite complex. So I am not sure (yet) how to fix the issue properly. I manually copy the LinuxSyscalls header file to a directory hoping that the build will continue..

LinuxSyscalls (mixed.Linux.Syscalls)...
%link -Output gen_header o.gen_header C:o.stubs_bootstrap
ARM Linker: (Fatal) File C:o.stubs_bootstrap not found.
AMU: *** exit (1) ***

It seems that stubs_bootstrap is really not something known to this build. I manually added a link to stubs and then it builds but I am not sure if that is what is intended.

find ./ -name stubs_bootstrap
./Export/APCS-32/Lib/CLib/o/stubs_bootstrap

ls -al ./Export/APCS-32/Lib/CLib/o/stubs_bootstrap
lrwxrwxrwx 1 janrinze janrinze 42 Feb 25 15:45 ./Export/APCS-32/Lib/CLib/o/stubs_bootstrap -> /proc/self/fd/9/Libraries/CLib/o/stubs,ffd

ls -al ./Export/APCS-32/Lib/CLib/o/*
-rwxrwxr-x 1 janrinze janrinze 173896 Feb 25 15:53 ./Export/APCS-32/Lib/CLib/o/ansilib
-rwxrwxr-x 1 janrinze janrinze 176460 Feb 25 15:53 ./Export/APCS-32/Lib/CLib/o/ansilibm
-rwxrwxr-x 1 janrinze janrinze  40048 Feb 25 15:53 ./Export/APCS-32/Lib/CLib/o/stubs
lrwxrwxrwx 1 janrinze janrinze     42 Feb 25 15:45 ./Export/APCS-32/Lib/CLib/o/stubs_bootstrap -> /proc/self/fd/9/Libraries/CLib/o/stubs,ffd

here it has a link to a very unusual /proc/self/.. which really should not be used.
Also stubs has no ,ffd extension.

ls -al ./Export/APCS-32/Lib/CLib/o/
total 396
drwxrwxr-x 2 janrinze janrinze   4096 Feb 25 17:17 .
drwxrwxr-x 4 janrinze janrinze   4096 Feb 25 15:52 ..
-rwxrwxr-x 1 janrinze janrinze 173896 Feb 25 15:53 ansilib
-rwxrwxr-x 1 janrinze janrinze 176460 Feb 25 15:53 ansilibm
-rwxrwxr-x 1 janrinze janrinze  40048 Feb 25 15:53 stubs
lrwxrwxrwx 1 janrinze janrinze      5 Feb 25 17:17 stubs_bootstrap -> stubs

Above is how I think it should look like and what makes the build work.

LinuxSyscalls (mixed.Linux.Syscalls)...
GNU.diff <Export$Dir>.LinuxSyscalls LinuxSyscalls
AMU: *** Parameters not recognised ***

If "<AMU$ReturnCode>" <> "0" Then copy  LinuxSyscalls <Export$Dir>.LinuxSyscalls FR~C~VN
LinuxSyscalls header export complete

Above a hint why the headers and LinuxSyscalls don’t get installed or built properly.

This tries to outsmart makefiles by using diff on files to see if they changed. Makefiles have dependencies to ensure newer files so we should use that instead.

Lastly:

g++: error: unrecognized command line option ‘--std=c++14’

I wonder if c++14 is really necessary to build this.

On a side note:
Once built, I can now run !Zap. That one ran into a data abort but the data abort now is properly handled within RISC OS.

I am very very impressed with all the results so far!

Netsurf starts, no network yet of course but this looks really promising.
Rpcemu backend for networking looks like a good candidate to implement a network interface.

I wonder if c++14 is really necessary to build this.

It works fine with C++11 mode.

We should start at the beginning and ask why “stubs_bootstrap” is not a functioning link.

Several symbolic links to /proc/self/fd/9/… are created by the make target “stamp-prepare” at the mixed/Linux/Support/build.mk, clearly most of them work as the the build partially works.

I can not imagine how the current Makefile (2e0830ecc3c2934552ea9a21d5fa933ccb129c39) could create a broken link, was it left over from a previous attempt? I have just noticed that I have omitted a wildcard so that it only matches Export/APCS-32/Lib/CLib/o/stubs without a filetype suffix or Libraries/CLib/o/stubs with or without a suffix. I have uploaded a fix for that.

The failure goes as follows:

1. A C program “gen_header” is compiled.
2. It is linked with stubs_bootstrap
3. Which then produces LinuxSyscalls
4. Which is copied if it has changed (error from diff expected)
5. Which is then included in HAL, Kernel and PortableHAL.

Shall I just delete it and replace it with it’s output? It only used as a list Linux system call numbers in ObjAsm format, though I was planning on other things for it.

a link to a very unusual /proc/self/.. which really should not be used.

I used links to /proc/self/fd/.. to prevent one accidental copying the DDE somewhere in violation of it’s licence, I did not want the warning and question ROOL’s InstallTools obey file uses, nor consider it appropriate just to omit the question.

@Jan: That whole thing looks really promising, as I really like prototyping stuff in GLSL and still use Risc OS Basic to play around.

Do pages like Shadertoy work under Linux ?

…and at the same time one can run Basic stuff windowd like my old benchmarks run on Risc OS, see link here ?

@Kuemmel: Yes Shadertoy works too. Your programs for VFP seem to fail with SWI name not known.

I have mentioned this laptop here before but I don’t think anyone actually understood what is under the hood. NVidia graphics with 192 cores. So yes OpenGL is really nice on that.
It should be possible to use OpenGL from RISC OS on Linux at some point using a backend that is linked against the OpenGL libraries. That way lots of new possibilities arise from within RISC OS.

@Timothy: using links to /proc/self/fd/… is best defined as a hack. No programs I know of make links to /proc/self/.. in the filingsystem.
Also when setting up the build environment it might be a lot easier to run a simple script to create links to DDE and use those. That’s how I get things to compile. Since this is intended to be built on Linux we should be using Linux to setup links. Also Make/AMU can detect if a change is in a file and act accordingly. That removes the need to use diff.
The build was done on a clean checkout with no stray links since the directory was created during git checkout.

/proc/self is a reference for a running program. So Only if that program has the same fd/9/ then the link to /proc/self/fd/9/… can actually work. Any other program trying to access a link pointing to /proc/self/fd/9/.. would get an error. This can be seen in errors like:

Unable to stat: ./mixed/RiscOS/Library/Acorn/c++,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/link,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/ResGen,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/amu,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/decaof,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/cc,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/cfront,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/cmhg,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/objasm,ff8
Unable to stat: ./mixed/RiscOS/Library/Acorn/libfile,ff8
Unable to stat: ./Export/APCS-32/Lib/c++lib
Unable to stat: ./Export/APCS-32/Lib/CLib/o/stubs_bootstrap

because:

ls -al ./mixed/RiscOS/Library/Acorn/
total 148
drwxrwxr-x 3 janrinze janrinze  4096 Feb 26 11:23 .
drwxrwxr-x 8 janrinze janrinze  4096 Feb 26 11:23 ..
lrwxrwxrwx 1 janrinze janrinze    39 Feb 26 11:23 amu,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/amu,ff8
lrwxrwxrwx 1 janrinze janrinze    38 Feb 26 11:23 cc,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/cc,ff8
lrwxrwxrwx 1 janrinze janrinze    39 Feb 26 11:23 c++,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/c++,ff8
lrwxrwxrwx 1 janrinze janrinze    42 Feb 26 11:23 cfront,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/cfront,ff8
lrwxrwxrwx 1 janrinze janrinze    40 Feb 26 11:23 cmhg,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/cmhg,ff8
-rw-rw-r-- 1 janrinze janrinze   540 Feb 26 11:23 debugaif,feb
lrwxrwxrwx 1 janrinze janrinze    42 Feb 26 11:23 decaof,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/decaof,ff8
-rw-rw-r-- 1 janrinze janrinze  5167 Feb 26 11:23 deccf,ff8
-rw-rw-r-- 1 janrinze janrinze 10271 Feb 26 11:23 diff,ff8
drwxrwxr-x 2 janrinze janrinze  4096 Feb 26 11:23 Docs
-rw-rw-r-- 1 janrinze janrinze 14159 Feb 26 11:23 find,ff8
lrwxrwxrwx 1 janrinze janrinze    43 Feb 26 11:23 libfile,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/libfile,ff8
lrwxrwxrwx 1 janrinze janrinze    40 Feb 26 11:23 link,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/link,ff8
-rw-rw-r-- 1 janrinze janrinze  8927 Feb 26 11:23 modsqz,ff8
lrwxrwxrwx 1 janrinze janrinze    42 Feb 26 11:23 objasm,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/objasm,ff8
lrwxrwxrwx 1 janrinze janrinze    42 Feb 26 11:23 ResGen,ff8 -> /proc/self/fd/9/!SetPaths/Lib32/ResGen,ff8
-rw-rw-r-- 1 janrinze janrinze 32111 Feb 26 11:23 rpcgen,ff8
-rw-rw-r-- 1 janrinze janrinze  5135 Feb 26 11:23 Squash,ff8
-rw-rw-r-- 1 janrinze janrinze  9087 Feb 26 11:23 squeeze,ff8
-rw-rw-r-- 1 janrinze janrinze  7167 Feb 26 11:23 toansi,ff8
-rw-rw-r-- 1 janrinze janrinze  7471 Feb 26 11:23 topcc,ff8
-rw-rw-r-- 1 janrinze janrinze  5199 Feb 26 11:23 unmodsqz,ff8
-rw-rw-r-- 1 janrinze janrinze  4879 Feb 26 11:23 xpand,ff8

Whereas the links should be pointing to the DDE directory which does not reside in /proc/self but in ../../../../../DDE/!SetPaths/Lib32/ which is the correct relative path when DDE is residing next to RISC_OS_Dev.

If a symlink RISC_OS_Dev/DDE pointing to the real DDE environment, it can be possible to use links like ../../../../DDE/!SetPaths/Lib32/ which would be convenient.

Somehow I wonder if it isn’t possible to make everything work using environment variables. usually ‘PATH’ and the likes are used to find things. So ‘ACORN_DDE_PATH’ should be possible to use and all can be found. Perhaps I am overlooking some things.

apparently commit c75a9ae833a4d38bec80e655f372508038c408e0 broke building on my ARMLinux machine.

The RISC_OS binary in github used to run Acorn binaries under Linux apparently no longer is compatible with my system. Not sure what changed.

Hopefully “git bisect” can find the source change which lead to the broken binary (you might want to use “git stash” first):

git bisect start c75a9ae833a4d38bec80e655f372508038c408e0 9ce264a3649202aae595666fe338fc0d2d2c94f3^

git bisect run bash -c ‘git checkout 9ce264a3649202aae595666fe338fc0d2d2c94f3 mixed/Linux/Support/RISC_OS.xz castle/RiscOS/BuildSys/Components/ROOL/Linux; make check; ret=$?; git reset —hard; exit $?’

Alternatively the output of strace may be helpful:

strace -o logfile mixed/Linux/Support/RISC_OS --nofork

@Timothy: Since RISC_OS.xz is supplied as a binary I don’t see why bisect will actually help me. There is only one change regarding that file. If the file was generated with the Makefiles then I could probably bisect. But binary files usually are built with a specific set of tools which may or may not be supported on other platforms.

The RISC_OS.xz file, how is that generated?

Somehow I think it is related to the way it handles the terminal since using sdl works fine.