Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

comparison of Pascal (P4 subset) bytecode compiler (Developers)

posted by Rugxulo Homepage, Usono, 29.04.2024, 05:42

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

Post reply
 

Complete thread:

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