MMX assembler doesnt like const.

-------------------
const int foo = 1;
asm mov EAX,foo;

compiles ok.

----------------------
ulong foo = 1;
asm movd MM0,foo;

compiles ok.

-----------------------
const ulong foo = 1;
asm movd MM0,foo;

complains "bad type/size of operands 'movd'"

So simply changing the variable to const, breaks mmx's ability to use it. but the same thing is not true when using normal int registers.

cw

"Chris Warwick" <sp@m.me.not> wrote in message news:et24ga$1ppn$1@digitalmars.com...
> MMX assembler doesnt like const.
>
> -------------------
> const int foo = 1;
> asm mov EAX,foo;
>
> compiles ok.
>
> ----------------------
> ulong foo = 1;
> asm movd MM0,foo;
>
> compiles ok.
>
> -----------------------
> const ulong foo = 1;
> asm movd MM0,foo;
>
> complains "bad type/size of operands 'movd'"
>
> So simply changing the variable to const, breaks mmx's ability to use it. but the same thing is not true when using normal int registers.

Are you sure that you can move immediates into MMX registers with movd? Everything I've found only says that movd moves from reg to MMX or from MMX to reg..

Chris Warwick wrote:
> MMX assembler doesnt like const.
> 
> -------------------
> const int foo = 1;
> asm mov EAX,foo;
> 
> compiles ok.
> 
> ----------------------
> ulong foo = 1;
> asm movd MM0,foo;
> 
> compiles ok.

Really?  That's odd...

> -----------------------
> const ulong foo = 1;
> asm movd MM0,foo;
> 
> complains "bad type/size of operands 'movd'"

Yup, yup.

> So simply changing the variable to const, breaks mmx's ability to use it. but the same thing is not true when using normal int registers.
> 
> cw

I can't be sure, since I haven't written any MMX code in a while, but...

movd.  As in DWORD.  As in 32-bits.  ulong is 64.  Have you tried movq? :P

Maybe the reason this is happening is because it's only taking the first 32-bits of your non-cost ulong foo, whereas if you try to use a 64-bit immediate, it actually throws up an error saying "are you sure you mean that, because that don't fit".

That said, I don't think I ever tried to load a ulong const... there's a few static ones in there, but no consts.

Anyway, give movq a shot.  Never know :)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Apologys for the previous jibberish.. i've been on honeymoon with D for the last 4 days and havn't had much sleep lol.. So the problem is still there i just wrote out the examples wrong.. getting my movd's and movq's all mixed up.. Anyway copy and past this time so i dont feck up...

private ulong MMXZERO = 0x0;
    movq       MM0,MMXZERO;

compiles fine, as expected.

But the addition of 'const'

private const ulong MMXZERO = 0x0;
    movq       MM0,MMXZERO;

causes "bad type/size of operands 'movq'"

cheers

cw

On Mon, 12 Mar 2007 01:43:34 -0000, Chris Warwick wrote:

> Apologys for the previous jibberish.. i've been on honeymoon with D for the last 4 days and havn't had much sleep lol.. So the problem is still there i just wrote out the examples wrong.. getting my movd's and movq's all mixed up.. Anyway copy and past this time so i dont feck up...
> 
> private ulong MMXZERO = 0x0;
>     movq       MM0,MMXZERO;
> 
> compiles fine, as expected.
> 
> But the addition of 'const'
> 
> private const ulong MMXZERO = 0x0;
>     movq       MM0,MMXZERO;
> 
> causes "bad type/size of operands 'movq'"
> 
> cheers
> 
> cw

The MMX instruction 'movq' requires that the source/destination is either MMX register or an address of a 64-bit value, except that both can't be addresses. I believe that the DMD compile optimizes the 'const' value to be a literal zero so you end up with ...

   movq, MM0,0x0

which is not allowed.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

"Derek Parnell" <derek@psych.ward> wrote in message news:1898vpzduavha.1b2w76ic8zmeg.dlg@40tude.net...
> On Mon, 12 Mar 2007 01:43:34 -0000, Chris Warwick wrote:
>
>> Apologys for the previous jibberish.. i've been on honeymoon with D for
>> the
>> last 4 days and havn't had much sleep lol.. So the problem is still there
>> i
>> just wrote out the examples wrong.. getting my movd's and movq's all
>> mixed
>> up.. Anyway copy and past this time so i dont feck up...
>>
>> private ulong MMXZERO = 0x0;
>>     movq       MM0,MMXZERO;
>>
>> compiles fine, as expected.
>>
>> But the addition of 'const'
>>
>> private const ulong MMXZERO = 0x0;
>>     movq       MM0,MMXZERO;
>>
>> causes "bad type/size of operands 'movq'"
>>
>> cheers
>>
>> cw
>
> The MMX instruction 'movq' requires that the source/destination is either
> MMX register or an address of a 64-bit value, except that both can't be
> addresses. I believe that the DMD compile optimizes the 'const' value to
> be
> a literal zero so you end up with ...
>
>   movq, MM0,0x0
>
> which is not allowed.

