I have tried using FASM instead of MASM32 (default), in order to get all MMX instructions assembled properly. I compile with -sf and -fasm options.

It works except if I use the align (16); directive to align loops for increased speed.

A simple test. Use the testtimer.hla example. It compiles with -sf -fasm, and testtimer.exe executes normally.

Then, insert;

nop;

//align (16);


right after begin testtimer; and before
	alarm.create();

alarm.start();


HLA inserts the following macro at the start of testtimer.asm

macro align v 

{
rb (v-1)-($+v-1) mod v
}


and the alarm functions are translated thus:

		nop

lea esi, [ebp-42] ; alarm
call timer_create ; create
lea esi, [ebp-42] ; alarm
mov edi, dword ptr [esi+0]
call dword ptr [edi+0]



04001070  |. 90             nop;

04001071 |. 8D75 D6 lea(ESI,[TYPE DWORD EBP-2A]);
04001074 |. E8 C7100000 call TESTTIME.04002140;
04001079 |. 8D75 D6 lea(ESI,[TYPE DWORD EBP-2A]);
0400107C |. 8B3E mov([TYPE DWORD ESI],EDI);
0400107E |. FF17 call([TYPE DWORD EDI]);


If you uncomment the align directive, HLA puts the following code after the nop (at the start of the program right after initialization of esp and ebp)

rb 15 - (($-_origin___hla_+17) mod 16) ;align 16


Three problems:
1) FASM encodes this as several bytes of zero,
2) the 8D75 etc of the LEA is incorporated into another instruction
3) IT IS NOT ALIGNED TO 16 BYTES!!!!! The instruction code - 8D75 is two bytes early!!!

04001070  |. 90             nop;

04001071 |. 0000 add(AL,[TYPE BYTE EAX]);
04001073 |. 0000 add(AL,[TYPE BYTE EAX]);
04001075 |. 0000 add(AL,[TYPE BYTE EAX]);
04001077 |. 0000 add(AL,[TYPE BYTE EAX]);
04001079 |. 0000 add(AL,[TYPE BYTE EAX]);
0400107B |. 0000 add(AL,[TYPE BYTE EAX]);
0400107D |. 008D 75D6E8BA add(CL,[TYPE BYTE EBP+BAE8D675]);
04001083 |. 1000 adc(AL,[TYPE BYTE EAX]);
04001085 |. 008D 75D68B3E add(CL,[TYPE BYTE EBP+3E8BD675]);
0400108B |. FF17 call([TYPE DWORD EDI]);
0400108D |. BB 00000000 mov(0,EBX);


Help please.
Posted on 2003-10-14 21:29:31 by V Coder
Alignment is one of those things that is problematic under FASM.
A while back, Thomasz gave me the macro you're seeing to use.
As you've discovered, it doesn't always work. I'd asked for a generic
align directive in FASM, but Thomasz gave some technical reason
for not providing it. Never gave it much thought after that.
If anyone has any ideas how to create a generic align directive
in FASM, I'm all ears.
Cheers,
Randy Hyde
Posted on 2003-10-15 12:07:06 by rhyde
Three problems:
1) FASM encodes this as several bytes of zero,
2) the 8D75 etc of the LEA is incorporated into another instruction
3) IT IS NOT ALIGNED TO 16 BYTES!!!!! The instruction code - 8D75 is two bytes early!!!


I have solved problem 3. It seems HLA's code is wrong:

rb 15 - (($-_origin___hla_+17) mod 16) ;align 16

should be

rb 15 - (($-_origin___hla_+15) mod 16) ;align 16

[]

I intended to search through your code so I could tell you exactly where the problem is, but I slept...

In relation to problems 1 & 2, it seems rb is intended to reserve data bytes (by putting zeroes), not align code. Maybe you can encourage Thomasz to put a similar instruction to align code by inserting $90s (NOP) instead of $00s.
Posted on 2003-10-15 21:39:49 by V Coder
I got what should be the solution from comrade over at the FASM Board.

macro aligncode value {

times ((value-1) - (rva $ + value-1) mod value) nop
}


Well, I'll give it a try.

Randy would you be able to incorporate both this and the fix for rb in 1.58?
Posted on 2003-10-15 22:42:20 by V Coder

I got what should be the solution from comrade over at the FASM Board.

macro aligncode value {

times ((value-1) - (rva $ + value-1) mod value) nop
}


Well, I'll give it a try.

Randy would you be able to incorporate both this and the fix for rb in 1.58?


No. v1.58's already out the door.
But I look into it for v1.59 (there's another outstanding problem in the tables module,
so 1.59 will probably appear in a week or so).
Cheers,
Randy Hyde
Posted on 2003-10-16 21:26:36 by rhyde