Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FPC 16-bit (Announce)

posted by marcov, 30.04.2013, 17:15

> > I had nothing to do with this port :-)
>
> IIRC, FPC (circa 1993) was originally compiled with TP (16-bit) and
> intended as 32-bit TP dialect replacement (since Borland defected to
> Windows) and eventually became self-hosted for 32-bit DOS (GO32v1) target
> only.
Correct

> Then everybody went cuckoo for Cocoa Puffs for Delphi (1997?).
Early, D1 (16-bit, win3.x TP compiler based) is 1995. But I didn't migrate from TP, but from Topspeed Modula2. I used TP before, but I never explorer some aspects (like its pm stuff)

> > I left 16-bit for new projects +/- 1997
>
> DEC brought out the Alpha in 1992, why didn't you jump ship earlier?

SGI did Mips in 1990. But I used DOS and a bit of Linux/BSD then, and in those early times I mostly used W9x as I used DV/X before it , to run multiple dos shells and swap between them.

The main reason for me to abandon 16-bit was the 640k limit. (there was an extender for TSM2, but it was expensive, and I didn't have it).

TSM2 also didn't have an HUGE memorymodel, so I don't have much experience with that either.

I played with the thought to go back to TP and dig into the 16-bit extender stuff, but I was playing with *nix, and knew that would get more important. (for my use I mean, since that was the dorm's server and the always-on machine)

> They
> have a Pascal compiler. Heck, GPC might actually build there too. ;-)
I never managed to build GPC on anything in that period. I also got very mixed signals about its viability (e.g. different versions (both GPC and GCC) on different targets etc, and little community around it.

Even if FPC hadn't existed, I doubt I would have ended up with GPC.

> > when I started with FPC, and ported all remaining stuff to it in 2000.
>
> Almost funny considering how much the 1.x series is regarded as so weak in
> hindsight.
The requirements were different back then too.

> Yes, admittedly, 2000 and XP were flawed but still somewhat serviceable for
> DOS stuff.

This was early w2k time. I ran betas even before it really came out. XP was much,much later.

And anyway, IMHO it was not servicable. It was the proverbial last straw. DPMI memory limits, console programs starting up real slow, application programs assuming LFN already anyway

> But stuff after that ... not so much. It's kinda ugly having so
> many wars over competing tech.
I was already way beyond that then, since I had working FPC code on *nix.

Dos was important to me (a platform I used for 10 years), but not the center of my world. The portable code had inherited assumptions (like LFNs), and DOS was becoming the weakest link, so I just decided to move on.

> > Note that it is all still very initial, and I haven't heard the exact
> plans
> > (asked for rationale, Nikolay said "because I can"). E.g. how many TP
> > idiosyncrasies (think inline($54) etc) are going to be implemented.
>
> There are other 16-bit Pascal subset-ish compilers and VMs out there.

Yes. I fail how to see it is relevant for this discussion.

> Even
> P4/P5 is well-documented, but I've not delved enough to even pretend to
> port that (to 32-bit, much less 16-bit) as actual native compiler.
P4/P5 is not strictly a 16-bit compiler. I don't know where you got that idea? It is release as source, and meant to be portable.

It compile with FPC/trunk nowadays (and even mostly works), except for the bit where in ISO mode parameters are wired to file descriptors. A few paramstr() inserts, and it works, at least superficially.

> > Self hosting (16-bit compiler that generates 16-it programs) is probably
> > out of the question. (at least if I my memory is correct and 286pm only
> > does 16MB max) So probably it will always be (64/)32-bit -> 16-bit
> > crosscompile.
>
> You can use EMS on 8086 or XMS on 286.

Memory as in addressable via the addressing scheme of the compiler. Using EMS/XMS requires handcoding, or at the very least very coarse block level allocation (and no fine grained access). That won't do for a compiler's memory requirement.

> IIRC, Jason Burgon (GVFM dude) once
> said you can get about 128 MB from 16-bit Borland DPMI, maybe more with
> HDPMI16 or (which?) Windows or DPMIONE.

Afaik the 286 MMU was limited to 16MB. (the same limit as the ISA bus) Maybe you can get further with newer CPUs, but in that case you can also run the 32-bit version.

If your MMU can handle more, I would guess the hardware limit is having 65536 non overlapping segments of 64k, which is basically 4GB +/- some mappings required by Dos (like the first 1MB)?

> And of course always swap to hard drive if needed.
This is fairly useless for compilers. Swapping works fine if blocks of memories aren't use for a long time (iow if you have a working set of memory that at most times is sufficiently smaller than total memory)

Compilers mostly allocate finely grained.

> You really don't need lots of RAM to make a compiler. You can either split
> off into several passes (like early Modula-2) or just don't try to support
> the full Delphi XE2 ten bazillion functions, operators, keywords, forms,
> IDE, smart linker, etc.
Irrelevant. We are talking about retargeting an existing compiler to 16-bit, not new compilers and what you can dream up. If you want those dreams, get started :-)

> My silly Android tablet
> has aDOSBox [sic], but it's dirt slow. I haven't bothered much with it. I
> assume eventually somebody could port something natively useful to FPC,
> which more or less claims to support Android and ARM in trunk (right?).
Yes, but that are mostly not black and white things. Two ways to android even, but usually it is simpler to simply root it to debian, if you want development work done :-)

> There's another (Delphi-compiled, HX friendly IIRC) DOS cross-compiler
> (.COM only) subset on SourceForge, public domain, though I don't know how
> useful or interesting it is.
>
> http://sourceforge.net/projects/xdpascal/files/
Not useful and uninteresting. No strings, not sets, nothing. Even TP3/4 is better.

> I've intentionally tried not to cloud this thread, esp. since I'm no
> compiler expert. But suffice to say, it's complex. The two biggest issues
> seem to be trying to use all available memory (and peripherals) as well as
> interfacing with the outside world (libs, ABIs, linking).
Yes. That's the first sane remark in this post. But it misses the major problem. Debugging. Much more difficult than assembler or linker.

Watcom debug is said to support Dwarf,stabs and Codeview, but it is not clear what of those is supported for 16-bits target.

> Quite honestly, I know it's not quite the same, but I wonder if it would be
> equally worthwhile to port something simple like Pascal-S interpreter. (I'm
> not sure if it's been done reliably before. There are a lot of half-broken
> offshoots and maybe Ada- or Seed7-hosted versions floating around, dunno.)
While I don't have a direct interest in the 16-bit target from an user perspective (it's merely retro sentiment for me), I would say there are enough minimalistic attempts. Better have a cross-only compiler that generates good code and supports a complete dialect than forcing an artificial 16-bit bottleneck on the compiler to be 16-bit itself.

And more importantly, I think it is impossible. 16MB is simply not enough. Solutions to use more probably also can run the 32-bit compiler anyway.

> Though I know it already can compile quite easily (minimal changes) with
> FPC, but I'm thinking about translating into other languages (Modula-2?
> Oberon?),
I wasn't aware that any of those have currently active 16-bit efforts. Or anybody else even.

> Heck, I've not even gotten a grip on ye olde PL/0 yet. (As cool
> as self-hosting is, I can't help but wonder if it'd be wiser to be more
> neutral.

I'm not sure what neutral means in this context. IMHO self hosting is the neutral choice (no added dependencies :)

Post reply
 

Complete thread:

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