DOS ain't dead

> Sorry for polluting your announcement!

We are both free to start a new thread.

> I'd also be interested in converting it to assembly. (You know, TP was
> allegedly written in asm, which is why it's so small.) I always had the gut
> feeling that most C programs were horribly bloated, roughly 10x more than
> they should be. Some of that is unavoidable, and I know it doesn't
> usually matter, but it still feels a bit sloppy. So I blindly guess
> that an asm-written minised could optimally be 4 or 8 kb (uncompressed). Of
> course, TP has a smartlinker, so it matters less there if written in
> Pascal. I do prefer TP over asm these days. I don't know, it's just
> something I wonder about. But there are no quick fixes in life.

That reminds me about all the unfinished things on my laptop.

---
Forum admin

> > > > I want to port minised to TP. Should be easy (famous last words)!
> > >
> > > Why TP, when it already exists written in another language?
> >
> > I think it would be an interesting comparison. But I admit there is no
> > super-obvious advantage. Still, who knows if it would be easier to speed
> > up or fix bugs.
>
> I'd also be interested in converting it to assembly. I always had the gut
> feeling that most C programs were horribly bloated, roughly 10x more than
> they should be. So I blindly guess that an asm-written minised could
> optimally be 4 or 8 kb (uncompressed). Of course, TP has a smartlinker,
> so it matters less there if written in Pascal. I do prefer TP over asm
> these days.

Classic J&W Pascal had limited string ("packed array [1..n] of char") support. I think UCSD Pascal was the inspiration for TP's "string" type. It feels almost like BASIC (no annoying bugs like in C where arrays decay into pointers/addresses). In fact, QBASIC or REXX would also be good tools for this kind of problem. (I'd already rewritten my A86 sed script into BAS, TP, C, and AWK, for comparison.)

So I finally rewrote my latest simplified FASM sed script into TP. I have a feeling that Prof. Wirth or Prof. Kernighan would call it too ad hoc. It should be simpler, more modular, more generalized! But at least it works and doesn't depend upon sed. With TP 5.5, it's only 5 kb (or 3 kb UPX'd). Not too shabby! Still, what little you save in size also means reduced functionality. Sed is better than an ad hoc, one-time, "black box" (opaque) solution.

Sets can be useful: "ch in ['a'..'z','A'..'Z','0'..'9']" = "[a-zA-Z0-9]". Although it's a size penalty to use that in TP when you don't truly need it. A few simple comparisons (like C's isalnum() function) here would have sufficed instead. So actually it was 5.5 kb until I avoided sets, then it's only 5 kb. Almost pointless to worry about such small savings, but I truly didn't need all the extra set functionality, so it should be avoided (for this one compiler).

Also, Modula-2 and Oberon are much more limited with their SETs/BITSETs. Basically, SET there is just a (byte-ending neutral??) abstraction for bitwise operations only for word-sized data (for 32-bit INTEGER, e.g. MIN(SET)=0 and MAX(SET)=31). I think J&W Pascal tried to support "set of char" (basically "array [0..255] of boolean"), but the ISO standard didn't demand that, sadly. This was one of BWK's complaints, that sets were too weak, but obviously it can be worked around or avoided. It wasn't necessarily meant to handle literally every scenario, just some limited uses.

I think C was loosely inspired by SNOBOL with such functions like strcspn() ("find first char in s1 that matches any char in set"), etc. (Icon is also an interesting successor to SNOBOL, but I'm not truly familiar with either one.)

I also wonder about Forth. I never truly learned it, plus I think it lacks some advantages of modular Wirth languages. But it's still good and has its own advantages (in small size, simplicity, portability, dynamicity = run-time vs. compile-time, etc). You know, interpreters don't have to be huge (sed isn't) for limited functionality. It just takes some TLC, some elbow grease, to finesse and whittle down everything to a reasonable subset.

Whatever, just something I'm thinking about.

> > What exactly do you miss that you can't find in existing solutions? I
> > somewhat know what you mean, but then again, we already have dozens of
> > tools (of varying quality). TP is good and unique but not that
> > unique or irreplaceable!
>
> That's easy:
> 1) TP6+ compatible (inline assembler),
> 2) Self-hosting,
> 3) Less than 1 Mbyte,
> 4) FOSS.
>
> All in one product!

I definitely sympathize, obviously, but I think nostalgia is less crucial than something you can actively use. From an architectural standpoint, considering how the BIOS/CSM is going away for good, how IA-32 is basically dead (see latest Ubuntu news, among others), how AMD64 hates 16-bit code, you'll be stuck to a VM, which sometimes won't work as well as you'd like. Hey, I like 8086 and DOS, but perhaps sticking to that exclusively for the future isn't wise.

MarcoV would clearly say "Just use FPC, it's more portable, more architectures, not limited only to mode TP, and (since it's FOSS and self-hosted) can be slimmed/modified if needed." You might even be able to compress it (with various tools) if 1 MB was truly your goal (for whatever unknown reason). But you knew that.

Dialectically speaking, there's a lot of similar toolsets. For classic Pascal (ISO 7185), you have P5 and p5c. GPC is effectively inactive, so there aren't many other Extended Pascal (ISO 10206) options, but sources are still available. I think Pat Terry long ago ported Hans-Peter Mossenbock's Coco/R parser to Turbo Pascal.

Wirth added SYSTEM to Modula-2, so inline assembly wasn't needed as badly. He prefers Oberon since forever anyways. I think he went out of his way to avoid literally any assembly in his latest works, relegating the minor need for system-specific stuff to the SYSTEM pseudo-module. His preferred dialect is Oberon-07, and his Compiler Construction and Project Oberon online projects/ebooks (BSD-licensed) are self-hosted and fit in 1 MB (of RAM) on a Xilinx Spartan FPGA or whatever. Not quite what you wanted but somewhat similar. (I think GForth had a Gray parser for Oberon, too.)

Turbo Pascal borrowed a lot of stuff from Modula-2 anyways (units vs. modules, close enough), maybe even from Oberon. (The OOP stuff is called "type extension" in Oberon.) Compared to raw assembly (and we have many self-hosted assemblers), Pascal is probably easier for units, strings, and dynamic heap allocation but otherwise not groundbreaking. I think Mossenboch's Oberon-2 book is freeware nowadays, not to mention Wirth's PIO (Programming in Oberon) instead of older (famous) PIM[234]. Although there are many Oberon dialects (Component Pascal [sic], Active Oberon, Zonnon).

Oh, even Excelsior XDS Modula-2/Oberon-2 compiler (which officially is supported by Japheth's HX) has now been open-sourced (Apache 2.0)! Although I'm still wondering if GM2 will ever be upstreamed (probably!) or work with DJGPP. (Bah, we still need some work towards FPC's Go32v2 and i8086-msdos.)

I know none of this is a quick fix or perfect solution, but similar things do exist and are out there in the wild. It wouldn't be impossible to recreate TP (or similar language or functionality) for DOS. Even MarcoV I think normally used to prefer Modula-2 over TP, but nowadays he's all in for Delphi (which is quite advanced, albeit very complicated after 20+ years). Even XPL0 was loosely based upon Wirth's old Pascal-based PL/0 (from A+D=P).

Sorry for the ramble. I just don't know why it's so hard to make a useful, simple, portable, standard compiler (that is easy to rebuild!).

Please start a new thread for further notes. Thanks.

---
Forum admin