modern 64-bit cpus (Miscellaneous)
> > 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??
It shouldn't, but is simply too hard to avoid. But you can choose not buying an Apple and just a normal device.
> 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!"
Yeah, I've actually worked with such card once, though in slightly later Mac (4400 or its clone?), circa 2000 to run Turbo Pascal during a FPC get-together. I didn't have a laptop back then, and one of the local guys brought this one to work on for me.
> > 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.
rc1 has been branched, probably takes a week or two before all is uploaded and announced.
> i386/AMD64 are still "tier one" on FreeBSD, right?
I don't do much FreeBSD. The servers that I have used for 2015 were taken offline in fall 2018, and at home I mostly switched to Linux derivatives due to HW support.
> Oh, I never bothered with Raspberry Pi, but FreeBSD apparently still (!)
I have all 4 iterations (1,2,3,4), so maybe I should give it a whirl.
> > 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.
Yup, sorry. That link seems to indicate that they are better than fat pointers or displays (which are stack records with information), without providing the reasons.
I only know what the GPC people told me long ago, that they chose it because it aligned with GPC. I also heard that the "C" nested implementation was limited, but also never verified that independently.
More complex cases of accessing parent parameters with multiple levels and recursion (basically writing a recursive descent parser as nested procs) was said to be big dividing line.
However such very procedural code is now much rarer.
> > 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.
If the work sticking to the old stuff becomes larger than the disadvantages on the newer incarnation, I upgrade. Nostalgia is overrated.
> Not
> everything should be rolling release, though. (Doesn't ZFS on some modern
> OSes have fallbacks nowadays?)
I've no idea. I don't like rolling releases, I mostly use LTS versions.
(GPC)
> 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.
At least typesafety and amount of casts would lessen somewhat.
> 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.)
IMHO not fair. They worked on it voluntarily while they also used it at work. And they deserve credit for that volunteer work.
> He didn't care for his own use, he actually preferred C++11,
> so he was only interested if someone else was financially interested.
The company had changed a decade before that reckoning, so some synergies were gone. And then hobby becomes a chore.
> Apparently old users gave up and migrated to other things.
Most were already quite old.
> 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.
Strange post, his demands are weird, and many have no or few details. Comparing GCed to non GC languages is IMHO apples and oranges anyway, and it heavily depends on intended application.
Usually such tradeoffs are driven in the direction the main guy wants anyway. It is usaully more about finding justification than to really measure the various languages. More importantly, I complete miss other aspects than language (libraries, target concerns, IDE, gui etc etc), which is another sign it is crafted for a specific audience when the decision already had effectively been made.
In my case D being GCed would earn a -50. Useless.
> 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.
C also has nested functions, but like D I don't know how far it goes. The need for trampolines would usually indicates a more advanced usage though.
> That doesn't mean
> anybody cares or needs it that badly, nor that it will be standardized,
> just that it's "probably" not impossible.
It can also mean that it only supports cases that can be transformed to internal form that doesn't do anything special. Probably you'd have to dig into the C and D regression suites to see what it supports.
> Oh, BTW, GM2 (ISO 10514, ISO Modula-2 atop GCC) also works with nested
> procedures (and C++-compatible exceptions, your Delphi favorite feature),
Don't understand. Do you mean SEH?
> 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.
Browsed through it. Mostly same content as 2003. See that the M2 R10 stuff is also dead. (not that sad about it, IMHO it was a bit too baroque)
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