Should it really be optimizing typed constants like that, especialy with asm?

is it worth me bring this issue up somewhere?

cheers,

cw

Chris Warwick wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:1898vpzduavha.1b2w76ic8zmeg.dlg@40tude.net...
>> On Mon, 12 Mar 2007 01:43:34 -0000, Chris Warwick wrote:
>>
>>> Apologys for the previous jibberish.. i've been on honeymoon with D for the
>>> last 4 days and havn't had much sleep lol.. So the problem is still there i
>>> just wrote out the examples wrong.. getting my movd's and movq's all mixed
>>> up.. Anyway copy and past this time so i dont feck up...
>>>
>>> private ulong MMXZERO = 0x0;
>>>     movq       MM0,MMXZERO;
>>>
>>> compiles fine, as expected.
>>>
>>> But the addition of 'const'
>>>
>>> private const ulong MMXZERO = 0x0;
>>>     movq       MM0,MMXZERO;
>>>
>>> causes "bad type/size of operands 'movq'"
>>>
>>> cheers
>>>
>>> cw
>> The MMX instruction 'movq' requires that the source/destination is either
>> MMX register or an address of a 64-bit value, except that both can't be
>> addresses. I believe that the DMD compile optimizes the 'const' value to be
>> a literal zero so you end up with ...
>>
>>   movq, MM0,0x0
>>
>> which is not allowed.
> 
> Should it really be optimizing typed constants like that, especialy with asm?
> 
> is it worth me bring this issue up somewhere?
> 
> cheers,
> 
> cw

'const' doesn't mean the same as in C++. A const is a constant, not a variable. You cannot take the address of a const; in many ways it's more like a #define. In theory, the const may not even be allocated any storage space at all in the final executable. (In practice, I think it always is, but I hope that changes eventually).

"Don Clugston" <dac@nospam.com.au> wrote in message news:et3rdl$1bhc$1@digitalmars.com...
> Chris Warwick wrote:
>> "Derek Parnell" <derek@psych.ward> wrote in message news:1898vpzduavha.1b2w76ic8zmeg.dlg@40tude.net...
>>> On Mon, 12 Mar 2007 01:43:34 -0000, Chris Warwick wrote:
>>>
>>>> Apologys for the previous jibberish.. i've been on honeymoon with D for
>>>> the
>>>> last 4 days and havn't had much sleep lol.. So the problem is still
>>>> there i
>>>> just wrote out the examples wrong.. getting my movd's and movq's all
>>>> mixed
>>>> up.. Anyway copy and past this time so i dont feck up...
>>>>
>>>> private ulong MMXZERO = 0x0;
>>>>     movq       MM0,MMXZERO;
>>>>
>>>> compiles fine, as expected.
>>>>
>>>> But the addition of 'const'
>>>>
>>>> private const ulong MMXZERO = 0x0;
>>>>     movq       MM0,MMXZERO;
>>>>
>>>> causes "bad type/size of operands 'movq'"
>>>>
>>>> cheers
>>>>
>>>> cw
>>> The MMX instruction 'movq' requires that the source/destination is
>>> either
>>> MMX register or an address of a 64-bit value, except that both can't be
>>> addresses. I believe that the DMD compile optimizes the 'const' value to
>>> be
>>> a literal zero so you end up with ...
>>>
>>>   movq, MM0,0x0
>>>
>>> which is not allowed.
>>
>> Should it really be optimizing typed constants like that, especialy with asm?
>>
>> is it worth me bring this issue up somewhere?
>>
>> cheers,
>>
>> cw
>
> 'const' doesn't mean the same as in C++. A const is a constant, not a variable. You cannot take the address of a const; in many ways it's more like a #define. In theory, the const may not even be allocated any storage space at all in the final executable. (In practice, I think it always is, but I hope that changes eventually).

ah ok, thanks.

cw