Why do RET instructions have a REPZ prepended on x86?

by luu • 13 years ago

174 34 13 years ago

simcop2387• 13 years ago

Things like this are why I got out of writing ASM for anything back in the 1990s. It's gotten to the point where while a tight loop might be doable by a person in a performant way, anything else might entirely be far too complicated to make it perform well all over. Along with that you can't make it portable on other architectures.

derleth2• 13 years ago

Along with that you can't make it portable on other architectures.

Not only that, but it seems from other stuff I've read that you'd have a hard time making x86 code performant on more than one microarchitecture or family thereof, which means re-writing the same code for different manufacturers and different generations from the same manufacturer.

It seems that if you accept the façade that says "x86 is x86" you're better off writing in C or even Haskell, but if you peel the façade back to write fully performant code you're doomed to either keep re-writing it or doomed to see it languish as processor technology moves on.

I'm immediately reminded of the early RISC design concept of "moving the microcode into the compiler"; having extremely simple hardware that explicitly exposed design details like pipeline length in the form of delay slots becoming ISA features and saying that compilers would handle all the resulting complexity much like how microcode handled it in the System/360 and similar.

It turns out architectural branch delay slots were a mistake, but compilers have gotten better at turning obvious source code into performant machine code unless you need so much performance you have to dig into architectural details anyway.

It's unavoidably complicated. And now we're moving towards multi-core CPUs, which bring to the fore another area which is unavoidably complicated.

wtallis• 13 years ago

I think delay slots and similar tricks have been abandoned not because they failed to enable high performance, but for pragmatic and business reasons: the details end up changing every 2-3 years, so you need to re-compile all your code, and it takes 2-3 years for the compiler to get good and stable.

onan_barbarian2• 13 years ago

This is spot on. We use a lot of intrinsics, as we want to get at some of the underlying features of the architecture, but we almost never write asm. It's becomes obsolete almost immediately and is often far worse than the compiler's first cut.

We had a former performance guru who once put a huge #ifdef I_DONT_CARE_ABOUT_PERFORMANCE around the "naive" C version of a loop and had his favourite x86 asm version on the #else branch of the ifdef. Needless to say, much hilarity resulted when defining this macro improved performance. I suspect that the naive version may have been a bad idea at one stage (Pentium 4, perhaps) but became a better version from Core 2 onwards...

Ocassionally I'll get on a wild tear and think "Oh, I can do better than the compiler" after it generates some ridiculous-looking instruction sequence that seems to not be using enough registers (or whatever). I then find that hand-writing and hand-scheduling everything in accordance to what looks really good to me - actually works worse than the insane-looking code in the compiler. Put it down to stuff like store-to-load forwarding, dynamic scheduling, register renaming, etc.

nly• 13 years ago

It seems that if you accept the façade that says "x86 is x86" you're better off writing in C

Sure... but also remember that most C code ends up having to be compiled for the lowest common denominator. All your x86 Linux distro binaries for instance will be compiled for 'generic' x86-64, i.e. something compatible with the 10 year old AMD64 3000+.

Ok, well you say... we can just turn on arch specific compiler options: -msse4.2 -march=core2 etc, and this is true, but there's still less incentive for compiler programmers to produce wonderful transforms and optimisations utilising SSE 4.2 and AVX2, or a very specific target pipeline/behaviour, than there is for generic optimisations that can be applied across platforms or processor families. In fact a lot of SSE code generated by compilers is fairly rudimentary even with these options.

Part of the 'problem' really is we have this model where x86 CPUs are being engineered with additional complexity to run old code faster, even though a lot of that old code generally doesn't need that performance. You only have to look at some of the other architectures to see some interesting approaches that x86 has ignored.

Perhaps we need to be more of the mindset that recompiling code when moving from AMD64 to Core2 is as obvious as recompiling it when moving from ARM to x86.

bookface2• 13 years ago

This was really interesting, but one thing it didn't fully explain was why the fact that ret imm16 was fastpathed would make it a worse choice for this optimization than repz ret. Excuse my noobiness, but can anybody explain that to me?

Someone• 13 years ago

"in the K10 family, the ret imm16 instruction is now fastpathed"

I understand that as follows: on the K8 both repz ret and ret imm16 were microcoded; hence, the shorter repz ret was preferred.

On the K10, ret imm16 got fastpathed. That made it the preferred code, even though it is a byte longer.

bookface2• 13 years ago

Ah, thanks. I missed that that whole part was talking about the K10.

rayiner3• 13 years ago

Each cycle, a modern x86:

- Fetches 16-32 bytes

- Finds instruction boundaries (because of variable-length encoding)

- Branch predicts any branches in the fetch group

- Decodes 3-4 instructions in the fetch group

- Issues 3-4 decoded operations to the rest of the pipeline

This whole process has to happen every cycle (though it's pipelined over 3-5 cycles in the front end), and the performance of this process gates the rest of the pipeline. As a result, many of the micro-architectural "gotchas" in modern x86 processors tends to be in the fetch/decode phase.

onan_barbarian2• 13 years ago

You are overgeneralizing. Being front-end bound is true for some code but not for others.

We see our gotchas typically in terms of not being able to issue instructions due to data dependencies and filling up the RS with things that can't make progress (informally, a big tree of "ORs" where one source for everything has missed L1 and held everyone else up).

Other people will be hopelessly bound on cache or memory bandwidth, or floating point multiply, or whatever. Or disk access :-)

