For the solution of your trivial example, see the answer of @rce.
However, achieving a proper understanding of a more realistc, fairly complex assembler code and convert it into HL-code, you should be sure that your reversing produced not only understandable, but also correct HL-code.
"Correct" means here that the original assembler code and the HL-code produce the same results, which you can verify e.g. by letting them run in two instances of IdaPro, each with the debugger running, and comparing after each significant step for correctness.
You could proceed like so:
Convert the assembler code in "Assembler-like" C code, just as you did it in your question.
Simplify it. Try to get rid of constructs specific for the assembler version and convert it into a more "C" natural form. This is what @rce did in his answer.
Try to understand the logic behind the constructs. Change the "register-like" variable names to "speaking" names connected to the logical meaning of the code. This is not possible from your example as you only provide two(!) lines of assembly code.
Re-write the whole thing step-by-step in logical terms only.
Always compare whether the output is correct. Even if steps 1 to 4 could be realized differently, this step is indispensible.
As this seems tedious, for more complex algorithms (which cannot be recognized by other means like the use of known "magic numbers"), this can be a successful strategy for a proper reverse engineering of non-trivial assembler code. It can become difficult, e.g. if you have "flattened" code or algorithms which contain vectorized code realized with intrinsics.