FPC 16-bit (Announce)
> "Itanium is dead, x64 wins!" (groan)
One could argue if it was ever alive to be begin with.
> I have no idea, but Wikipedia claims it's still going strong, at least
> through 2017.
I think C=64 as a target sees more action than Itanium.
> Except for GCC, they are all very narrow in what they target and are
> ridiculously expensive.
Yes. There are discount and educational versions though.
> GCC's main problem is being too *nix-oriented,
All true.
But still that is what is mostly used.
> finally updated for May. I think it's quite funny what they say, and you of
> all people may find it "interesting".)
I think search analysis is a lousy way of determining language usage, so I don't take tiobe very seriously. I see Delphi usage at every client I visit (usually in some engineering department), and no wonder that that doesn't make the web.
> > No. Since I might simply use another compiler if I had an extremely
> tight
> > budget.
>
> 99% of compilers are expensive. If your budget is tight, you won't have
> enough money to keep buying more and more compilers.
One in twenty plus years should be doable. 16-bit is the way of the dodo since before the mid nineties.
Or simply live with an imperfect (gcc) one. But nothing justifies requiring silly and arbitrary 500k limits.
> Reveals my roots? That was my whole point! The IBM PC grew up with
> PC-DOS/MS-DOS, and (more or less) we still have such compatibility today,
Yes. But you didn't post a msdos specific statement, you posted about nothing worth doing requires more than 500k. That is a general statement.
> > > Everything else is mostly ignored (including FreeBSD). If certain
> parts
> > of
> > > the commercial world weren't so anti-GPLv3, FreeBSD wouldn't exist
> > > anymore.
> >
> > Wrong, since GPLV3 is fairly recent.
>
> Five years is hardly recent. A lot has happened since then.
Still you don't really qualify your above statement about FreeBSD non GPLv3 sentiment being its raison d'etre.
> > FreeBSD has a strong following among
> > ISPs. It is not a client OS, so comparing downloads is a bit strange.
> > (since that is an end-user centric metric).
>
> I meant third-party projects that explicitly target FreeBSD, not just
> random *nix compatibility in sources that halfway work. Those binaries have
> very very low download counts.
That's exactly what I mean. That is an end-user (desktop) centric way of measuring a server OS.
> Certified? No, nobody wants to waste the time or money (same as Linux or
> FreeBSD, from what I hear). And no, it doesn't (can't) support things like
> 2008 (mmap). My point was that even what is there (1992, parts of 2001) is
> ignored.
A chain is only as strong as its weakest link. You are either compatible or not. A few rest bits of posix compatibility are useless.
> > Well, or simply think that the burden/baton should pass to actual users?
> > Maybe there is a nice task for you there
>
> No, because even when it works they don't care.
Neither do users apparently, or they would step up.
> > The balance that hardware like memory makes in the total cost of
> software
> > development. Hourly programmer rate / unit memory.
>
> Costs always go up, never down.
In currency yes. But in price/MB, no.
> Besides, the whole "RAM is cheap" cliche is a red herring. Nobody can truly
> install 256 GB or 1 TB anyways, the motherboard is way too limited.
No, but you can install 4GB for sub Eur 50, which is still way more than 500kb. Or when did you last bought new memory in sub 128MB quantities? 2000 ?
> > > Apple, IBM, Intel (not ICC), Embarcadero, FreeBSD, Minix all use and
> > > support it. There's probably more groups than that, obviously. It's
> far
> > > from dying.
> >
> > All those wins are on license, not on technical grounds. So....
>
> Faster compilation. Less memory usage. 75%-90% speed of GCC.
Two of those would be interesting. Unfortunately there are killer downsides:
- bad cross platform/architecture support.
- no openmp
- own part of toolchain (linker/assembler/debugger) projects are not
that active it seems.
> That's far from just licensing
True. But I think for your list the licensing bit was dominant.
> (which reminds me, you never hear about PCC
> anymore. At one time that was seen as the one to follow. Guess nobody cares
> anymore. Sad, really.)
As far as I know, OpenBSD clung to PCC as a last hope for a while. But it never really was " the one to follow" for the rest.
> > Nope. The so called nextgen compiler is still very incompatible (the iOS
> > XE4 recently released is based on it).
>
> BTW, dare I say it, but ... is iOS really worth targeting? Well, I guess if
> something is trendy enough and makes enough money ....
Not for me. Anyway, the problem with iOS targeting is a bit as a lottery. Yes, there are people that win, and develop succesful iOS apps. From what I see this group is small.
Most of them however seem to see it just as another client (shop front in vertical markets), more a mobile form of website than real applications with functionality. It is expected though and they grudgingly bear the cost, or even hope to score points against the competition. This is the largest group by far.
Then there is a group attracted by the mobile glory and play with mobile toolchains but never ship something real and just want to get on board.
> > This because it does more than just LLVM. It also tries to reinvent the
> > language on .NET/Java footings, including immutable strings, meaning all
> > string routines need to be reviewed/rewritten.
>
> In fairness, Delphi already probably had too many kinds of strings.
I'm not sure that is really the case. Yes it has many, but most are for specialist but viable use. Only shortstring could be canned I guess, but many argue even against that.
> (And
> other languages have had immutable strings too, perhaps due to garbage
> collection, dunno. E.g. Lua and Modula-3.)
Garbage collection is probably a factor yes. But Delphi is not a GCed scripting language.
> > If Embarcadero continue on this course, I'll probably have a few years
> left
> > on my XE3, and then migrate either to MSVC or FPC.
>
> Migrating to MSVC sounds like a bad idea. Even if you loved C++ (since
> their C support is minimal, i.e. C++ wins over obsolete C), there are many
> other tools.
C++ wins over C period
> But maybe you're one of those that can't live without fancy
> IDEs. That seems to be most people's favorite thing about MSVC. (Well, the
> console is indeed considered obsolete in many peoples' eyes, part of the
> reason Windows was promoted so heavily.)
It's very telling that you are anti-IDE, but not really explain why the other tools would be an option at all. Or ask why I chose MSVC.
> During previous revisions to this post, I deleted some points. But let me
> exhume one: we are both living in deprecated worlds.
>
> Windows: Win32 GUI (preferred), DOS console (legacy, deprecated)
The windows console also exists, and is prefered. (cmd.exe vs command.com).
Since last year there are even console only windows (server) versions again.
> Linux: GNOME or KDE under X11 (preferred), POSIX console (deprecated)
Hard to say. Linux, like Windows is a server OS, and console belongs there.
> So even if there is some compatibility, it's always shunned and ignored by
> some people.
You confuse not the popular choice with outright deprecated.
Complete thread:
- FPC 16-bit - marcov, 26.04.2013, 09:41 (Announce)
- FPC 16-bit - Laaca, 26.04.2013, 16:14
- FPC 16-bit - marcov, 26.04.2013, 22:30
- FPC 16-bit - DOS386, 28.04.2013, 14:53
- FPC 16-bit - marcov, 29.04.2013, 10:17
- FPC 16-bit - Laaca, 29.04.2013, 12:52
- FPC 16-bit - marcov, 30.04.2013, 17:36
- FPC 16-bit - marcov, 01.05.2013, 19:47
- FPC 16-bit (80186 cpu + NASM info) - Rugxulo, 03.05.2013, 10:40
- FPC 16-bit (80186 cpu + NASM info) - marcov, 03.05.2013, 15:10
- FPC 16-bit (80186 cpu + NASM info) - Rugxulo, 03.05.2013, 10:40
- FPC 16-bit - Rugxulo, 30.04.2013, 14:00
- FPC 16-bit - marcov, 30.04.2013, 17:15
- FPC 16-bit - Rugxulo, 01.05.2013, 03:12
- FPC 16-bit - marcov, 03.05.2013, 23:27
- FPC 16-bit - Rugxulo, 06.05.2013, 17:43
- FPC 16-bit - marcov, 08.05.2013, 23:39
- FPC 16-bit - Rugxulo, 15.05.2013, 19:00
- FPC 16-bit - marcov, 15.05.2013, 21:27
- FPC 16-bit - Rugxulo, 15.05.2013, 22:44
- FPC 16-bit - Laaca, 16.05.2013, 10:15
- FPC 16-bit - Rugxulo, 16.05.2013, 20:35
- FPC 16-bit - marcov, 16.05.2013, 20:46
- FPC 16-bit - marcov, 16.05.2013, 21:26
- FPC 16-bit - marcov, 16.05.2013, 21:19
- FPC 16-bit - Rugxulo, 17.05.2013, 07:52
- FPC 16-bit - marcov, 05.06.2013, 13:34
- FPC 16-bit - Rugxulo, 06.06.2013, 00:03
- FPC 16-bit - marcov, 01.07.2013, 22:29
- FPC 16-bit - Rugxulo, 07.07.2013, 01:52
- FPC 16-bit - marcov, 01.07.2013, 22:29
- FPC 16-bit - Rugxulo, 06.06.2013, 00:03
- FPC 16-bit - marcov, 05.06.2013, 13:34
- FPC 16-bit - Rugxulo, 17.05.2013, 07:52
- FPC 16-bit - Laaca, 16.05.2013, 10:15
- FPC 16-bit - Rugxulo, 15.05.2013, 22:44
- FPC 16-bit - marcov, 15.05.2013, 21:27
- FPC 16-bit - Rugxulo, 15.05.2013, 19:00
- FPC 16-bit - marcov, 08.05.2013, 23:39
- FPC 16-bit - Rugxulo, 06.05.2013, 17:43
- FPC 16-bit - marcov, 03.05.2013, 23:27
- P5 (PCOM/PINT) with FPC 2.7.1 snapshot - Rugxulo, 03.05.2013, 10:53
- P5 (PCOM/PINT) with FPC 2.7.1 snapshot - marcov, 03.05.2013, 15:04
- FPC 16-bit - Rugxulo, 01.05.2013, 03:12
- FPC 16-bit - marcov, 30.04.2013, 17:15
- FPC 16-bit - Laaca, 29.04.2013, 12:52
- FPC 16-bit - marcov, 29.04.2013, 10:17
- FPC 16-bit - Laaca, 26.04.2013, 16:14