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, 03.05.2013, 23:27

> 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.
True. But talk can be easily combinable over a couple of beers. For concrete projects that are built on different assumptions that is usually impossible.
(other than testing with one to make the other behave the same).

More importantly, I don't even see anything that you name is on the same level as FPC. They are not decade long polished production compilers, but one of attempts of people.

And again, your bootstrapping problem is mostly self-imposed. I don't see an absolute need to have a 16-bit hosted 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.

No, since it is not a complete solution. (pint.p must be compiled by something) AND the result is not that interesting anyway. A very minimal interpreter. Big deal.
(rest P4/P5 skipped. I'm only interested in it as testing codebase, not use)

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

Why put the holy limit at a 16-bitter with a 20 bit bus ? Why not go for some real iron, like a 8-bitter ? :-)


> 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.
Or 1998 or so, when computers routinely got 16MB+

> 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.
IMHO such efforts will never break free from mindless minimalism, and are thus doomed from the start.

> 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.
Yes, they did. Imposing those same limitations now is masochism, not heroism. There is nothing to prove, it has been done.

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

He is building a FPC backend. The frontend is unmodified. FPC is a pm codebase. Do you actually READ my posts ? :)

> You can indeed target 16-bit with 16-bit host without problems.

If you start over, and focus on it, you can probably do it in 286pm. (even with TP you needed the pm compiler for larger programs). Go ahead, but it is totally irrelevant for the FPC backend.

(xdpascal)
> It's mostly TP3-ish, as he claims, targets 16-bit DOS, public domain, and
> is Delphi (32-bit Win32 .EXE) hosted.

Yes. Exactly, useless.

> No, I'm not saying this particular one is better or super useful, just
> saying it's a start
For what? Suicide by compiler frustration?

> an existing project with similar goals, so it's worth
> mentioning (IMO).
Not a production compiler, not even in the same category.

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

Does the OW 16-bit target debugger support stab or dwarf? I can only see lists that are general (and thus are probably for 32-bit, and probably only a handful of the older like CV variants for the 16-bit target)

> NASM can
> output Borland style for OMF. YASM supports Codeview (cv8), Dwarf, and
> Stabs. JWasm by now probably supports appropriate formats for all
> platforms.
It is not who generates what (we do dwarf2/3 and stabs already), but what will read it.

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

For any compiler creating a new backend (architecture target) is a problem. It is simply a lot of work. But better a good compiler for a few targets, than something worthless that supports "everything"

> Nothing (outside of Forth) ever easily bootstraps, and that (as well
> as monstrous demands for features) always kills language popularity.
... and that proves the above point :)

> I have no desire to limit dialect, but I also still think a decent 16-bit
> "hosted" compiler is far from difficult or impossible.
Go ahead then. But it is irrelevant for the FPC project.

> I don't understand your obsession with "no multiple passes,

FPC archicture change.

> no swapping"
Swapping is fairly useless for programs that randomly access most of their allocated memory in a fine grained manner. Like compilers.

The whole principle of swapping/paging is that the working set at any time is systematically smaller than total memory demand. This usually doesn't go for compilers

> and "must have all optimizations from the entire world".
Yes. As you have shown, there is enough cruft already. Feature dropping is not an option. Features are important. 16-bit hosted not, except for fun.

> > 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.
Modula2 and Pascal have no subset. They are different languages with different keywords and different blockstructure principles.

(TeX discussion removed, didn't see the relevance, except to illustrate that before 1985-early nineties period portability is a b*tch)

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

No. They are perfectly fine. Nothing wrong with it. Real production compilers, no toys.

> At least Lua (for now) is reasonably small

Is a scripting language.

> and sticks to ANSI C (with a few quirky assumptions).
Yeah, another against it.

> I just don't know why bootstrapping a language is this difficult.
Its not a language. It is the program that DOES the language.

Post reply
 

Complete thread:

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