Render switch discriminant once per group; drop dead inner scope (#253)
* Render switch discriminant once per group; drop dead inner scope
The optimized Ok() switch-block code in _generate_optimized_ok_method_body
was rendering each switch group's discriminant twice: once unscoped at
grouping time to build the SWITCH: key, and again with the active
ExpressionScope at emit time. Render it once with the scope and reuse
the result. The result is stable for equivalent discriminants because
ExpressionScope.add dedupes by inner rendered form, so it still works
as a grouping key.
The ok_method_switch_block template's \${inner_scope_definitions}
placeholder was unused — the inner ExpressionScope it referenced had
nothing added to it. Removed both, which also drops the blank line
each switch block carried in the goldens.
No behavioral change; purely compile-time cleanup. Golden churn
limited to the blank-line removal in four files (one line per existing
switch block).
* Sort switch cases by value; coalesce identical-body cases (#254)
Three composing changes to the optimized Ok() switch generator:
1. Case-label sort. Each switch arm's labels are sorted by the
underlying integer/enum value before emit. _case_sort_key()
returns the int for sorting. Sorted cases give older embedded
GCCs (the ones shipped with microblaze-elf and many bare-metal
arm-none-eabi toolchains) a better shot at emitting a dense
jump table rather than an if-ladder.
2. Identical-body coalescing. Cases whose rendered body text is
identical (same field set in the same order) are merged into a
single arm with multiple \`case X:\` labels. The C++ compiler
emits one body for the whole arm — a real text-size win once a
later PR (disjunction matching) starts producing such pairs.
3. Multi-field per case. When two conditional fields share a
discriminant + case value (\`if tag == 0: a\` and \`if tag == 0: b\`),
they're now bundled into the same case arm rather than the second
falling back to a separate if-statement. Each field's validation
becomes one line of the case body.
The ok_method_switch_case template becomes ok_method_switch_arm,
taking pre-formatted \${case_labels} and \${case_body} strings.
Single-label single-field arms render identically to the old
template, so golden churn is limited to the f0_copy field in
testdata/many_conditionals.emb folding into case 0 of the
LargeConditionals switch.Emboss is a tool for generating code that reads and writes binary data structures. It is designed to help write code that communicates with hardware devices such as GPS receivers, LIDAR scanners, or actuators.
Emboss takes specifications of binary data structures, and produces code that will efficiently and safely read and write those structures.
Currently, Emboss only generates C++ code, but the compiler is structured so that writing new back ends is relatively easy -- contact emboss-dev@google.com if you think Emboss would be useful, but your project uses a different language.
If you're sitting down with a manual that looks something like this or this, Emboss is meant for you.
Emboss is not designed to handle text-based protocols; if you can use minicom or telnet to connect to your device, and manually enter commands and see responses, Emboss probably won't help you.
Emboss is intended for cases where you do not control the data format. If you are defining your own format, you may be better off using Protocol Buffers or Cap'n Proto or BSON or some similar system.
In C++, packed structs are most common method of dealing with these kinds of structures; however, they have a number of drawbacks compared to Emboss views:
Emboss does not help you transmit data over a wire -- you must use something else to actually transmit bytes back and forth. This is partly because there are too many possible ways of communicating with devices, but also because it allows you to manipulate structures independently of where they came from or where they are going.
Emboss does not help you interpret your data, or implement any kind of higher-level logic. It is strictly meant to help you turn bit patterns into something suitable for your programming language to handle.
Emboss is currently under development. While it should be entirely ready for many data formats, it may still be missing features. If you find something that Emboss can't handle, please contact emboss-dev@google.com to see if and when support can be added.
Emboss is not an officially supported Google product: while the Emboss authors will try to answer feature requests, bug reports, and questions, there is no SLA (service level agreement).
Head over to the User Guide to get started.