If one is curious about whether this applies to one's own code, you don't have to speculate - just bust out the Optimization Guide (http://www.intel.com/content/www/us/en/architecture-and-tech...) and go figure out where your bottlenecks are by looking at counters. VTune can do some of this stuff for you.

rayiner3• 13 years ago

I'm speaking from an architectural design standpoint. Exceeding the ability of the OOO engine to cover cache misses isn't a "gotcha" it's a design limit of the hardware. Being able to only predict three branches in a 16-byte fetch group, even though more than 3 branches can fit in a 16-byte stretch of code, is a gotcha. Being able to execute only 3 SSE operations per cycle is a design limit. Not being able to hit 3 SSE operations per cycle depending on which registers you use and how many prefix bytes they require to encode is a gotcha.

pbsd• 13 years ago

Modern Intels also cache decoded uops to alleviate this. So if your (say) main loop is less than about 1500 uops, decoding performance becomes less relevant. This is particularly important for SIMD instructions, which are often quite large (> 5 bytes) and thus can easily bottleneck on the decoding step.

iso-8859-1• 13 years ago

It's fortunate, since it made Intel able to encode the new XACQUIRE/XRELEASE of the Transactional Synchronization Extensions' Hardware Lock Elision using these short ancient prefixes:

"Hardware Lock Elision adds two new instruction prefixes XACQUIRE and XRELEASE. These two prefixes reuse the opcodes of the existing REPNE/REPE prefixes (F2H/F3H). On processors that do not support TSX, REPNE/REPE prefixes are ignored on instructions for which the XACQUIRE/XRELEASE are valid, thus enabling backward compatibility."

from http://en.wikipedia.org/wiki/Transactional_Synchronization_E...

kps• 13 years ago

And REPNE RET, among others, similarly has an interpretation in Intel® Memory Protection Extensions (lawyers made me write that) to help make the new pointer bounds checking ABI transparent & interoperable with other code.

[1] http://software.intel.com/en-us/articles/introduction-to-int... [2] http://download-software.intel.com/sites/default/files/31943...

ballard• 13 years ago

Deep pipelines, single cycle RISC and the history of MIPS (eg Hennessy is a badass)

http://en.m.wikipedia.org/wiki/MIPS_architecture#History

rbanffy2• 13 years ago

And there are people who say the x86 ISA is just fine, that such kludges are absolutely normal...

I get the x86 is immensely successful, but being popular is not synonymous with being well engineered. Or engineered.

tristanj• 13 years ago

This is an issue with AMD's branch predictor, not with the x86 ISA. The code would work fine with a single "ret" instead, however people found using "rep ret" made it nanoseconds faster. it just shows how you can find optimizations in the most unexpected of places.

rbanffy2• 13 years ago

Good point. This is not ISA-mandated behavior, but an implementation quirk.

ajross• 13 years ago

Right, because ARM cores exhibit completely predictable behavior with, say, assignments to IP or instruction predicate bits?

All architectures are insane. MIPS, probably the epitome of a minimal/clean architecture, still has a vestigial 1980's pipeline stage (the branch delay slot) baked right into the ISA such that it can never be removed.

Is the x86 ISA a big mess? Yeah. But ARM is hardly better (anyone remember Jazelle?) Basically, if you don't want to look at the assembly stick to your compiler. That's what it's there for. But don't pretend that this stuff isn't present everywhere -- real engineering involves tradeoffs.

simias• 13 years ago

As someone who's fought for months with the ARM cortex-a9 cache prefetch behaviour and behaviour of the various memory attributes (not intuitive and only partially documented), I wholeheartedly agree with you.

Those are bits of hardware which are supposed to run around GHz speeds, they might look clean enough on the surface but when you dig deep enough "hic sunt dracones".

rayiner3• 13 years ago

x86 is great. You'll absolutely see kludges on RISC architectures (e.g. anything having to do with loading a 32-bit or 64-bit constant into a register). Then you have branch delay slots on MIPS, instruction alignment issues on certain PPC processors (G5), etc.

One of the nice things about x86 is that while the encoding is a little wonky, the semantics are great. No imprecise exceptions, no branch delay slots, strong memory ordering, etc. The last one in particular is absolutely wonderful in this day and age of multicore processors (scumbag RISC: makes you use memory fences everywhere; makes memory fences take 300 cycles).

diydsp• 13 years ago

While we're at it, why did Ahmed Bougacha register an entire domain for this topic?!?! (srsly, I'm wondering if he's just super-passionate about this topic and had the resources to spare? Is this the beginning of a much larger set of questions related to the topic, etc.? )

qikon• 13 years ago

Both! I have plenty of drafts in the area. Right now I’m working on binary analysis / translation / decompilation using LLVM (I’m actually gearing up for an RFC/patch on the mailing list): http://dagger.repzret.org. If you’re curious, I gave a talk at the LLVM Euro conference about the kind of problems you’d have, and some interesting use cases.

We’ve been quiet ever since, I’ll get back to writing about the meat once we have something out there, and more feedback from the community!

elmindreda• 13 years ago

This is why I like having compilers.

Why do RET instructions have a REPZ prepended on x86?

Related Stories