Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

GCC 13.2 released (with Modula-2 support) (Developers)

posted by Rugxulo Homepage, Usono, 20.11.2023, 08:53

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

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 81 users online (0 registered, 81 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum