native: for in string

[Eliyaan]

• implements for ch in my_string
  (skips one of the new tests on windows, passing only with gcc)

[huly-for-github]

Connected to Huly®: V_0.6-22974

[spytheman]

Why use cmp_reg2 instead of cmp_reg here?

[Eliyaan]

because cmp_reg needs Amd64Register and not Register, so cmp_reg2 is a function that casts the Registers to Amd64Register and then calls cmp_reg. I did not change the cmp_reg function as it is already used in a lot of places, to avoid big changes. (same for pop and pop2)

[spytheman]

Is there a place, that will need to call the interface version, instead of the CPU specific one?
i.e. why does it need to be in the public interface at all?

[spytheman]

hm, there are a lot of calls to it fn (mut g Gen) for_in_stmt(node ast.ForInStmt) {, similar to this:

        g.code_gen.pop2(Amd64Register.rdx)
        g.println('; push address of the len:')
        g.code_gen.push(Amd64Register.rdx) // len
        g.code_gen.mov_deref(Amd64Register.rdx, Amd64Register.rdx, ast.int_type)
        g.code_gen.cmp_reg2(main_reg, Amd64Register.rdx)

That does not seem right to me - vlib/v/gen/native/stmt.c.v is supposed to have platform independent code, not pass the names of Amd64 specific registers around 🤔 .

[spytheman]

I think we should have something similar to:
main_reg := g.code_gen.main_reg()
for example:
sreg := g.code_gen.secondary_reg()
and then use that instead of Amd64Register.rdx in places, that are not supposed to be platform dependent.

[spytheman]

However, that cleanup is better indeed to be in its own separate PR, not here.

[Eliyaan]

I agree, I will clean this up when I'll have a better idea on how it could be organized in a cleaner way.

[spytheman]

why add pop2, instead of pop here?
There is no other pop method in the public interface, and it only has a single argument, not 2.

[spytheman]

Excellent work.

[medvednikov]

Yay!