Skip to content

Eli suggestions #1

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

Open
wants to merge 3 commits into
base: armdev
Choose a base branch
from
Open

Eli suggestions #1

wants to merge 3 commits into from

Conversation

orinatic
Copy link
Collaborator

I've got three seperate commits of things that might be good ideas (to varying extents)

I wouldn't suggest actually taking any of them directly, since I did them more for ease-of-explanation than with intent that they would actually be correct -- I didn't exactly check them to make sure I didn't miss anything/I don't really understand the code enough to say for sure I'm not breaking something with any of these

Eli Davis added 3 commits June 15, 2021 12:46
I'm not sure this is actually better than current setup, but it does
allow you to avoid passing some strings around

I'm not sure how to test this code, so you'd want to take this as
a starting point/make sure I got it right, rather than just merging
this
If you want to check if it's a specific architecture, just do
`isinstance(app, X86Access)` or whathaveyou.

This has the advantage of telling the type system the type
you're looking at -- if you do that, you can do app.x86dictionary
without having to assert that it's an X86Access or cast to x86Access
or something
be replaced with isinstance checks

I did them for x86SimulationState's set_register and set, but I think
if you did it for the rest of the SimLocation stuff, you'd avoid a
looot of casts.

I think you could probably go so far as to remove the is_<foo> methods
entirely, but that's totally up to you

Note that if you're suuuuper concerned with performance of the python,
you miiight want to disregard this one? I think the bool-check cast
is going to be ever so slightly faster? But if you're super concerned
with performance, this stuff should probably just be in ocaml :P
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

Successfully merging this pull request may close these issues.

1 participant