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, 06.05.2013, 17:43

> 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.
I wasn't trying to compare anyone to anyone else. And certainly such fluff as "production" wasn't on my radar at all. All projects start small initially. Unfortunately, most of them fall apart later because they can't handle the complexity. Don't you think that is something that should be avoided?

> And again, your bootstrapping problem is mostly self-imposed. I don't see
> an absolute need to have a 16-bit hosted compiler.
No, of course not, only if someone could only access 16-bit only machines, which is more rare these days than 10 years ago. (But 16-bit host is far from impossible, even for "real world production commercial compilers".)

But let's be honest, my printer most likely doesn't care if I use 16-bit or 32-bit or 64-bit software. As long as you send it the right codes, it'll do its job. (Hypothetically speaking. Right now my printer won't work at all, heh.) Most reasonable problems (and programs) don't (or shouldn't) care about bitsize at all. If you can't write something useful in 500 kb, you can't write anything.

> 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)
This was not necessarily meant to be a production tool out of the box. You'll have to adapt it. As is, it's meant to be a portable self-bootstrapping example of the original language as standardized.

I certainly don't expect it to influence FPC (nor you) at all, just mentioning it for completeness.

> > <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 ? :-)
Already been done. Besides, I don't have any 8-bitters.

> Or 1998 or so, when computers routinely got 16MB+
You don't need 16 MB for a decent compiler. You don't need 4 GB (or even 1 GB) for a decent OS.

> IMHO such efforts will never break free from mindless minimalism, and are
> thus doomed from the start.
I'm not suggesting a OISC esolang, just something that is reasonably-sized and doesn't need everything and the kitchen sink.

> > 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 ? :)
I'd be surprised if he supported full Delphi 7, but I guess it's not impossible.

> (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.
Useless because it lacks a full dialect (e.g. Delphi 7) or because you yourself will never need to use it?

> > 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?
I've not seen the FPC guts, but I doubt it's much cleaner.

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

I never mentioned "production". I wasn't comparing anyone, just mentioning an interesting example. All such harping like that just reminds me of BWK's "real work, not toys" bullcrap. (Some people just like to exaggerate.)

> 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"
If that were true, then why do we have so many competing technologies? Oh, that's right, it's often political bias, not technical, that limits software.

> > 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.
You have to stop somewhere. You can't add indefinitely. Worse is when features start conflicting (e.g. GNU Pascal's Borland stuff, lots of workarounds for that). Eventually complexity falls in on itself.

> Modula2 and Pascal have no subset. They are different languages with
> different keywords and different blockstructure principles.
Not 100% identical, no, but very very similar, due to common ancestry.

> (TeX discussion removed, didn't see the relevance, except to illustrate
> that before 1985-early nineties period portability is a b*tch)
Decent portability is still relatively unknown. People make horrible assumptions and just call it portable because it happens to work (sometimes accidentally). I don't admire any project that "only" works on Mac, Win, Lin. It's often less out of technical reasons than just developer whimsy.

> > 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.
Perfectly fine? GCC has undergone ten bazillion changes over the years and broken a lot of things. It's a pain to build, it's a pain to install. It's too POSIX heavy, and expecting it to work reliably on anything outside select targets (GNU/Linux using ELF, especially, their preference) is sometimes only wishful thinking.

Post reply
 

Complete thread:

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