Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The specific implementation principle of the implicit return mode #103

Open
zhangdujiao opened this issue Apr 25, 2024 · 0 comments
Open

Comments

@zhangdujiao
Copy link

Every time a call instruction is encountered, the predicted return address (obtained through iaddr, iretire, and ilastsize) is pushed onto the stack. Every time a return instruction is encountered, it is matched with the predicted address on the stack, and then it is determined whether the prediction is correct. If it is correct, no packet is sent. If it is incorrect, a packet containing the address is sent, right?

These paragraphs below in 7.6.3. Format 2 irreport and irdepth are not very well understood:

"In some cases it is also necessary to report the current stack depth or call count if the packet is reporting the last instruction before an exception, interrupt, privilege change or resync. There are two cases of concern:
• If the reported address is the instruction following a return, and it is not mis-predicted, the encoder must report the current stack depth or call count if it is non-zero. Without this, the decoder would attempt to follow the execution path until it encountered the reported address from the outermost nested call;
................
• If the reported address is not the instruction following a return, the encoder must report the current stack depth or call count unless:
◦ There have been no returns since the last call (in which case the decoder will correctly stop in the innermost call), or
◦ There has been at least one branch since the last return (in which case the decoder will correctly stop in the call where there are no unprocessed branches)."

Can you help me make it clear? It's a little bit hard for me to understand this from the Decoder point of view.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant