# EOF: Type Section Flags ###### tags: `EOF` TLDR: Currently the type section reserves some values, but doesn't allow specifying special cases of functions. One very useful special case needed is functions which do not return, because this allows a lot of optimisations and the introduction of `JUMPF`. Besides non-returning functions it is unclear what other special cases to expect. Some potential cases: - Purity levels (view or pure functions) - Which field to add? Input? - Initcode - Currently the first code section is the dedicated initcode - Anything else? Next we propose a number of options to support the above. **Q1:** Are these flags useful (besides non-returning functions)? **Q2:** Which option below is the best? ## Current type section entry This supports no "flags", but reserves certain bits in `inputs`/`outputs`/`max_stack_height`. | name | length | value | description | |---------------|----------|---------------|-------------| | types_section | variable | n/a | stores code section metadata | | inputs | 1 byte | 0x00-0x7F | number of stack elements the code section consumes | | outputs | 1 byte | 0x00-0x7F | number of stack elements the code section returns | | max_stack_height | 2 bytes | 0x0000-0x03FF | maximum number of elements ever placed onto the stack by the code section | | code_section | variable | n/a | arbitrary sequence of bytes | | data_section | variable | n/a | arbitrary sequence of bytes | ## Use special values in the `inputs`/`outputs`/`max_stack_height` In this case we use a specific value, like `0xff` in `outputs` to signal that it is non-returning. Unclear what special values to specify in the other fields. ## Reuse reserved bits as flags in `inputs`/`outputs`/`max_stack_height` We can use 1 bit of `inputs`, 1 bit of `outputs`, and 6 bits of `max_stack_height` (total 8 bits) as flags. We can extend this by most-significant bit meaning "special case", and then having 7 more bits for flags in each of `inputs` and `outputs` (Note that these special cases then are only available for functions that woudn't defining their inputs or outputs type.) Non-returning functions would be value `0x81` (`b10000001`) in `outputs`. Downsides are that there's no other part of the container that uses bit-packing, and it complicates parsing. ## Dedicated `flags` field with bit-packing We replace the type section design with the following: | name | length | value | description | |---------------|----------|---------------|-------------| | flags | 8 bits | 0x00-0xFF | | | inputs | 7 bits | 0x00-0x7F | number of stack elements the code section consumes | | outputs | 7 bits | 0x00-0x7F | number of stack elements the code section returns | | max_stack_height | 10 bits | 0x0000-0x03FF | maximum number of elements ever placed onto the stack by the code section | Total 32 bits, as in current spec. The upside is that separation of concerns is clear. The downside is that same as before, bit-packing is not used in EOF yet. ## Dedicated `flags` field without bit-packing We introduce an 8-bit `flags` field in the type section, without bit-packing. It accomplishes the same as above, but suddenly we are using more space than before. ## Multiple type section kinds In this option we take the current type section layout, but introduce multiple kinds: - `kind_types_regular_function` - `kind_types_non_returning_function` - `kind_types_view_function` - `kind_types_pure_function` This means that functions would be sorted by their flags and laid out such in the container. Note that this option doesn't allow mixing types/flags, i.e. a non-returning function cannot be pure/view.