Oberon-2 -> C compiler
======================
(release 0.17.2)
220 LEX source files (scanner for lexical analysis) src/*.l
4,192 YACC source files (parser for syntactic and semantic analysis
and part of code generation) src/*.y
809 C header files (misc. definitions and interfaces) src/*.h
9,197 C implementation code files (main driver,
command line handling, symbol table, other auxiliary data types
and runtime system/library implementation) src/*.c
707 build, install, and test scripts (sh)
------
15,125 < 16K LOC
======
(+6,299 lines of Oberon-2 test code)
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...
[2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/comp/o...
Yes, compare that to the smallest possible, ISO-compliant burst laughing C++ compiler implementation in any language...
Complicated means "likely full of errors that are hard to identify"...
Your Forth implementation is fascinating.
To borrow your words, yes it's going to be frickin' cool.
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/ob...
I was planning on not having a Desktop Environment at all and just have graphical applications use the whole screen, but I was intrigued by Viewers and Texts architecture. Their fundamental simplicity is rather elegant and I feel that mixing this with Forth's own radically simple elements, there's something quite powerful to be had. I'm not sure yet how it will materialize, but I still have that feeling.
I'm not really looking to write new graphical applications for Dusk, so I'm not planning on ever needing a Oberon-based gadget framework. The idea behind Dusk is to port existing applications onto a radically simpler platform (compared to your typical POSIX) with a minimal effort, not to write new software.
I still can't really understand everything just from reading the code, but I had assumed it would be some kind of explicitly stack-based state machine precedence parser, like this article describes: https://h14s.p5r.org/2014/10/shiftreduce-expression-parsing-...
Kind of looks like you did that in expr.fs? Not completely sure, though.
Infix notation parsing happens in ast.fs[1]. It parses tokens left to right and builds a tree (the structure is Lisp-like cons) describe the expression in such a way that expr.fs[2] then just has to recursively process the top tree node to have proper codegen.
In other words, operator precedence, prefix/postfix operators, etc. are all considered in ast.fs. Once in expr.fs is reached, all those things have been processed.
AST tests[3] give a good example of what ast.fs does.
I'm not sure I'd say that Forth being stack-based particularly help there. This logic is more "recursive-based" than anything. Lots of recursion all around.
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/comp/o...
[2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/comp/o...
[3]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/tests/...
Yeah, I just think parsers are really cool, and have read enough about different parsing algorithms that I'm used to vocab like that.
As for Dusk OS: are there release tarballs/.zips or such anywhere available for download? (like for Collapse OS)
All I'm seeing is a reference to "target a release", which (I'm assuming) refers to some git function? Hoping to bypass the need for using git just to download & check archive's contents.
johnisgood•8mo ago
pjmlp•8mo ago
https://www.astrobe.com/default.htm
ETHZ still uses Active Oberon somehow,
https://gitlab.inf.ethz.ch/felixf/oberon
This is the owner of that repo,
https://inf.ethz.ch/de/personen/person-detail.MTMyNjc0.TGlzd...
However I do agree it is very niche, one is better of with Go, D, C#, Swift, as modern compiled managed languages with low level language features for systems programming.
bri3d•8mo ago
Commercially it had some popularity in industrial automation and robotics many years ago and some companies still maintain Oberon codebases for this reason. I believe this is the main target market for the commercial Astrobe Oberon compiler for Cortex-M, which sells enough to stick around.
I can’t think of a good reason to start a new commercial product in it and I’m not aware of any new commercial uses, but there are still lots of academic and hobby projects cropping up.
butterisgood•8mo ago
What I mean is if you pick the right primitives to begin with you don’t have to turn a system into horrid spaghetti.
Complexity costs everyone - consumers, people building products and supporting them etc.
And sometimes standardization is the enemy of the simple.
So these things will never be popular as long as committees exist to make our lives miserable.