leeter

Must have depended on variant, the one we used in college would throw a GP fault for misaligned access. It literally didn't have an A0 line. That said it's been over 10 years and I could be remembering the very hard instruction alignment rules as applying to data too...

Sounds like M68K or something similar, although Alpha AXP had similar byte level access issues. A compiler on either of those platforms likely would add a lot of fix up code to deal with the fact they have to load the aligned (either 16bit in M68K case or 32Bit IIRC in Alpha) and then do bitwise and shifts depending on the pointers lower bits.

Raymond's blog on the Alpha https://devblogs.microsoft.com/oldnewthing/20170816-00/?p=96...

I'm curious how much they'll pull over from the existing DLCs, the Plazas and Promenades pack does allow for pedestrian cities. But not in a European sense despite the dev being in Europe.

It's not just backwards compat, it's all the crazy guarantees that the stdlib has to make. Most code doesn't have strong exception guarantees... the stdlib generally speaking does. It also has to deal with all sorts of silly things without breaking like people overloading operator,() and still expecting things to work without issue. They really are a case study in getting decent performance in most cases out of exceptionally defensively written code.

This was not what I thought it was. I assumed it was the `for(auto f : <collection of class>)` issue that STL tried to fix and gave up on. Turns out it was initializers and locks. Extending them to live as long as the loop much like the `if` initializer syntax does for the block.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p27...

I keep hoping that the C and C++ committees will get together and standardize some of that in the form of C23/C++11 style attributes. But that is sadly likely a naïve hope.

Primary ATC is still done that way but at least for the big jets there are other ways they send digital comms to ATC[1]. The main reason is because radios fail and more complex radios fail more easily. A standard Jetliner carries three radios, any of which the pilots can use to contact ATC. The bands are internationally standardized. So it's not just a case of the FAA mandating a change. It would have to be the entire world. So even if the FAA did require digital radios it wouldn't actually change much because both ground and plane would still have to transmit analog backup anyway. That creates more chatter etc.

It's also important to recognize that controllers are human and can only deal with one thing at once. The current system generally speaking gives one human control over one section of airspace.

In this specific case the pilot should have been aware of the restricted airspace and set a flight plan that took them away from it before turning to their destination. There is zero excuses for flying into restricted airspace as there are published maps. The zone around the WH and USC is a permanent zone, so even less of an excuse.

[1] https://en.wikipedia.org/wiki/ACARS

RISC Architectures confirmed murdered by Itanium: Alpha AXP, MIPS (on the desktop), and HP PA-RISC

Architectures set back significantly by Itanium: POWER, SPARC

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

The answer is: yes

Itanium failed because getting instruction parallelism is actually incredibly hard to do and compilers didn't catch up in time to make it matter. But it also failed because of AMD64 which had backwards compat, was cheaper by a lot, and was a lot easier to get decent perf out of.

Opinion: I think Itanium was always destined to fail. The idea seems good on paper but fails in practicality because it limits what the hardware can do to achieve speed without breaking backwards compat with itself. You can't have a superscalar Itanium by definition because branch prediction etc. is by design delegated to the compiler. This means that the chips can literally only go up via clock speed, which as we now know doesn't scale forever.

To answer the last question first: Yes instruction decoding is dirt cheap (generally speaking) the thing that slows down a CPU is memory model, register retirement etc.

In theory RISC was intended to be basically no microcode where the CPU would expose the hardware instructions. In reality that is done to an extent but superscalar basically made the advantage that had mostly obsolete. This left RISC having the main advantage of having a ton of registers which does simplify other things when designing a superscalar CPU. But at the end of the day most architectures are falling into the "FISC" singularity where speed is all that matters. This is why AARCH64 was deliberately designed to be insanely superscalar from the ground up.

The article misses a lot, it assumes the only battleship on battleship combat was Jutland. That's simply not true. Surigao Strait[1] and the Naval Battle of Guadalcanal[2] both definitely occurred. As did Hood/Bismarck (this one depends on if you consider HMS Hood a "Battlecruiser" or "Fast Battleship" IMO it's the latter).

