DOS ain't dead

Sorry, for a 1-year old news, may be it will be useful:

-------------------------------------------------------------------

Source code for the Lilith's single pass Modula-2 compiler has been recovered. Jos Dreesen informes: "I managed to extract the sourcecode for the Lilith's single pass Modula-2 compiler from the harddisk of the Lilith on display in the Museum of Kommunikation in Berne / Switzerland. This singlepass compiler was used as the basis for many followups : the IBM RT port, Macintosh port and and...".

https://www.astrobe.com/Modula2/
https://www.astrobe.com/Modula2/M2SPCompilerSource.zip

or

https://github.com/DosWorld/pascal.modula.ada.oberon/tree/master/Lilith-and-Modula-2/Single-pass

The third Lilith Modula-2 compiler was released in 1985. It is a single-pass compiler developed by J. Gutknecht and N. Wirth and compiles about four times faster than the earlier multi-pass compiler. The single-pass compiler is also significantly smaller than the older 4/5 pass compiler.

The source code went missing for many years but was eventually located in Nov 2021 by Jos Dreesen, the designer of the remarkable Lilith emulator EmuLith.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

There's a lot of old stuff floating around.

https://people.inf.ethz.ch/wirth/projects.html

> Modula-2 Compiler, 1983-85
>
> Over the years it became evident that the available Modula-2 compilers,
> including the one from ETH, were less than optimal, and through mediocre
> performance sometimes deterred users to take full advantage of Modula-2.
> Wirth decided to develop a new compiler from scratch by himself.
> It is based on the simple principle of one-pass compilation, whose
> application had become possible because of the large memories of modern
> computers, and which eliminates most of the slow accesses to secondary
> storage devices. The new compiler is remarkable because of its clear
> structure, its compactness and its efficiency. The program is about
> 5000 lines long, compared to 10'000 of its predecessor and 100'000
> of comparable Ada compilers, and it compiles itself in less than 2 minutes,
> compared with half an hour required by its predecessor. These advantages
> are not only visible in the compiler's use, but they demonstrate that
> powerful modern languages do not necessarily require giant, complex
> translators, as is so often claimed.

Keep in mind that Wirth still prefers Oberon (see Project Oberon and Compiler Construction).

For Modula-2, you're probably better off with ADW, ACK, XDS, GM2, or even FST.

https://www.phoronix.com/news/GCC-Modula-2-FE-2022-Review

> [T]he latest Modula-2 front-end patches for the GNU Compiler Collection (GCC)
> were sent out. The Modula-2 driver code has been rewritten and is now based
> off GCC's Fortran and C++ drivers. The Modula-2 linking mechanism has also
> been completely rewritten.

Sorry for the non-sequitor, but I would like to talk with DosWorld about his SmallC archive an GitHub. I have opened an issue there for further discussion link:: Small C issue (FJS).

Thanks!

> Sorry for the non-sequitor, but I would like to talk with DosWorld about
> his SmallC archive an GitHub. I have opened an issue there for further
> discussion link:: Small C
> issue (FJS).

Unlike OpenWatcom (e.g. wlib.exe), Turbo C cannot be legally redistributed by users. But you can still (with a free online account of theirs) download it.

https://edn.embarcadero.com/museum/antiquesoftware

> Sorry for the non-sequitor, but I would like to talk with DosWorld about
> his SmallC archive an GitHub. I have opened an issue there for further
> discussion link:: Small C
> issue (FJS).

Why not? Create PR (pull request).
In fact, i am don't do development for all this tools. It is just a museum (or zoo ).

Here is most notable continue development:
https://github.com/alexfru/SmallerC

Available one more notable work on github - author name sounds like he is from Romania, but i am forgot his account (thats all what i remember about him). He also work with Small C sources and create own linker for obj/omf.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Available one more work on github - author name sounds like he is from
> Romania, but i am forgot his account (thats all what i remember about
> him). He also work with Small C sources and create own linker for obj/omf.

ZaneDubya/Small-C: Small-C Compiler, Assembler, Linker, and Library for 16-bit MS-DOS. Includes "YLink", an object file linker for MS-DOS executables.

---
Forum admin

> Keep in mind that Wirth still prefers Oberon (see Project Oberon and
> Compiler Construction).

Niklaus Wirth is a brilliant scientist but his works lacks practice.
I am play with his source codes of compilers - try to find more practical application.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> ZaneDubya/Small-C: Small-C
> Compiler, Assembler, Linker, and Library for 16-bit MS-DOS. Includes
> "YLink", an object file linker for MS-DOS executables.

Yes, he. Thanks!

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

>
> For Modula-2, you're probably better off with ADW, ACK, XDS, GM2, or even
> FST.
>
> https://www.phoronix.com/news/GCC-Modula-2-FE-2022-Review
>
Didn't know there are still people working on keeping the language alive and trying to get it into GCC. Modula always was a little short on the compiler side. Perhaps we are getting a version that is capable of generating DOS binaries anytime in the future

