leeter

I played around with the godbolt he put up, I honestly found that adding __restrict to the pointers appears to make the biggest generated code difference and the code seems to be written with that in mind. That does ruin portability sadly, but it does cut the number of instructions generated down significantly and allows the compiler to use memcpy.

I'd be curious to compare that to his normal version in a benchmark

nVidia and Sony actually cited this patent I'd think you'd need to look further back. I'd guess Cray? This seems like something they would have patented very early on with the Cray1.

Facebook's use of this pattern prevented me from attending my grandfather's funeral (live streamed on facebook because of COVID) earlier this year. I was to say the least... pissed. If not for my sister who re-broadcast it to me over discord I'd have missed it completely.

I personally think the better solution is going back to how copyright worked pre 1976, where copyright had to be positively asserted to exist and everything else went into the public domain. I'm also of the position that a 'make available' clause needs to be added to ensure that a work is constantly available during its period of copyright; moreover if the rightsholder should fail to make it available for longer than a set period of time it reverts to the public domain permanently. Finally I think the default period for copyright should be 23years (in line with patents) with progressively more expensive renewals based on the annual income of the property, the goal being to encourage people to let things go into the public domain unless they are extremely profitable.

They make money off the one uploaded and inappropriately claimed until they release the claim (and the money) or decline the counter-claim. They also have an option to claim a strike against the flagged work.

I think the thing that I've come to the conclusion with CISC and specifically x86 is that it's basically a better VLIW than VLIW. That's not to say there aren't opportunities with x86's memory model. To me the greatest advantage of RISC is it triggers my OCD less than x86 does... until I look at how CISCy ARM gets sometimes...

Seems like an LGR oddware candidate, along with other eyeopener devices like this.

That's what I'd assumed when I started skimming the spec, but the section I referenced seems to indicate a max of four regardless. I've never heard of a JPEG that's not RGB(A) or CMYK. So it would be highly unusual, not saying it couldn't happen but given how unusual it would probably be replaced with a custom format for that specific application.

Skimming the JPEG spec I think the commit author was waaaay off base. The actual spec is very clear that 4 components is the max and are expected to be sequential in nature (4.11 Summary of coding processes) unless I'm reading it wrong. Ultimately the original implementation was wrong fro not including a fourth channel per spec... but not wrong in assuming sequential.

They weren't horrible either, AArch64 is incompatible with AArch32 but you can still implement both on the same chip with shared internals.

AMD didn't have to extend x86 the way they did, but without buy in from intel there was no way forward unless they went the route they did. Because unless both had agreed to shift to UEFI at the same time and agreed on an ISA it wasn't going to happen. This is why even a modern x86-64 processor has to boot up in real mode... because there was no guarantee that the x64 extensions were going to take off, so AMD had to maintain that strict compatibility to be competitive.

AArch64 had no prohibition, because there is no universal boot protocol for ARM. Insofar as the UEFI or loader sets the CPU in a state the OS can use then it's fine. The fact that there is one IP holder helped as well.

That said could AMD make a x86-64 processor without real mode or compatibility mode support? Yes they can. In fact I would hope that the processors they ship to console manufacturers fit that bill. There is a lot they could strip out if they only intend to support x86-64.

Based on the docs kernel mode drivers would call KeWaitForMultipleObjects instead it appears. User space should just call WaitForMultipleObjects. While NtWaitForMultipleObjects and ZwWaitForMultipleObjects exist they seem to be undocumented which means they probably have funky behavior. Anything in KernelBase.dll is a pretty thin wrapper that I'd be hesitant to call Win32 so much as "really thin syscall wrapper"

As a native of a very well known mountainous state I can say it's more than that. If you're summitting on a mountain you need to be prepared to bivouac at least one if not two nights and survive adverse weather. Even experienced hikers can find themselves trapped far from the trailhead by either weather or fire. That's not even talking about the usual bears, mountain lions (don't hike alone), or ticks (Lyme Disease is real).

In my experience the executives want what the sales folks want. What the sales folks want is features, preferably features that work half the time so they can include a support contract on top of the license. So they can fix bugs and get paid for it but only the ones for a specific paying customer. They don't care if the overall thing is dying for lack of investment, they just want a signing because that's what their bonus is based off of.

This is quite interesting.

