Introduce MoveInteger64 instruction into X64 Macro Assembler

Introduce MoveInteger64 instruction into X64 Macro Assembler

[haitao.feng, 2013-11-07 13:37:22]

PTAL.

[danno, 2013-11-13 13:00:39]

Thanks for the patch, but I wonder why this is necessary? Won't MoveInteger64
also be movq on x32? If so, it seems like this change just adds syntactic sugar.
If so, then I'd rather just leave the code like it is.

[haitao.feng, 2013-11-14 08:45:18]

Danno, thanks for the review.

This change adds syntactic sugar as you mentioned in the email. In order to
translate x64 codes into x32 code, some movq should be changed to movl (related
to pointers), others are left intact (double, integer64 and return address).
This CL and https://codereview.chromium.org/26216008/ and
https://codereview.chromium.org/65723003/ make the intent (what movq does)
clear.  

After this change, all the other movq could be replaced by a Move macro
instruction where X64 uses movq and X32 uses movl. I have thought to use Macro
instruction to write all the assembler codes, if you prefer movq assembler
instruction, we could use it uniformly. I could revert
https://codereview.chromium.org/26216008/ and only introduce the Move macro
instruction discussed above.

On 2013/11/13 13:00:39, danno wrote:
> Thanks for the patch, but I wonder why this is necessary? Won't MoveInteger64
> also be movq on x32? If so, it seems like this change just adds syntactic
sugar.
> If so, then I'd rather just leave the code like it is.

[Toon Verwaest, 2013-11-25 12:17:13]

Would it be possible to use movp rather than MoveReturnAddress, and keep movq
rather than introducing MoveInteger64? Movp would just mov a platform-specific
pointer-sized value, while movq and movl would do what the name indicates.

If there's no other reason you introduced those specific Move* functions, I'd
prefer to not overspecify the intent. Otherwise we end up with lots of specific
macro instructions that add more noise than value.

[haitao.feng, 2013-11-25 12:42:16]

Hi Toon,

Thanks for the review. My origin intent is to introduce MoveDouble, MoveDouble
and MoveInteger64 (they all need 64-bit move instruction, an alternative is to
use MoveQuadWord, see https://codereview.chromium.org/26216008/), after that,
introduce a new Move macro instruction for all the other movq usage. For x64,
this new Move is implemented by movq and for X32, it is implemented by movl.

I am not sure movp is a right abstraction for all the other movq usages. For the
difference between x64 and x32:
    1) Nearly all the movq in the x64 port needs to be replaced with movl by the
script.
    2) 64-bit movq needs to be kept, they are doubles, integer64 and return
address. I have used __k annotation in the X64 code so the script does not
translate them into movl.

Thanks
-Haitao

On 2013/11/25 12:17:13, Toon Verwaest wrote:
> Would it be possible to use movp rather than MoveReturnAddress, and keep movq
> rather than introducing MoveInteger64? Movp would just mov a platform-specific
> pointer-sized value, while movq and movl would do what the name indicates.
> 
> If there's no other reason you introduced those specific Move* functions, I'd
> prefer to not overspecify the intent. Otherwise we end up with lots of
specific
> macro instructions that add more noise than value.

[haitao.feng, 2013-11-25 12:48:19]

For your information, the latest x32 port source code is at
https://github.com/fenghaitao/v8/tree/x32. I am now rebasing simd source codes
so that I could submit them to get your core team's high-level review comments.
After that, I will rebase x32 port to bleeding_edge.

[Toon Verwaest, 2013-11-25 14:37:25]

I prefer introducing high-level instructions that internally choose the correct
implementation, rather than using a script (and C++ macros) to selectively
replace instructions. Macros like __k and __n seem very error-prone to me.

At the same time, I think it's overkill to over-specify the semantics of certain
instructions (eg MoveReturnAddress). The move instruction itself doesn't care
that it's a return address, it just cares about the size. The offset does,
however, care that it needs to find the offset for a return address. So it made
more sense that the Operand was specific to the return address, rather than the
current Operand(rsp, 0). The same thing is true for this MoveInteger64. As danno
mentioned, movq seems fine since it'll always be 64bit.

And so that's what I meant with using movp; which I thought would mean either
movq on x64 or movl on ia32 (could be that I'm just confused and that we need
another name for that). For other cases, where it's either always 64bit or 32bit
independent of the architecture, we should just keep on using either movq or
movl; rather than introducing new copies such as MoveQuadWord.

So I wouldn't replace *all* movq by movp, but only those that have to either be
movq or movl. Those that are always movq stay movq.

Does this make sense?

[haitao.feng, 2013-11-27 05:41:24]

> So I wouldn't replace *all* movq by movp, but only those that have to either
be
> movq or movl. Those that are always movq stay movq.
> 
> Does this make sense?

Yes, this totally makes sense. Sorry for the late response as rebasing SIMD with
bleeding_edge took most of my time.

Firstly, I want to clarify that I have introduced movp in
https://codereview.chromium.org/64453002/. It will abstract the move pointer
instructions for X64 and X32. In the movp implementation, if the target is x64,
we use "emit_rex_64", and if it is x32, we have to use "emit_optional_rex_32" (I
will have to do this in the x32 branch of V8 in my github repository).

Secondly, if I follow your sentences correctly, we might be able to introduce
AssemblerEmittingMode for X64 assembler instruction, for example,
     enum AssemblerEmittingMode {
         ARCHITECTURE_DEPENDENT,
         ALWAYS_64_BIT,
         ALWAYS_32_BIT
     }    

and introduce move instruction with a default mode as ARCHITECTURE_DEPENDENT. It
will address most of the movq usage in the X64 code. When we have to use 64-bit
or 32-bit, we use ALWAYS_64_BIT or ALWAYS_32_BIT. What do you think?

Could we have some chat or phone call on the future collaboration? I am
haitao.feng@gmail.com at Gtalk.

[haitao.feng, 2013-11-27 12:11:56]

> Secondly, if I follow your sentences correctly, we might be able to introduce
> AssemblerEmittingMode for X64 assembler instruction, for example,
>      enum AssemblerEmittingMode {
>          ARCHITECTURE_DEPENDENT,
>          ALWAYS_64_BIT,
>          ALWAYS_32_BIT
>      }    
> 
> and introduce move instruction with a default mode as ARCHITECTURE_DEPENDENT.
It
> will address most of the movq usage in the X64 code. When we have to use
64-bit
> or 32-bit, we use ALWAYS_64_BIT or ALWAYS_32_BIT. What do you think?
Please ignore this part. We could use template to distinguish movl, movq and
move (or movp as you suggested). I uploaded a CL
https://codereview.chromium.org/91333002/ for your reference. If you are OK with
this, I will change movq extensively in the X64 port.