DOS ain't dead

> 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).

> 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.