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

Drop FPU state on REPLY? #4

Open
blitz opened this issue Feb 5, 2013 · 0 comments
Open

Drop FPU state on REPLY? #4

blitz opened this issue Feb 5, 2013 · 0 comments
Labels

Comments

@blitz
Copy link

blitz commented Feb 5, 2013

We currently never assume that FPU state is preserved across a call to REPLY and a subsequent entry through a portal. The way the code is structured would even make it very hard to find a good usecase for accessing the FPU state left from servicing the last portal call.

Would it make sense to change the semantics of REPLY to not preserve FPU state, i.e. setting fpowner = nullptr on REPLY? It should save a call to fpu->save() in a lot of cases, with no ill side effects, except for the minor tidbit that when a EC accesses the FPU upon serving a subsequent portal call, it will see stale content (if it were to look, which it isn't...).

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

No branches or pull requests

1 participant