I used that as an example of a bad idea; I don't have details on this bad idea but you could have an instruction looking at an init, bound and increment registe

I used that as an example of a bad idea; I don't have details on this bad idea but you could have an instruction looking at an init, bound and increment registers and a constant telling where the loop ends and voila, the processor runs for loops without needing lower-level increment and branch instructions, and it shaves off one instruction (not a cycle, necessarily, but an instruction): FOR counter_reg, init_val_reg, bound_reg, step_reg, END_OF_LOOP ... END_OF_LOOP: ...instead of: MOVE counter_reg, init_val_reg START_OF_LOOP: ... ADD counter_reg, step BRANCH_LESS_THAN counter_reg, bound_reg, START_OF_LOOP I was saying that this obviously not-so-good idea is not much different in spirit from building hardware for quickly creating and applying lambda terms, which is what the Reduceron does. Lowering lambda calculus to simpler operations so that lambda expressions are not represented in a runtime data structure at all much of the time, the way GHC and other compilers approach the problem, is a better idea.