I've debated for awhile trying to write a "UEFI DOS" for awhile. Thus far I've always shied away because of the sheer immensity of just getting a UEFI dev env set up much less one that would support emulation/virtualization of DOS applications so they could pretend they are on original hardware.

All of that is not even considering the whole bytecode vs. native issue...

Not relational but IBMs Information Management System (IMS) comes to mind.

https://en.wikipedia.org/wiki/IBM_Information_Management_Sys...

dBase appears to be the first DBMS for minicomputers however.

Windows does it because the vast majority of functionality is not implemented in the kernel per se, but rather in user space by preference for stability. Even things like display drivers are often primarily implemented in userspace.

The main advantage of not having a stable kernel ABI is that you have the freedom to change it for security/performance reasons. This means the OS can change how they implement things over time without breaking things as easily. MS is notorious for this and for using this fact to allow them to 'emulate' older ways of doing things even when the real implementation has long since moved on.

The main advantage of having a stable kernel ABI is that the userspace can be whatever the developer wants it to be realistically. If they want it to be just a single GO program and literally nothing else they can do that (routers are a good example of devices that do this).

You completely missed the point, multiple release builds doesn't actually fix the problem of emulation not having the same behavior or timing. That has a big impact on software cert for purpose and could completely torpedo an entire project where a dev team works on a GC profile because actual hardware doesn't exist yet and is supposed to release on an I profile. There is no substitute for actual hardware.

Example: The Commodore 128 (or the Plus/4 works too). The C128 had a more powerful CPU capable of 16-bit work, accessing more RAM, faster Disk access etc. But in general it was rarely targeted. Why? Because developers were looking for the widest degree of compatibility and that meant restricting themselves to the minimal possible subset of compatibility between the C128 and the C64. This meant that by and large the 128KB of ram went unused as most applications ran in C64 mode.

The same applies here: the more extensions and things you pile on... the less likely they are to get used unless they are de-facto mandatory. Even today you can see games getting released that won't touch AVX instructions on both Intel and AMD because of compatibility reasons.

Valve provides data to developers on penetration of various ISA extensions via the hardware survey ( https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... ) but for RISC-V there is no way to do the same. So most utility writers will be highly constrained in what they will use in terms of expected extension use, that will have significant harms in terms of performance. Alternatively it requires recompiling for every single different target, which is also likely.

In essence: you need a good baseline of compatibility for people to expect to use. It makes moving software easier between targets. A piece of software might certify for example on R64GC but not on R32IF because the double precision emulation might not work as expected or the lack of carry could be an issue etc.

Not as simple as it sounds, HANDLEs are universal on windows. So it requires user mode code to both be in on the charade and to play nice, which it rarely ever does. The issue being things like GetWindowHandle, CreateMutex etc. Passing a Mutex or Event handle to another process is not uncommon on windows. Yes in theory you could just block off the lower 64k Handles as compat handles but it makes code complicated and that leads to unnecessary bugs in code that has to handle it. It's a lot simpler at the end of the day to just ask customers that need that support to just run 32bit windows which has NTVDM support for real mode code and simple 16bit protected mode support that's transparent and just works. So yes they could have done that... but the complication isn't worth it when they have something that works just fine already at no extra cost to development or client; and these apps are being phased out largely anyway. Long story short: the solution sounds simple but once you start plugging all the holes and corner cases it gets insanely complicated very quickly.

Mostly true, this would be protected mode 16bit code (286), not DOS code or real mode code. Protected mode 16bit code was rare and thus support was less needed.

So unfortunately people do care, it's why 32bit windows is still a thing. Most of the people that care however are large legacy enterprises that are running line of business applications that they don't have the source code for or require libraries they don't have the source code for. While they are migrating it's not a quick process in many cases.

As for 16bit HANDLEs for 32bit programs, it wouldn't have solved the issue as the HANDLEs are kernel tokens. The kernel doesn't actually care whether the user space application is 32 bit or 64bit in many cases. That's all handled via WoW64CPU.dll and friends. They proxy all kernel calls from 32bit code and then segment switch to a 64bit segment before calling the kernel. The same happens in reverse when coming back. So it would incur significant performance overhead in many cases to add that when it isn't really necessary and would negatively impact already memory constrained programs. Instead MS chose to let them get the best benefits they could from 64bit mode: all 4GB the 32bit address space can be used for 32bit things instead of just the bottom 2/3GB (depending on being flagged /LARGEADDRESSAWARE). In the end it's a lot more complicated than just telling people that aren't using very memory intensive apps in the first place to just run 32bit Windows which already works... and supports vm86 mode.

