[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    emit_rm in MacroAssembler
From:       Thomas.Rodriguez () Sun ! COM (Tom Rodriguez)
Date:       2009-02-23 19:56:05
Message-ID: E3CA9B2C-4C81-417F-979F-6587EBA0DCB2 () Sun ! COM
[Download RAW message or body]

It certainly could be factored differently.  I've never been very  
happy with factoring strategy in the MacroAssembler.  It would be nice  
if there was some fairly rote translation from the description in the  
manual to the source code you should write but that may just be  
dreaming.  The tendency is to find a similar instruction and copy from  
that which is basically what I did.

tom

On Feb 23, 2009, at 11:44 AM, Christian Thalinger wrote:

> On Mon, 2009-02-23 at 11:26 -0800, Tom Rodriguez wrote:
>> They aren't structured the same at all.  I think you want something
>> like this for the 64 bit reg/reg:
>>
>>   emit_byte(0xF3);
>>   int encode = prefixq_and_encode(dst->encoding(), src->encoding());
>>   emit_byte(0x0f);
>>   emit_byte(0xb8);
>>   emit_byte(0xc0 | encode);
>>
>> The prefix* family of functions take care of emitting the proper REXs
>> and masking the registers down to 3 bits.  Use the regular
>> prefix_and_encode for popcntl.
>
> That's almost exactly what I did:
>
> +void Assembler::popcntl(Register dst, Register src) {
> +  //assert(VM_Version::supports_popcnt(), "must support");
> +  emit_byte(0xF3);
> +  int encode = prefix_and_encode(dst->encoding(), src->encoding());
> +  emit_byte(0x0F);
> +  emit_byte(0xB8);
> +  emit_byte(encode);
> +}
>
> But your code emits the correct instruction :-)  Shouldn't the 0xC0  
> part
> be in some kind of function?
>
> -- Christian
>



[prev in list] [next in list] [prev in thread] [next in thread]