[Oberon] ulmo - revival of ulm oberon system

[նորայր]

Hello,

I would like to announce that i have managed to revive the Ulm's Oberon System. It didn't work for years, for different reasons, most importantly:

a) libelf changes. that was possible to solve by downloading tof2elf executable frum Ulm's website. Or using your own archived copy. It's not possible anymore to download it, but I had one.
b) Linux object file format changes, because of address space randomization.

I was approaching this task many times, as I do with other things I want to do, over the years. Once I managed to compile my tof2elf, but then I realized libelf changed, and tof2elf logic should be changed as well. Then at some point I came up with a linker script that helps to prepare compatible object files.

I had a binary installation from 2006, I used it to bootstrap the new version of the compiler.

I remember, I liked Ulm's Oberon Compiler for some reasons, and disliked for others:
Back then I was able to run Native Oberon on a very weak hardware. I could recompile the compiler. But Ulm's Oberon required lots of memory and would make my computers thrashing. I know that my computers had less memory than was normal at the time, but yeah, it is what it is. I felt that it's not good for an Oberon compiler to be as slow, and to not be able to compile a helloworld when I had 32mb of RAM.

What I liked was that it behaved sort of like FreePascal, its standard library only used Linux syscalls, it had beautiful interface with System.Unixcall, and resulting binaries did not depend on libc, but only required kernel. That's a very important advantage, and it made this revival much easier, because I worked on a 64bit Linux.
I also liked that it preserves the way Modula-2 worked with separate definition files that must be written by the programmer. Well I have relaxed that rule a bit, if the main module has no definition, the stub definition would be written so the compiler could build it.

Ok long story short, there were two releases:
In 0.9 I revived the compiler. It works on a modern Linux machine. It is able to compile files. It uses same way of building, with pons and cdbd. And it is slow even on my 11th gen Intel machine.

In 0.10.0 I managed to make it possible to not use pons and cdbd anymore. Now the compiler is able to build files right from the file system. Not necessary to check in those to the db. However the old way is still supported, in case someone needs it.
Now the build is so much faster! It's not as fast as OP2, the library is rich with abstractions, and the compiler uses those abstractions, and it's not as fast as OP2 is, but compared to today's compilers it's very fast and simple.
I also made sure that the compiler can work like fpc works: you provide it the main module, and it'll automatically figure out dependencies, and build the dependencies. You may supply paths to sources.
There's a test in src/test that illustrates this.

Yes, there's a makefile, but it is just for showing the user the command.
Makefile is not necessary, Oberon has strict module hierarchy, and compiler is able to figure out the dependency tree by itself. Actually  that functionality already existed in Ulm's compiler, just it was working with files that exist in db, not on file system.

So anyway, it works now, it produces 32bit binaries on 64bit system. tof2elf is compiled to a 64bit binary on a 64bit system, but that's fine.

The project repository is https://github.com/norayr/ulmo currently. Sorry for github. I know I need to migrate everything from there one day. Ulmo is from Tolkien world, and I guess it's legal to use it. Vala is from there too and nobody complained afaik.

Hope this will be useful. Meanwhile I'd like to gradually add amd64 support and HUGEINT type. Then maybe aarch64 and 32bit ARM. The compiler backend has a beautiful abstracted interface and everything clearly is divided to separate modules, but still, it's a lot of work. I have other projects and other work in life.

norayr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20260314/a5d13ddf/attachment.sig>