Skip to content

lll: do not expose push/dup/swap/jumpdest as functions#3005

Merged
axic merged 1 commit intodevelopfrom
lll-instruction
Oct 2, 2017
Merged

lll: do not expose push/dup/swap/jumpdest as functions#3005
axic merged 1 commit intodevelopfrom
lll-instruction

Conversation

@axic
Copy link
Contributor

@axic axic commented Oct 2, 2017

Depends on #3004.

They are still available in assembly: (asm 0 DUP1 SWAP2)

@axic
Copy link
Contributor Author

axic commented Oct 2, 2017

The reason here is that none of these can be used meaningfully as each function starts its own stack frame and that means the only way to call it is (SWAP2 0 1) which is translated into PUSH 1 PUSH 0 SWAP2

@axic axic requested review from chfast and pirapira October 2, 2017 10:57
@axic
Copy link
Contributor Author

axic commented Oct 2, 2017

Hm, should this include jump/jumpi too?

bool validFunctionalInstruction(string us)
{
auto it = c_instructions.find(us);
if (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what's more readable, but in general if you are returning bool you don't need to wrap bool expression with if.


namespace
{
bool validFunctionalInstruction(string us)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function assumes the us is a valid instruction name. This precondition should be at least put in a comment.

Alternatively, you can handle also invalid instructions and reduce the condition in else if (c_instructions.count(us) && validFunctionalInstruction(us)).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handle as in? They do not make sense to be exposed as macros (aka "functions").

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handle as if (it == c_instructions.end()) return false;.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it can be added, though the callee does that already (via count(us)). A comment will not hurt anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm suggesting to actually remove count(us) on the callee side. Use only validFunctionalInstruction().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For readability purposes I'm not sold to remove it from the caller side.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But did simplify it according to suggestions.

@axic axic force-pushed the lll-instruction branch from 78238ea to a29345b Compare October 2, 2017 14:51
if (!c_instructions.count(us))
return false;
auto it = c_instructions.find(us);
return !(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively if (it == nullptr) return false; could remove the need of count()?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Precisely: if (it == c_instructions.end()). See http://en.cppreference.com/w/cpp/container/map/find "return value" section.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@axic axic force-pushed the lll-instruction branch from a29345b to 2be1555 Compare October 2, 2017 15:15

namespace
{
/// Returns true iff the instruction is valid as a function. Assumes @a us is not nullptr.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but Assumes @a us is not nullptr. is wrong. The string cannot be nullptr, but can be empty. Anyway, there are not assumptions about the argument, because .find() will work for any input.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated :)

@axic axic force-pushed the lll-instruction branch from 2be1555 to cbd4465 Compare October 2, 2017 15:21
@axic axic merged commit 91b20b4 into develop Oct 2, 2017
@axic axic deleted the lll-instruction branch October 2, 2017 19:47
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.

2 participants