Closed AndrewTolmach closed 1 year ago
Thanks Andrew! I've put in all but the last. Regarding that one, do you know how to set the eflags register directly? I think that would be needed for what you're proposing regarding the partial evaluation of the comparison. Or did you have something else in mind?
Re the last point: I actually had in mind partial evaluation earlier on, e.g. at the source level, which could, e.g. convert 2<3
to True
. (Of course, one would really also want to do if-simplification to get rid of the dead arms of conditionals that test constants.)
One could do something similar in patch-instructions, but only if it was allowed to match on multiple instructions at one time (e.g. convert cmpq $3,$2; jl
to jmp
). Obviously this is a bit fragile and may go beyond what you'd want to consider as a "patch." I don't see how to get an improvement over the current scheme if we can only match on the cmpq
in isolation; I believe there is an instruction (sahf
) that let you write the flags directly, but it requires loading %ah
first, so we'd still need two instructions.
I guess the larger point was just that students may (should?!) find it a bit odd that we up trying to generate code to perform a comparison at runtime whose outcome is known statically. No odder than adding 1+2 at runtime, of course!
Ahh, the partial evaluation earlier on makes perfect sense, thanks!
and
andor
is essential to get the desired short-circuit semantics.and
andor
as a source of nested conditionals, rather than talking about inlining.return
statement; the "conclusion of themain
function" is mysterious here; perhaps add a forward pointer to 5.11 ?