modern 64-bit cpus (Miscellaneous)
> Well the default here is more "Je ne comprend pas!". At least that is the
> quintessential reaction of the French according to urban legend.
No one speaks French here, including me. (BTW, happy Mardi Gras.)
> > > > Never heard of it. All we have is the mundane
> > > > HP, Dell, MS, Apple, Lenovo, Asus, etc.
> > >
> > > Yup, except for Apple of course since it doesn't sell Windows laptops
> > > afaik.
> >
> > Bootcamp still exists, right?
>
> Yeah, but why pay the idiot tax to run an emulator ?
Some people need or use both, apparently. Hey, why pay the Windows tax if all you're going to use is Linux?? Why pay state taxes for almost all online purchases, including digital (like has been forced around here in recent years)?? Dunno!!
Want a good laugh? Appleās MS-DOS Compatible 486 Macintosh from 1995! "The Power Macintosh 6100/66 DOS Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside!"
Nowadays, just run a hypervisor (presumably xhyve, based upon bhyve ... or maybe Parallels?). I haven't been as active in recent years, so I've done very little, but FreeDOS 1.3rc2 is out.
> The next FPC version eliminates Watcom tools. (maybe not yet for win3.1x
> native though). Generating 16-bits dos apps on 64-bits *nix without
> external tools is now viable.
I noticed via snapshots, just haven't tried to rebuild it myself.
> > Keep in mind that recompiling p7zip natively in DOS (with admittedly old
> > G++ 3.4.6) also only took four minutes, IIRC. Yes, emulation can be very
> > slow. Still, not to complain, slow emulation is better than literally
> > nothing, as long as it's relatively accurate.
>
> I never compiled p7zip
A quick try yesterday, with newer G++ 9.2.0, didn't show any huge slowdowns, so that's good. (GCC itself was converted to a subset of C++03 back in '13. I believe C++11 support finalized in the 4.8.x series. More or less, C++17 is fully supported in latest stable versions, barring platform anomalies.)
IIRC, *BSD has libarchive and its own unzipper these days. Ubuntu has included Info-Zip as default for a few years. Yeah, I remember FreeBSD has xz nowadays, too (.txz in RELEASE while OpenBSD still uses inferior .tgz, 32 kb dictionary vs. 16 MB, I think). i386/AMD64 are still "tier one" on FreeBSD, right?
Oh, I never bothered with Raspberry Pi, but FreeBSD apparently still (!) supports ARMv6 for that. I was amazed, years ago, since most people hated that old arch, that anybody at FreeBSD was sympathetic. (Of course, I'm sympathetic, from afar, just because it can't be that bad, but most people hate hate hate such "old" things! Yes, I know, newer versions have newer arches, so who cares.)
> > > > > Afaik gcc doesn't really support that, only simple nesting.
> > > >
> > > > Trampolines? (I have no idea.)
> >
> > Macs don't like trampolines,
>
> Since 2008, nobody likes trampolines since they require writable stack.
Executable stack, I presume you mean. (I'm no systems engineer, I don't fully know the details.) See Wikipedia.
> Most 64-bit targets were fairly quick to require that also(since they had
> no legacy software)
If you constantly and forcibly upgrade everything, it matters less. Not everything should be rolling release, though. (Doesn't ZFS on some modern OSes have fallbacks nowadays?)
> > IIRC, and I'm not even sure if GPC works there
> > anymore (from what little I read).
>
> Well, the writing has been on the wall for a long time. Pity that they
> never did the reboot that Frank was talking about( generating C, more FB
> cgen style). Even though it wasn't my cup of tea, I was somewhat curious to
> see how it would turn out in practice.
The ancient 3.4.6 codebase (2005?) was in C (K&R?), which made things difficult when they couldn't extend it, at least not as easily. Though I doubt C++ is a panacea for all ills.
GPC was mostly paid work, so I think the main developer (and other dude) were only interested in getting paid. (Not to sound cynical, but I think that's fair.) He didn't care for his own use, he actually preferred C++11, so he was only interested if someone else was financially interested. Apparently old users gave up and migrated to other things.
I did see one guy from .nl (SARC?) "privately" migrated from Extended Pascal (Prospero, not GPC) to D. I don't really blame him, I know it can get complicated, but his attempts to use FPC and Ada didn't pan out (surprisingly), yet he really loves D! Good for them, I guess.
What a strange world.
> > BUT ... nested functions are (yet another)
> > feature that many people can't live without. I wonder how Pascal-p5c
> > deals with it (probably using the GCC extension, I haven't looked closely).
>
> From the website, it looks superficial, very basic. Wouldn't be surprised
> if FPC's ISO mode was more compatible.
D is integrated as official frontend into GCC nowadays since 9.x, and it supports nested functions. Barring implementation limits or bugs or OS-specific problems, it makes no sense to say that GCC (or C or C++) can't handle it if it already handles it in the D frontend. That doesn't mean anybody cares or needs it that badly, nor that it will be standardized, just that it's "probably" not impossible.
Oh, BTW, GM2 (ISO 10514, ISO Modula-2 atop GCC) also works with nested procedures (and C++-compatible exceptions, your Delphi favorite feature), though I've barely tested it (years ago). Similarly, it probably will get merged one day. I always check this one blog from time to time.
Complete thread:
- modern 64-bit cpus - Rugxulo, 21.02.2020, 11:40 (Miscellaneous)
- modern 64-bit cpus - marcov, 22.02.2020, 19:31
- modern 64-bit cpus - Rugxulo, 23.02.2020, 02:10
- modern 64-bit cpus - marcov, 23.02.2020, 17:24
- modern 64-bit cpus - Rugxulo, 24.02.2020, 00:11
- modern 64-bit cpus - marcov, 24.02.2020, 21:59
- modern 64-bit cpus - Rugxulo, 26.02.2020, 03:54
- modern 64-bit cpus - marcov, 26.02.2020, 18:11
- modern 64-bit cpus - Rugxulo, 27.02.2020, 12:13
- modern 64-bit cpus - marcov, 27.02.2020, 21:44
- programming language comparison - Rugxulo, 01.03.2020, 11:55
- programming language comparison - marcov, 03.03.2020, 11:46
- programming language comparison - Rugxulo, 03.03.2020, 23:02
- programming language comparison - marcov, 04.03.2020, 11:02
- Minix - Rugxulo, 05.03.2020, 00:12
- programming language comparison - marcov, 04.03.2020, 11:02
- programming language comparison - Rugxulo, 03.03.2020, 23:02
- programming language comparison - marcov, 03.03.2020, 11:46
- programming language comparison - Rugxulo, 01.03.2020, 11:55
- modern 64-bit cpus - marcov, 27.02.2020, 21:44
- nested procedures - Rugxulo, 03.03.2020, 06:05
- nested procedures - marcov, 03.03.2020, 10:16
- nested procedures - Rugxulo, 03.03.2020, 22:19
- nested procedures - marcov, 08.03.2020, 23:08
- ultra-modern x86_64 cpus - Rugxulo, 31.03.2020, 20:29
- ultra-modern x86_64 cpus - marcov, 17.04.2020, 12:02
- ultra-modern x86_64 cpus - Rugxulo, 31.03.2020, 20:29
- nested procedures - marcov, 08.03.2020, 23:08
- nested procedures - Rugxulo, 03.03.2020, 22:19
- nested procedures - marcov, 03.03.2020, 10:16
- modern 64-bit cpus - Rugxulo, 27.02.2020, 12:13
- modern 64-bit cpus - RayeR, 27.02.2020, 05:41
- modern 64-bit cpus - marcov, 26.02.2020, 18:11
- modern 64-bit cpus - Rugxulo, 26.02.2020, 03:54
- modern 64-bit cpus - marcov, 24.02.2020, 21:59
- modern 64-bit cpus - Rugxulo, 24.02.2020, 00:11
- modern 64-bit cpus - marcov, 23.02.2020, 17:24
- modern 64-bit cpus - Rugxulo, 23.02.2020, 02:10
- modern 64-bit cpus - marcov, 22.02.2020, 19:31