3 ms·
Calls don't need to be predicted though since they're unconditional. So 16 call/ret pairs should only be 16 B2B entries.
by monocasa 2y ago
Calls don't need to be predicted though since they're unconditional. So 16 call/ret pairs should only be 16 B2B entries.
- IshKebab 2y agoYou can predict a dynamically dispatched call surely?
- colejohnson66 2y agoYou still need to predict the target if it’s indirect
- eigenform 2y agoModern machines usually try to predict target addresses, not just the direction of conditional branches. You can implement it for unconditional calls and jumps too, even for direct/relative-addressed ones. That's pretty common nowadays. When you calculate the target of a jump, you can cache it (that's what a BTB is). Next time you encounter it, you predict the target by accessing the cached value in the BTB and start fetching early instead of waiting for your jump/call to move all the way through the machine.
- phire 2y agoYou need to predict the target (with BTB) if want zero-bubble calls (1 cycle latency). Otherwise it takes 3 cycles (on the P550) to take a direct call. Doesn't matter that it's unconditional, it can't see the call until after decoding. Sure, it's only two extra cycles, but that's a full six instructions on this small 3-wide core. And an indirect call? Even if the target is known, it's going to need to fetch it from the register file, which requires going through rename. And unless you put a fast-path in with an extra register-file read-port, you need to go through dispatch and the scheduler too. Probably takes 6-10 cycles to take an indirect branch without a BTB. On bigger designs it's even more essential to predict unconditional branches, as their instruction caches take multiple cycles, and then there are quite substantial queues between fetch and decode, and between predict and fetch.