I read in intel documentation the default conditional branch prediction policy: backward predicted taken, forward predicted not taken (at least the first time a conditional branch is encountered). Same than RISC-V.

But I am unable to find it in AMD CPU documentation, anybody?

Here. Chapter 7

So it seems AMD prediction default rule is different than the one from Intel and RISC-V: 7.9, no mention of forward or backward branches, namely AMD default prediction is only forward.

Meh. 2014, still valid nowdays?

This is probably worth a read: https://www.agner.org/optimize/microarchitecture.pdf

It looks like the Jan-2014 edition is the last one that is publicly available on the https://amd.com. There may be other editions, but I can't find anything.

AMD switched to a scheme where they produce optimization manuals for each new core. For example, the Zen5 manual is document 58455. If you follow people like InstLatX6 on bsky|X, they usually broadcast documentation updates - very helpful, imho.

Everything is gated by whatwg cartel web engines.

https://github.com/bitRAKE/amd_zen_sogs

Now I have them all in one place. Zen4 missing from latest AMD portal.

This is what we call "bringing the hammer down"

I skimmed 58455, and they hardly changed the conditional branch prediction: until a conditional branch is actually taken, it is always predicted not taken, without branch direction information. BUT, after being taken a first time, the second time the branch will be predicted taken.

This is different than Intel and RISC-V, then machine code will have to be different for many conditional branch use cases.

And yes, whatever the hardware micro-architecture, the cache line is paramount.

What is still very blurry in my mind: sorta common rules to manage BTB entries per cache lines.

The documentation reflects the complexity of the core(s).

I always have questions when I read something like: Zen5 reduced it to 16GB -- I guess to reduce the number of address bits in the BTB. WTF, is "limited number"? Testing here shows that number is three.

I told the AI to build a test case for any ambiguity or falsifiable claim. It's still working. (The testing methodology takes time to refine into something useful. Some cases will need additional tooling.)

How do you even cross a 16GB boundary WTF?

Other than calling into another library or whatever, which is not something you can control due to ASLR, so how can "software limit it"? Makes no fucking sense.

Not every application uses one of the main OSes (Windows, Linux, Mac). And the CPU makers don't care about ASLR or similar things, that isn't their problem. Their advice is if the chosen OS doesn't play nice with their CPU then use a different OS.

Huh? I have been thinking the BTB is actually dealing with "close code". Why do I recall something like 16MB (not GB)??

Of course, we can't forget this beautiful resource ...
https://kib.kiev.ua/x86docs/