paddq regression

[V Coder]

Greetings Randy,

HLA is excellent.

I only recently discovered a paddq regression which causes my program to fail compilation with an error. I have not updated the program for months, but now I cannot test the latest new featres since in HLA:

   paddq ([esi+mda], mm4);

Error in file "palchk3.0alpha0.hla" at line 1635 [errid:72428/hlaparse.bsn]:
Expected a 64-bit operand.
Near: << ) >>

where mda is defined thus...

     ?iteration:=0;
     #while (iteration<16);
     ?mda :=iteration*8;

So, 16 errors listed on that line...

It compiles and works properly up to 1.81, so I am using that.

Cheers.

V Coder

[Randall Hyde]

Greetings Randy,

HLA is excellent.

I only recently discovered a paddq regression which causes my program to fail compilation with an error. I have not updated the program for months, but now I cannot test the latest new featres since in HLA:

   paddq ([esi+mda], mm4);

Error in file "palchk3.0alpha0.hla" at line 1635 [errid:72428/hlaparse.bsn]:
Expected a 64-bit operand.
Near: << ) >>

where mda is defined thus...

     ?iteration:=0;
     #while (iteration<16);
     ?mda :=iteration*8;

So, 16 errors listed on that line...

It compiles and works properly up to 1.81, so I am using that.

Cheers.

V Coder

Hmm...
Okay, I'll take a look at this. v1.82, of course, contained major changes to the MMX/SSE code, so it's not entirely surprising that something like this came up.  As a workaround (besides using v1.81), you might try:

Code Select Expand


paddq ( (type qword [esi+mda]), mm4);

Randy Hyde

[V Coder]

I have not been back at programming for a long time, and it seems the use of macros changed on me since the new HLA will not compile my old program.
#macro progsegment;
...
#endmacro progsegment;

// The HLA Ref says no semicolons after the endmacro statements

Find and replace fixed that, and now another error surfaced which is repeated countless times on different lines.
Expected a 64-bit operand.
Near: << ) >>

I had mentioned this paddq regression in which the compiler requires a generated an error message for my paddq instructions with defined constants.
paddq ([edx+mda], eax);

Randy suggested a workaround:
paddq ( (type qword [esi+mda]), mm4);

Now HLA appears to flag any constant, eg. paddq ([edx+8], eax);

The regression appears to still be there in the latest HLAs. Strangely therefore, HLA requires paddq index addresses to be explicitly stated as 64 bit addresses, but does not make that demand of any other instruction. This also breaks my old code, in which very many paddq statements are found.

Is there any fix in sight please?

Thanks.

[Randall Hyde]

I have not been back at programming for a long time, and it seems the use of macros changed on me since the new HLA will not compile my old program.
#macro progsegment;
...
#endmacro progsegment;

// The HLA Ref says no semicolons after the endmacro statements

This is correct. This changed a *long* time ago. The good news is that now macros may appear anywhere in the source file, not just in the declaration section (which was where they had to be back in the days when semicolons were required).

Find and replace fixed that, and now another error surfaced which is repeated countless times on different lines.
Expected a 64-bit operand.
Near: << ) >>

I had mentioned this paddq regression in which the compiler requires a generated an error message for my paddq instructions with defined constants.
paddq ([edx+mda], eax);

I assume you meant something like "mm0" rather than "eax" above?

Randy suggested a workaround:
paddq ( (type qword [esi+mda]), mm4);

Now HLA appears to flag any constant, eg. paddq ([edx+8], eax);

I would hope that it's flagging the "EAX" if you're really specifying EAX here. The second parameter needs to be an MMX register unless I've missed something along the way...

btw:

Code Select Expand


paddq( [edx+8], mm0 );

compiles fine for me under HLA v1.97.

The regression appears to still be there in the latest HLAs. Strangely therefore, HLA requires paddq index addresses to be explicitly stated as 64 bit addresses, but does not make that demand of any other instruction. This also breaks my old code, in which very many paddq statements are found.

Is there any fix in sight please?

Thanks.

I don't quite understand how you were generating the original constant (MDA), but paddq seems to be working fine for me when I specify an MMX register as the second operand.
hLater,
Randy Hyde

[V Coder]

Greetings.

I meant mm#, not eax. I accidentally typed that in the previous post.

Version 1.96 did not compile:

paddq ([edx+mda], mm1);

Error in file "abcd.hla" at line 1817 [errid:79445/hlaparse.bsn]:
Expected a 64-bit operand.
Near: << ) >>

In fact in retesting, neither did it compile

paddq ([edx], mm1);

It also gave error code 293:

abcd.hla [293]
error: illegal instruction.

Even after converting all paddq references to type dword so that the 64 bit operand issue did not arise, it still gave the 293 error and did not compile.

I needed to switch back to version 1.81 to compile.

Version 1.97 now has no problem compiling the paddq instructions as above, but the 293 error remains.

[Randall Hyde]

Hmmm...
You'll have to email me the full program, I suspect.
Every time I've compiled paddq( [edx], mm1); I get a successful compilation using both MASM and FASM output.
hLater,
Randy Hyde