> Keep in mind that Wirth still prefers Oberon (see Project Oberon and
> Compiler Construction).
I like the Wirth family of languages a lot. In my opinion, while Oberon is the pinnacle of elegant language design, here Wirth took the idea of simplification one step too far. If you put a language definition on just 17 pages, too many things are undefined or constrained (with Scheme Language as exception to this rule ).

> > Sorry for the non-sequitor, but I would like to talk with DosWorld about
> > his SmallC archive an GitHub. I have opened an issue there for further
> > discussion
> > link:: SmallC issue (FJS)
> > .
>
> Why not? Create PR (pull request).

OK. I am new to GitHub, but have joined, made a branch of your smallc::master, committed a change to README.md, and tried to create a PR to you (DosWorld/smallc::master) as a test. Let me know if it worked, either here or via GitHub.

Anyone know how to move my intrusions and their responses to a new 'smallc' thread?

> I like the Wirth family of languages a lot. In my opinion, while Oberon is
> the pinnacle of elegant language design, here Wirth took the idea of
> simplification one step too far. If you put a language definition on just
> 17 pages, too many things are undefined or constrained (with Scheme
> Language as exception to this rule ).

https://en.wikipedia.org/wiki/Vienna_Development_Method#Industrial_experience

> VDM has been applied widely in a variety of application domains. The most
> well-known of these applications are:
>
> Ada and CHILL compilers: The first European validated Ada compiler was
> developed by Dansk Datamatik Center using VDM. Likewise the semantics
> of CHILL and Modula-2 were described in their standards using VDM.

Dec/16/2022 (from here)

> [UPDATED] GNU Modula-2 is now in gcc-13 master which means gm2 will be
> released with GNU GCC 13 next year. This is great news again -
> Modula-2 will be available on multiple architectures and diverse
> environments.
> An article entitled GCC 13 to support Modula-2: Follow-up to Pascal
> lives on in FOSS form was accordingly published by The Register.
> The integration of the Modula-2 frontend was also mentioned at
> Phoronix.com: Modula-2 Language Frontend Merged Into GCC 13.

from Phoronix:

> GCC 13.1 has been released as the first stable version of GCC 13 as this
> annual feature release to the GNU Compiler Collection.
>
> GCC 13.1 is a big update that adds a Modula-2 language front-end for those
> interested in some vintage programming

FINALLY!

> > GCC 13.1

https://packages.debian.org/stable/devel/gcc

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > > GCC 13.1
>
> https://packages.debian.org/stable/devel/gcc

Yep. Slackware Linux is getting ready for it.

Thu Apr 27 04:40:20 UTC 2023
a/kernel-generic-6.1.26-x86_64-1.txz: Upgraded.
a/kernel-huge-6.1.26-x86_64-1.txz: Upgraded.
a/kernel-modules-6.1.26-x86_64-1.txz: Upgraded.
ap/dc3dd-7.3.1-x86_64-1.txz: Upgraded.
d/kernel-headers-6.1.26-x86-1.txz: Upgraded.
k/kernel-source-6.1.26-noarch-1.txz: Upgraded.
l/harfbuzz-7.2.0-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
testing/packages/gcc-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-g++-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-gdc-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-gfortran-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-gnat-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-go-13.1.0-x86_64-1.txz: Added.
testing/packages/gcc-objc-13.1.0-x86_64-1.txz: Added.
_____________________________________________________________

Perhaps sometime soon DJGPP will get it ?

---
--
http://glennmcc.org/

> > > GCC 13.1
>
> https://packages.debian.org/stable/devel/gcc

https://packages.debian.org/unstable/gm2 (12.2, apparently)

> Perhaps sometime soon DJGPP will get it ?

IMHO, "a little bit sooner then never". Update gcc for djgpp looks not so easy task.

(to all)

