Skip to content

Conversation

@pdobacz
Copy link
Member

@pdobacz pdobacz commented Apr 23, 2025

No description provided.

@pdobacz pdobacz requested review from gumb0 and shemnon April 23, 2025 12:20
@pdobacz pdobacz self-assigned this Apr 23, 2025
spec/eof.md Outdated
- Stack validation of `JUMPF` depends on "non-returning" status of target section
- `JUMPF` into returning section (can be only from returning section): `stack_height_min == stack_height_max == type[current_section_index].outputs + type[target_section_index].inputs - type[target_section_index].outputs`
- `JUMPF` into returning section (can be only from returning section): `stack_height_min == stack_height_max == type[current_section_index].outputs + type[target_section_index].inputs - type[target_section_index].outputs`.
**NOTE**: This means `JUMPF` must ensure target's inputs, must ensure its own outputs (to return control), but must take into account that the target section may leave extra output items after it finishes, so it may need that many fewer items on the operand stack
Copy link
Member

Choose a reason for hiding this comment

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

"must ensure" is duplicated here

Consider taking explanation from the EIP:

This means that target section can output less stack elements than the original code section called by the top element on the return stack, if the current code section leaves the delta type[current_section_index].outputs - type[target_section_index].outputs element(s) on the stack.

Copy link
Member

Choose a reason for hiding this comment

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

Generally EIPs have more explanations than mega-spec, and I'm not sure we have to repeat everything here.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, I'm not a fan of that particular explanation, not sure if what I proposed is better though :/.

As to:

Generally EIPs have more explanations than mega-spec, and I'm not sure we have to repeat everything here.

I believe it is useful. Some people still prefer to read the mega-spec and should not be confused by it. EIPs have Rationale and Motivation, which we do not repeat, but I guess some more unobvious passages of the spec will benefit from extra prose

Copy link
Member Author

Choose a reason for hiding this comment

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

I updated the wording a little bit. LMK if you prefer the EIP one after all

@pdobacz pdobacz requested a review from gumb0 April 28, 2025 10:56
@pdobacz pdobacz closed this May 7, 2025
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.

3 participants