Two idioms, zero new instructions
This lesson stacks two things you have already met. An enum is int-sized and adds nothing of its own to the generated code, from lesson 5, and a dense switch dispatches through a jump table, from lesson 1. Combine them into a switch over an enum-typed argument with consecutive values and the two never interfere. The enum is only renaming integers, so the dispatch matches what a switch on a plain int would emit.
Take paint(Brush b), which switches over an eight-value Brush enum (BRUSH_PEN, BRUSH_FILL, and so on) and returns a pixel cost per tool.
cmplwi r3, 7 # b arrives as a 4-byte int; bounds-check 0..7
bgt- .default
lis r4, table@ha
slwi r0, r3, 2 # b * 4 -> table index
addi r3, r4, table@lo
lwzx r0, r3, r0
mtctr r0
bctr # jump straight to the case for this brush
.case0: li r3, 10 blr # each arm is one li/blr...
.case1: li r3, 25 blr # ...the enum names left no trace
That cmplwi/lwzx/mtctr/bctr shape is the lesson 1 dispatch, down to the byte. What changed is the argument's type, and the enum type stays in the source and never reaches the object file. Your C labels the cases with enum names while the assembly works with their ordinals 0 through 7, and the li r3, N in each arm is the value that case returns.
Your task
Write cost_of(Tile t) to reproduce the assembly above. The Tile enum is provided in context. Eight dense enum values land in table form — read the li r3, N in each arm to recover what each tile costs.