I have few idea (but i don't promise):
1. "small oberon" (the same as small c, but oberon). If use p-code, it allow make better codegeneration (via p-code transformation).
2. Watcom Team - "does not auto-reject discussion" if somebody came with new frontend.

PS: Sorry for a my "long tongue", life is dramatically dynamic.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

GCC 13.2 Released With 58+ Bugs Fixed

> GCC 13.2 Released With
> 58+ Bugs Fixed

So DJGPP doesn't have it, ArchLinux doesn't build it, Cygwin is still using GCC 11, but Debian stable Bookworm 12.1 has GM2 with GCC 12.2.

Also godbolt.org has it (13.1 and 13.2 are broken, but snapshot works).

Also, Rugxulo, i hear you do some experiments in compilers area..

I want share idea:
It is need go in reverse way:
1. Create linker (obj's -> exe)
2. Create backend - codegenerator (bytecode -> obj)
3. Create frontend - parser (source -> bytecode)

If go in direct way each step will create new restrictions and requirements (more and more) -> need do lot of refactoring for all prev steps (and chain steps). Also, in this way possible (near to) easy create TP7-grade compiler only.

For example, i move to trash my experiments with Pascal-S, because (imho) Wirth's bytecode is not so good for optimization on backend (no SSA form, etc). Also, all of this is a reason for "strange" project rlink.

Will be better split all steps to standalone applications.

Imho, Wirth's pascal-p5/m2/oberon cover frontend only and shoud be used last of all.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Also, Rugxulo, i hear you do some experiments in compilers area..

I've never written a compiler, and I'm sorely lacking in deep understanding of symbol tables, trees, graphs, LL(1) parsing, etc.

I mainly like using (or even rebuilding) interpreters and compilers and find some language dialects intriguing. But most of it is hampered by non-portability or extreme complexity.

> I want share idea:
> It is need go in reverse way:
> 1. Create linker (obj's -> exe)
> 2. Create backend - codegenerator (bytecode -> obj)
> 3. Create frontend - parser (source -> bytecode)
>
> If go in direct way each step will create new restrictions and requirements
> (more and more) -> need do lot of refactoring for all prev steps (and chain
> steps).

A million separate auxiliary .EXEs and lots of temp files? That's probably what I would do, but if your target machines have enough spare RAM, you can save some effort by not strictly separating everything.

> Also, in this way possible (near to) easy create TP7-grade compiler only.

TP7 may be overkill. In particular, it's too DOS/8086-specific, and Wirth would eschew any inline assembly feature. Oberon-07 isn't perfect either.

> For example, i move to trash my experiments with Pascal-S, because (imho)
> Wirth's bytecode is not so good for optimization on backend (no SSA form,
> etc).

His RISC cpu code is probably considered "bytecode" these days.

> Also, all of this is a reason for "strange" project rlink.

The last thing you need to worry about is ELF vs. Mach-O vs. PE/COFF. Use something neutral (if possible).

> Will be better split all steps to standalone applications.

Maybe, and I halfway agree, definitely. But it will be slower and use temporary files. (So? Use a RAM disk.) I think it's more "transparent" this way to see what's going on, to make certain steps optional. (Obviously a preprocessor is not strictly needed for some languages and slows everything down.)

> Imho, Wirth's pascal-p5/m2/oberon cover frontend only and shoud be used
> last of all.

One guy was running TP5 (under EMU2) hosted on Linux. But another guy was emulating CP/M (Z80) on a RaspPi (via Ultibo) with no host OS and running TP3. Another guy tried to port the Oberon/RISC emulator (compiler and OS) to RaspPi as native (also via Ultibo).

While I am not writing a compiler (yet), I do find it interesting to read about certain subjects (when porting or refactoring code):

* https://en.wikipedia.org/wiki/Optimizing_compiler
* https://en.wikipedia.org/wiki/Algorithmic_efficiency

> Also, Rugxulo, i hear you do some experiments in compilers area..
>
> I want share idea:
> It is need go in reverse way:
> 1. Create linker (obj's -> exe)
> 2. Create backend - codegenerator (bytecode -> obj)
> 3. Create frontend - parser (source -> bytecode)

Although bytecode is slower, I do think creating (and redistributing) 10 bazillion separate native code .EXEs over and over again for each target platform is redundant. Perhaps better to have one bytecode universally (with interpreter / VM) that can be translated with a separate tool to native code (AOT?) if needed.

> If go in direct way each step will create new restrictions and requirements
> (more and more) -> need do lot of refactoring for all prev steps (and chain
> steps). Also, in this way possible (near to) easy create TP7-grade compiler
> only.

Although I like TP and Pascal, I also consider Oberon a decent choice.

> For example, i move to trash my experiments with Pascal-S, because (imho)
> Wirth's bytecode is not so good for optimization on backend (no SSA form,
> etc). Also, all of this is a reason for "strange" project rlink.
>
> Will be better split all steps to standalone applications.
>
> Imho, Wirth's pascal-p5/m2/oberon cover frontend only and shoud be used
> last of all.

Everybody and their brother seems to have their own bytecode format. I'd almost just rather prefer Lua's VM (for simplicity) over Java's VM.

Anyways, my interest in ISO 7185 "classic" Pascal (e.g. P5) is still strong. But I keep bouncing back and forth between P5, P4's subset, TP 3 (Alice Pascal), TP 5.5, and Oberon.

Although I've been careful to keep my ISO 7185 code roughly 90% as close as possible to TP dialect, requiring minimal changes. (I have more TP compatible compilers than ISO ones, but sometimes they support both.)

What I ended up doing for P4 was to write some small, standalone transformation programs that are run first (if needed). I have not studied Doug Comer's MAP (macro preprocessor) yet.

FIXME2.PAS is a very small subset of Sed on a single script that (only supports s/foo/bar/g and /delme/d but) helps a lot. (I actually also wrote TP and C versions for better clarity and compiler support, possibly smaller .EXE.) This is also much simpler than Diff + Patch.

P4LOWER.PAS is because P4 only supports lowercase keywords.
P4SETS.PAS is because P4 lacks ['A'..'Z'] ranges.
P4INCDEC.PAS is because inc() and dec() are common in later languages (also unsupported in TP 3 and Alice).
P4HEX.PAS is for $decafbad hex numbers and // comments.

It works for my simple code (minus a few theoretical corner cases that I need to fix). Not a perfectly universal or optimal solution but a good local one. In other words, it fills in a few gaps without having to restrict my source dialect too too much. Best to keep it as middle ground as possible, esp. when using multiple compilers.

Nothing revolutionary, just simple fixes.