> It was a political choice by Microsoft to drop 16 bit Windows support in 64 bit Windows. This is the limit of their famous backwards compatibility -- still impressive, though.

No... it wasn't political. It was a deliberate design decision for technical reasons ( https://docs.microsoft.com/en-us/windows/win32/winprog64/run... ) HANDLEs on 64bit windows have 32bits that are valid whereas HANDLES on 32bit windows only have 16bits that are valid. So unless Microsoft wanted to completely negate the value of going to 64bit in the first place, e.g. expanding the limits on programs to be less restrictive, it was always going to have something to give.

Because 32bit code often "thunked"^1 in 16bit code they couldn't really support it because even in 32bit mode HANDLEs still have 32bits of valid HANDLE. So a HANDLE passed to 16bit code wouldn't round trip correctly due to truncation.

Nor is it like MS could emulate this like the OPs code does, because that would require rewriting applications that had already shipped from ISVs that don't exist anymore or magically understanding when an application has 16bit code and needs to get fake HANDLEs neither of which is easy in reality. In the end it was easier to just ship a 32bit version of windows for those that still needed that support.

1^ This was only possible because FAR pointers in 16bit mode are still 32 bits and thus size of a pointer was in effect the same. So they could operate in the same address space. In 64bit mode this isn't the case because there are no FAR pointers and segmentation.

People forget that Big O is only part of the story, they also need to consider Little o and average runtime. Just because something is n^2 or worse asymptotically doesn't mean the average runtime will be that bad. There are many cases where the average runtime is closer to Little o almost all the time.

A few things worth reading on the topic:

Why the C++ committee didn't go with 'Stackful coroutines AKA Fibers' http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136...

Raymond Chen's thoughts on where they are still useful (hint they really aren't): https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10...

It's worth noting that this recommendation has nothing to do with delivered power.... a 500W can handle most systems on delivered power.

This has to do with transients, the 3000 series cards have some massive transients that can easily trip OCP protection on powersupplies not designed for that kind of transient. A 700W powersupply is able to handle those transients much better than a 500W PSU is.

Removed

So it sounds like the games were probably doing too much in the re-implementation (60FPS isn't necessary for a DOS game).

To answer the question:

>Is there any hope of actually getting the promised performance out of modern hardware without having a CPU/assembly expert on your team?

The answer is: it's complicated. Let's assume you want absolute maximum performance, so you use a uni-kernel design (quite a few super computers basically do this). Even without the overhead of virtual memory (minimal on modern hardware), the removal of multi-tasking (expensive but mitigatable) on a single core; you would still have to deal with all the complex things you need to do to run modern hardware. Modern hardware is complex, it's complex because we want things to be fast or have high bandwidth (usually both).

Ultimately you can usually get 90% percent of what the hardware can do with a good compiler, decent software architecture, and tuning to encourage vectorization; probably 95% with a great compiler. Even in user mode, even in Windows. So at the end of the day it's about what's more important: Using as few cycles of a CPU, or as few cycles of your time implementing it. I think the re-implementers chose the latter as they chose to let SDL follow its default FPS instead of tuning it downwards.

I remember a prior boss of mine was once asked if our reporting product could use PDF as an input. He chuckled and said "No, there is no returning from chaos"

Yeah my first thought was just running a 16bit OS on modern hardware (it will do it if you're careful and do the right things). But then the issue of it being an ISA card popped up... that's not really a solvable problem with modern hardware unless you can convince an IHV to make you a custom motherboard. Although apparently some exist ( https://www.ibase.com.tw/english/ProductDetail/EmbeddedCompu... ) probably for industrial applications. While I'm very sure you could get DOS running on that... I'm less sure of Windows 95. The google search did show other options that are plausible but I doubt many of them would arrive working as is without needing capacitor replacement at a minimum.

Oh probably and even if you did find one that works "well" you'd have to buy a ton of them to ensure you have backups. I'm well aware of the issues. But without an alternative or a grant to update the hardware what do you do? At some point the availability of period hardware with ISA slots is going to be prohibitively expensive.