But the point of a battleship wasn't just showing off, it was also area denial. You really can't move another surface combatant into an area with a battleship unless it is a battleship (that didn't stop Taffy 3 [3] from trying). So battleships served two clear roles IMO: Area denial and shore bombardment. There is a reason the US Navy kept the Iowas around until the 90s. For what they do there is nothing like them. That said let's also be clear the counter to a battleship is an aircraft carrier, not a battleship based on existing data.

[1] https://en.wikipedia.org/wiki/Battle_of_Leyte_Gulf#Battle_of... [2] https://en.wikipedia.org/wiki/Naval_Battle_of_Guadalcanal [3] https://en.wikipedia.org/wiki/Battle_off_Samar

Correct, the main value of std::out_ptr is the exception safety. There is no gap between the call and when you wrap the value in a smart pointer where something can happen and cause a leak. Is it strictly necessary in all cases? No, but it's a nice to have because it makes code less error prone if there are multiple paths. You can ensure the resource will be released when the scope ends. A code reviewer could look at the deleter to ensure it was the correct one for the use and be satisfied in most cases.

It would; you'd just have to supply a custom "free_deleter" in the definition of the unique_ptr that calls free instead of delete. I've used this for Windows System calls like GetAddrInfoExW which requires calling FreeAddrInfoEx when you're done.

    std::unique_ptr<ADDRINFOEXW, addrinfo_deleter> holder;
    ADDRINFOEXW hint = { .ai_family = AF_UNSPEC };
    if (const auto result = GetAddrInfoExW(
        sHost
        , nullptr
        , NS_ALL
        , nullptr
        , &hint
        , std::out_ptr(holder)
        , nullptr
        , nullptr
        , nullptr
        , nullptr); result != ERROR_SUCCESS) {
        // print error here
    }

No idea, my app is open source and I do other things at my day job.

Even GDI runs on the GPU[1] it just is slower because bitmaps are stored in system ram vs VRAM. IIRC there are tricks a driver can use to make it faster by default[2].

The (admittedly very dumb) issue I as a developer have switching from MFC/ATL to newer kits is that it makes it very hard to ship all in one apps without bloating them by shipping the control toolkit every single time. I realize this is a dumb complaint, but when I can get something down to ~3.5MB which I consider a win for size squishing in modern apps. But does it make sense for all cases? No, if I was writing something people need to use on more than an occasional basis I'd probably grab a toolkit that did the work for me to use D2D (which btw operates on top of either GDI or DX11, not DX12).

[1] https://learn.microsoft.com/en-us/windows/win32/direct2d/com... [2] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

My understanding is yes and no. In the pre DX12 era drivers often contained full replacement shaders for games sometimes. Where the OEM would hand write a replacement that worked better than what the game dev did, potentially on a GPU sku level. They would also potentially completely re-write how sections of the pipeline worked with shims for the same reasons. This was sustainable because shaders were relatively tiny (look at the limitations of DX9 shaders vs DX10+), and the pipeline relatively simple. However moving forwards to DX10+ and shader size explodes, as does pipeline complexity, and shader count. While they still did this for popular titles by special agreement, they largely switched to issuing guidance and providing tools to devs to optimize their games. But the issue persists. Writing shaders for Nvidia's warp system will potentially compromise performance on AMD, Intel etc. So OEMs still do some shims for games when performance is particularly egregious. But with DX12 and Vulkan in particular it's more about having presets for things like you'd find in NVidia control panel and a few game specific optimizations to critical paths, instead of just replacing how that game interacts with the driver completely.

If I have to buy something on Amazon I've gone out of my way to make sure I'm buying from them directly lately. Too many issues with them pulling crap like this when it's a third party seller. But by forcing them to be the seller I force them to also be subject for that transaction to my state's consumer protection act. That seems to cause them to care more because suddenly they are on the hook because they are not just the marketplace.

I think I saw that one; but the one that comes to mind is also:

https://www.techdirt.com/2018/04/27/how-microsoft-convinced-...

I seem to recall someone else getting in trouble for distributing Windows ISOs in the past. MS tends to get very touchy on that ostensibly for security reasons (which I actually get). They seem tend to look askance at scripts that strip down the OS but don't seem to otherwise care other than to tell people they won't get support while using said things.

> I suspect it might have been a common idiom in pre-C99 days.

There is a Blog from Raymond on this[1]. The TL;DR: is that zero length arrays and FAMs weren't legal until C99. Not sure where the support from MSVC factors in. But that's the story and AFAIK he's sticking too it.

[1] https://devblogs.microsoft.com/oldnewthing/20040826-00/?p=38...

I'm mixed on this personally, on one hand... I get it. Having curl on the XYZ micro controller you're using for a project is good. At the same time the only reason MSVC added c99 support was community pressure because major projects said "we don't care about MSVC anymore we're moving on"[1]. So clearly there is a correlation between vendors and versions. If the vendors don't feel pressure to support newer versions then they'll just continue to ship the garbage they've been shipping for years. I personally don't have a good answer for this. Daniel very clearly has made his decision and I'll respect that as it's not my project.

[1] Also because the C++ committee ignored Herb and just forced it into later C++ revs from a library perspective.

Short answer: Maybe[1]

Longerish answer: Still maybe, drivers are going to be an issue. Just because the thing can boot into a DOS compatible mode doesn't mean it will have windows 9x compatible drivers. Having DOS drivers does not also make something automagically windows 9x compatible either[2]. That said it should be plausible to get a board like Rastari did that is fairly compatible because industrial reasons. But it does mean you have to pick carefully.

[1] https://www.vortex86.com/news/3 [2] https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

My suspicion is you're right. Mostly based on Raymond's blog on the role of DOS in Windows 95[1]. Where people using weird drivers and other things that got in the way of 32bit disk access could massively slow down the system. It's plausible that one extender was being "nice" and using your native drivers or at least trying to be compatible whereas another just went "Nah that crap is slow" and just went for it with a native direct driver and was thus massively faster.

[1] https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

I think to some extent all ISAs that are asked to do performant computing inevitably drift from RISC/CISC into FISC (Fast Instruction Set Computing) in the sense they get instructions that are specifically designed to accelerate the most common workloads they'll be executing most commonly. In ARM64's case this is things like the infamous "javascript" instructions that emulate x86 floating point (which is also part of how javascript works for speed reasons). In x86 this has lead to a subset of instructions being super fast while anything off that beaten path is now slow (avoid the LOOP instruction at all costs!) as well as specific extensions being added for common work loads (AES, Crypto, FMA etc.).

> If I put in an SSD it might even be faster.

I think most of the retro youtubers I've seen have done this mod along with PRam battery replacements that don't leak. They seem to use the m.2 SATA mode drives to 44pin like thus (not recommending, just showing an example) https://www.amazon.com/44pin-Converter-Adapter-Computer-Acce...

Correct, AFAIK the main reason to not support Win16 protected mode was the size the relevant bits of HANDLEs which would have been severely limited to 16bits. Completely obviating the reason to use 64bit windows. As is HANDLEs are 32bits of significant data on at least through Windows 10. In theory now that Windows 11 has dropped 32bit support could be 64bits on Windows 11. All of this because someone will inevitably want to use the clipboard between a 64bit app and a 16bit app and it would have made things VERY painful. Could MS have written a layer that "fixed" that? Potentially but the number of people using 16bit software was relatively small AFAIK at that point.

But the page tables do technically support 16bit protected mode code when in compatibility mode under long mode AFAICT.

If the allegation that MS is locked to Qualcomm is true and the support of TSO as mentioned in other comments does not include any offering from the same my guess is MS hasn't bothered. They may yet if Qualcomm implements it.

I really wish Apple wasn't so secretive, this sort of thing makes an excellent tech talk at conferences.

Interesting, this is news to me. More curious that A64fx has it since that's an HPC chip. They must have a very valid reason for it (I've definitely run into HPC code that is absolutely garbage and would need it to be stable).

I think it's important to call out that Rosetta 2 on Apple silicon uses a special mode that changes how the memory model works to support x86 style memory ordering. That massively reduces the amount of work needed to emulate x86 and x86-64. Pretty sure apple both has a patent on it and a special dispensation from ARM to use it. Where qualcomm and MS don't have either. Which means emulation on Qualcomm CPUs is going to be painfully slow in comparison because it has to use a lot more locks and fences than is actually necessary with that mode available.