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 Rugxulo Homepage, Usono, 01.05.2013, 03:12

> > > Note that it is all still very initial, and I haven't heard the exact
> > plans, 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.
In theory, efforts or sources could be combined. No reason to reinvent everything in a vacuum (unless that floats your boat). We're not the first people to ever talk about such things.

> > 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.
I know, but I meant that somebody could (in theory) port it to whatever target they wanted. Even 16-bit wouldn't be totally out of the question, obviously.

Originally Scott implied that he wanted to eventually extend it to P6, a real native code compile for an extended dialect (his Pascaline?). But he's been very busy lately.

> 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.
Haven't tried lately. All I know is what we briefly discussed on the newsgroup (choked on "new(blah,blah2,blah3)"). Maybe I should try FPC snapshots on P5 again. It'd be cool if it worked in FPC. (Again, as nice as it is to self-bootstrap, perhaps there should be a bridge or two from other [more popular?] languages. Even Modula-2 or Oberon are more widely implemented than classic Pascal, AFAIK.)

> > 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.
<sarcasm>
Forget 32-bit, try 40- ... scratch that, 48-bit. No reason for a modern compiler these days to not use 1 TB. If you've got it, use it, why waste it? It's there to be used. RAM is cheap. Let them all upgrade, it's not 2003 anymore.
</sarcasm>

Funny that original Pastel (and GCC C frontend) couldn't work on 68000 due to reading the whole thing at once and keeping it in RAM, ate up too much stack. IMO, for a compiler (at least bootstrapping), you have to keep things really really minimal and avoid such situations. All the fancy features come later, first just get the basics working.

> > 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)
That's how they all did it "back in the day", tons and tons of passes. It's slower than keeping it all in RAM, but they didn't have that luxury.

> 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 :-)
If you're going to target a huge language like Delphi (and I'm not saying Nikolai is, I don't know), you're going to be in for a world of hurt. You can indeed target 16-bit with 16-bit host without problems. Maybe not as easily if you stick to strict portability or demand WPO (or LTO), but it can be done. In fact, throw away the idea that optimizations are necessary at all ... aren't computers fast enough these days?? (Throw away ye olde Makefiles! Use batch scripting to compile.)

> > 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.
It's mostly TP3-ish, as he claims, targets 16-bit DOS, public domain, and is Delphi (32-bit Win32 .EXE) hosted. That seems relevant. (Besides, the whole idea is that it can be improved further.)

Strings? Same as "array [1..255] of char". Sets? Same as "array [1..32] of boolean". Don't think on what it lacks in proper ways, think semantic equivalents.

No, I'm not saying this particular one is better or super useful, just saying it's a start, an existing project with similar goals, so it's worth mentioning (IMO).

> > 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.
In fairness, I forgot about error recovery and debugging, two other goals that people always add (as well as optimizations, ugh). Heck, even FASM doesn't have debugging, only "-s" for future converting. (Probably less of a loss as asm is so low level anyways.) There are, as always, too many competing and incompatible formats (that are only well-supported for certain platforms).

I'm just saying, you have to start somewhere. And I too don't know which debug format would be best. IIRC, OpenWatcom watcom debugging format was formerly used by them but eventually switched to Dwarf (2-ish). NASM can output Borland style for OMF. YASM supports Codeview (cv8), Dwarf, and Stabs. JWasm by now probably supports appropriate formats for all platforms.

> > 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 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.
I have no objections to any of that. I'm just saying, bootstrapping is a pain. Nothing (outside of Forth) ever easily bootstraps, and that (as well as monstrous demands for features) always kills language popularity.

I have no desire to limit dialect, but I also still think a decent 16-bit "hosted" compiler is far from difficult or impossible.

> 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.
I don't understand your obsession with "no multiple passes, no swapping" and "must have all optimizations from the entire world". I'm talking reasonably simple stuff, not making production quality competition to Delphi here. (I hate to keep bringing up Delphi, but it's just huge. Perhaps I should say C++. Though I think even "simpler" C is bloated too, esp. C99 or C11. Everybody always overcomplicates everything.)

EDIT: I think RR Software dude (Brukhardt?) said that their Ada95 compiler never uses more than 16 MB of RAM. I mean, I know we have tons more these days, but you can have a decent compiler working in 16 MB!

> > 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.
No, I don't know of any actively developed 16-bit compilers for those languages, I just meant in general, it might be easier to stick to a common Pascal-y subset of those languages and hand translate than trying to self-compile (bootstrap) with one specific (but using every feature in the book) language proper.

> > 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 :)
TeX / WEB (or whatever) avoided NEW/DISPOSE, nested procedures, WITH, and various other things (procedure parameters?). In 1982, I doubt Knuth was aware of Modula-2 (or even Ada), at least not in depth. And obviously not with later derivatives, but he did have portability in mind. The original Algol was a huge success, but everyone went on to various incompatible dialects for the same simple features! Without any bridge between them, they're all isolated to death (even if de facto or de jure standardized).

GCC and GNAT can brag all they want about portability, but they are a pain to compile, too big, too POSIX-y, and just overkill. At least Lua (for now) is reasonably small and sticks to ANSI C (with a few quirky assumptions). I just don't know why bootstrapping a language is this difficult.

Post reply
 

Complete thread:

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