Hacker News Reader

Comment by stefan_ | Hacker News Reader

It's not that they couldn't do it, it's that LDM is a terrible instruction and was rightly removed in the cleanup that is arm64. See also: x86 LOOP...

View on HN

IDK, it's a fantastic instruction... for in order, cache poor designs. It's awful for the gate counts AArch64 is targeting though.

LOOP was a great instruction until Microsoft messed it up. If the instruction went fast enough, a timing loop in Windows got messed up, and Windows wouldn't boot. People would blame the CPU vendor for the bug, so LOOP was purposely made slow.

Intel do that with a lot of old instructions I.e. MMX and SSE instructions are really really fast on AMD but horrible on Intel. I guess this is to force people to upgrade to the latest and greatest AVX whatever.

Citation needed? I've never encountered that, and used plenty of those.

The main reason old instruction become slow is that the hardware implementation is replaced by a microcoded version.

MMX these days costs extra instructions on both AMD and Intel CPUs. This has been the case since SSE and SSE2 were introduced and later AVX extensions.

There quite possibly been a point in time where certain MMX instructions run faster on some AMD CPUs and required less uOps to achieve.

https://agner.org/optimize/ This is a pretty good source for uOps and instruction cycles.

This looks an interesting story that I tried to do Google it, but couldn't find any reliable source. Isn't it easy to do windows fix than processor hack?

I could find some reasons though here https://stackoverflow.com/questions/35742570/why-is-the-loop...

I recall that the affected OS was Windows 95. (could be 98) The first to hit the problem was AMD. Although not pre-internet, it nearly is, so finding info would be hard.

People didn't get automatic updates from fast always-on connections. Lots of people had slow dial-up connections. For some people, even that wasn't an option, so an update would require physical media.

I think this is the story referred to: http://www.os2museum.com/wp/those-win9x-crashes-on-fast-mach...

I mean, they couldn’t have kept it even if they wanted, since the bitmask itself would take up the entire instruction width. stp/ldp is there, though.

If it didn't have the other issues, there are various ways it might have been saved, for example having it operate on pairs of registers, or splitting it into separate instructions for the low half and high half.

nanoMIPS uses a counted contiguous range of registers in its version of this instruction.

TIL there’s a thing called nanoMIPS.

Tragically LOOP is alive and well in x86-64.

EDIT: Blergh, confused LOOP with REP, but keeping the below comment so the rest of the thread still makes sense.

FWIW LOOP isn't the worse thing in the world once you have dedicated silicon for it anyway generating micro ops in the instruction decode pathway. It's just a pretty cute run length encoding scheme for the instruction stream.

It's slow as sin, though. Just straight emulating it using more common instructions is like 4x better in most modern Intel CPUs. For some insane reason, it emits 8 uops on Skylake.

Sure, it doesn't matter anymore because anyone who cares is going through the vector unit to do bulk transfers. But there was issues with doing unaligned base and length memory transfers for the longest time, well through x86_64's original design.

are you confusing LOOP with the REP prefix?

I absolutely am, thanks!

There is a reason why loop is (was made) slow: It was (in the 90s) explicitly made slow because it was used for timing loops. Making it faster would have broken existing software.

Source: https://stackoverflow.com/a/35743699

The things you link to don't seem to say that at all, they seem to say it got slow because it was hard to implement and no-one cared about it.

"IIRC LOOP was used in some software for timing loops; there was (important) software that did not work on CPUs where LOOP was too fast (this was in the early 90s or so). So CPU makers learned to make LOOP slow."

"(My opinion: Intel is probably still making it slow on purpose, and hasn't bothered to rewrite their microcode for it for a long time. Modern CPUs are probably too fast for anything using loop in a naive way to work correctly.)"

It's also very fast on AMD (not any slower than the equivalent dec/jnz), so use it if you want your software to run faster on AMD and slower on Intel...

My gripe with LOOP and other crappy instructions is that they use up valuable space in the instruction encoding.

Reply on news.ycombinator.com