ulmo 0.10.0 release
so there was this
i first tried it about 20 years ago. i liked it, because it was creating linux binaries that did not depend on c libraries.
it was very slow, however, and required lots of memory. my computer with 32mb of ram (yes i was always poor) wasn't able to compile a helloworld. that wasn't what i was thinking proper oberon should be like.
in part it was slow, as i recently confirmed, because the build process involved the db. that is pretty strange, and i never saw anything like that. in order to build a module, you had to check in the file in to a database, it had 2 network services constantly running - the db and the name server for project namespaces. then compiler could build the project from the database.
in part it was slow, probably because the compiler itself has many modules, and there's a rich library full of abstractions, and compiler itself uses the library extensively. in part ulm's oberon system is an attempt to develop a library.
so fast forward i'll say that now i see, it was slow mostly because of the database. and the complications it has, well, are nothing compared to how complicated modern compilers are.
when i was trying the compiler recent years, it stopped working for me. i made several attempts to revive it. as always, i would approach it, work a day or two, then forget about it, then approach it again, for years.
so i made 2 releases.
first, release 0.9 brings the compiler in to usable state today. as it was, with its name server and database dependency.
but it provides a custom linker script and links object files in an old way. also it considers libelf changes.
libelf is basically the only dependency from c and only one tool depends from it. there's tof2elf utility, that converts the intermediate tof representation to unix object files.
the next release, 0.10.0, basically deprecates all this complicated stuff with pons and cdbd, and the compiler now is able to build binaries from sources as files on the file system. just like any normal compiler does. (:
and it is fast now!
the remaining problem is, it's not a 64bit intel compiler. it is a 32bit compiler, but both compiler and resulting binaries work perfectly on 64bit linux machines, because cpu supports those instructions, and kernel usually is compiled to support 32bit mode. no 32bit userspace library is needed.
tof2elf is compiled to 64bit binary on 64bit systems, and to 32bit binary on 32bit systems.
also the compiler is able to build a dependency tree and compile all the dependencies, the programmer only needs to mention the main file on the commandline. the compiler will find the other modules, will build and link to the resulting static binary. just like fpc does.
so, that's it, you can read the release notes, and try to compile the test from two modules in src/test, the makefile there basically lists the command that is needed to compile the example. makefiles aren't needed with ulm's oberon compiler.
and yes, the naming. today i decided let it be ulmo, the sea lord.
https://github.com/norayr/ulmo/releases/tag/v0.10.0
Mar 12 · 8 weeks ago · 👍 imandes0, larrot
3 Comments ↓
🐙 norayr [OP/mod] · Mar 12 at 18:55:
another interesting thing about this compiler is that it follows very initial oberon design, which, like modula-2, had separate definition and implementation modules.
Around 2005, most PCs typically had 512MB to 1GB, with typical RAM prices of maybe $100 a gig. I wonder if your experience had to do with excessive swapping?
Consider that your RAM was 1/32 of what was expected at the time. Today, with say 16GB being the norm/minimum, you would struggle getting anything working in 512MB, 1/32th of the norm.
🐙 norayr [OP/mod] · Mar 12 at 21:20:
yes! still the oberon os from ETH would fit in less than 1mb, and the compiler would recompile itself in less than 1mb, actually in less than 512kb. i think in less than 256kb.
today i have some version of it in https://github.com/norayr/polpo - but i need to work more on it.