Since FASM doesn't support an ALIGN directive directly, I used the macro example
given in the manual, i.e.,

macro align value { rb (value-1)-($+value-1) mod value }

However, when I compile some code that invokes this macro, I wind up
getting the following error:

flat assembler version 1.43
t.consts.inc [2] align [0]:
align 4
error: invalid use of symbol.

Here's the relevant code:

t.asm:

format MS COFF


offset32 equ
ptr equ
macro align value { rb (value-1)-($+value-1) mod value }

ExceptionPtr__hla_ equ dword

include 't.extpub.inc'




section 'data' data readable writeable executable
include 't.data.inc'

section 'data' data readable writeable executable
include 't.bss.inc'

section 'code' code readable executable
include 't.consts.inc'

section 'code' code readable executable
include 't.ro.inc'

section 'code' code readable executable



t.consts.inc:


align 4 ;;;;This is the line the assembler complains about!
label L857_len__hla_ dword
dd 0dh
dd 0dh
label L857_str__hla_ byte
db "Hello World",00dh,00ah,0
db 0
db 0


Any idea what FASM is complaining about here?
BTW, as a future enhancement, I'd recommend the inclusion of a true ALIGN
directive in the assembler. Relying on the macro may create problems. Further,
I don't know if ALIGN works properly in STRUCTs, but clearly a directive built into
the assembler could work there as well.
Posted on 2003-01-11 16:54:46 by rhyde
This is because in COFF format addresses are not absolute, and therefore you can only align relatively to the beginning of section. You can put the following two macros at the beginning of your code to get such result:


macro section params
{ section params
align_origin = $ }
macro align value { rb (value-1)-($-align_origin+value-1) mod value }

I've done it this way, because I think that the programmer should decide in what way he want to align, on his own responsibility, because only the programmer truly knows (at least should know) in what way his code will be loaded into memory.
Posted on 2003-01-11 17:07:19 by Tomasz Grysztar
Originally posted by Privalov:

This is because in COFF format addresses are not absolute, and therefore you can only align relatively to the beginning of section.
You can put the following two macros at the beginning of your code to get such result:


macro section params
{ section params
align_origin = $ }
macro align value { rb (value-1)-($-align_origin+value-1) mod value }

I've done it this way, because I think that the programmer should decide in what way he want to align, on his own responsibility, because only the programmer truly knows (at least should know) in what way his code will be loaded into memory.
<<<<<<<<<<<<<<<<<

I'm not 100% convince that this works in all cases.
It works great if you have only one instance of each named section,
but FASM still complains if you do something like the following:

section '.data' data readable writeable
data_origin = $

section '.text' code readable executeable
code_origin = $

section '.data' data readable writeable
rb 3 - ($-data_origin+3) mod 4

(it returns the same error as before)

On further reflection, I'm not sure how this could work anyway.
After all, data_origin is not guaranteed to be at offset zero within
the section (i.e., I could link with another module that also has
a '.data' section and the placement of "data_origin" would be at the
mercy of the linker). The *best* this could do is align whatever follows
the "rb" directive relative to the beginning of this particular portion
of the section; of course, that's not the intent, the intent is to ensure
that the following object is dword aligned in memory. Should the
linker choose to relocate this portion of the (overall) section at an
odd address, the "rb" statement above would leave it at an odd address.

Since MASM does this for OMF and COFF files, TASM does this for OMF,
and Gas does it for a whole variety of file formats (including ELF), I would
assume that it's perfectly possible for FASM to do this as well.
Expecting the end programmer to understand object module formats and
their ramifications for something as commonly used as an ALIGN directive
is probably expecting too much from your audience. One of the main reasons
for using an assembler in the first place is to abstract this kind of stuff away.
It seems to me that the vast majority of programmers don't care and don't
want to know the low-level details of how their code is loaded into memory.
Forcing them to figure this out for something as common as the need to align
some object on a given boundary is problematic at best.

I'm working with the output of a compiler and I've got more latitude than
most with respect to what I'm willing to do (since I generally have to do it
only once), but what's needed here is a general solution that doesn't change
just because you reassemble the code for a different object module format.

As I said, I'm willing to play some games with the output of my compiler,
but the current solution doesn't seem to work. Any other suggestions?
Randy Hyde
Posted on 2003-01-12 10:34:39 by rhyde
You have misunderstood me. Your code:


section '.data' data readable writeable
data_origin = $

section '.text' code readable executeable
code_origin = $

section '.data' data readable writeable
rb 3 - ($-data_origin+3) mod 4

is different from a solution I've proposed. I you use that two macros I've posted, this code:


section '.data' data readable writeable
; ...
section '.text' code readable executeable
; ...
section '.data' data readable writeable
; ...
align 4
; ...

will become:


section '.data' data readable writeable
align_origin = $
; ...
section '.text' code readable executeable
align_origin = $
; ...
section '.data' data readable writeable
align_origin = $
; ...
rb (4-1)-($-align_origin+4-1) mod 4
; ...

And this is working correctly

After all, data_origin is not guaranteed to be at offset zero within
the section (i.e., I could link with another module that also has
a '.data' section and the placement of "data_origin" would be at the
mercy of the linker).

And that's exactly what I had meant when I said it's programmers responsibility to make alignment macros suitable for your appliance.
Posted on 2003-01-12 11:43:39 by Tomasz Grysztar
It seems to me that the vast majority of programmers don't care and don't
want to know the low-level details of how their code is loaded into memory.


With all the respect Mr. Hyde, I think you are wrong on this point. I prefer FASM to MASM exactly for this reason. I do not want the assembler taking decisions in my name.;)

MASM is good in *helping* the programmers and it is free, so there is no sense in clonning it.

Best Regards,
Posted on 2003-01-13 05:58:55 by pelaillo

Posted on 2003-01-13 06:52:32 by bazik

Me too, fully.. although I think FASM should have a built-in ALIGN directive. Then it's up to the programmer to provide a true alignment correspondent to at least the maximum alignment specified in any ALIGN used in the source.

Also, I think it should have true nestable block comments.. but I'm not saying nothing new. :)
Posted on 2003-01-13 07:17:58 by Maverick

Posted on 2003-01-13 21:18:24 by rhyde
I always wanted a directive like ALIGN, but more... for example, I need to align code on an 16 + 4 boundary. Some silly code works best that way, or is it the silly processor? :)
Posted on 2003-01-13 21:32:57 by bitRAKE

You have misunderstood me. Your code:


section '.data' data readable writeable
data_origin = $

section '.text' code readable executeable
code_origin = $

section '.data' data readable writeable
rb 3 - ($-data_origin+3) mod 4

is different from a solution I've proposed. I you use that two macros I've posted, this code:


section '.data' data readable writeable
; ...
section '.text' code readable executeable
; ...
section '.data' data readable writeable
; ...
align 4
; ...

will become:


section '.data' data readable writeable
align_origin = $
; ...
section '.text' code readable executeable
align_origin = $
; ...
section '.data' data readable writeable
align_origin = $
; ...
rb (4-1)-($-align_origin+4-1) mod 4
; ...

And this is working correctly

And that's exactly what I had meant when I said it's programmers responsibility to make alignment macros suitable for your appliance.



Well, you'll have to excuse my misunderstanding of how the underlying MS COFF
format works. Never before have I needed to know the relocatable object code
format an assembler produces in order to use that assembler :-)

I'm still having problems with your code.
consider the following FASM example:



format MS COFF


section '.data' data readable writeable
align_origin = $

var1 db ?
var2 dw ?
rb (4-1)-($-align_origin+4-1) mod 4
var4 dd ?
var1_2 db ?


section '.text' code readable executable
align_origin = $

; Junk added just to change the code PC:

mov eax, ebx
nop

section '.data' data readable writeable
align_origin = $
;Okay, let's align var4_2 on a 64-byte boundary:

rb (40h-1)-($-align_origin+40h-1) mod 40h
var4_2 dd ?


section '.text' code readable executable
public rtnadrs4

; Quick function that returns the address of Var4 so I can display it:

rtnadrs4:
lea eax,
ret

public rtnadrs42

; Quick function for displaying the address of var4_2 so I can display it.

rtnadrs42:
lea eax,
ret

public aorigin

; This function returns the last value of align_origin (to compare with var4_2's address):

aorigin:
mov eax, align_origin
ret






I called the three functions above from the following HLA code:


program t;
#include( "stdlib.hhf" )

procedure rtnadrs4; @external;
procedure rtnadrs42; @external;
procedure aorigin; @external;

begin t;

call rtnadrs4;
stdout.put( "adrs1=", eax, nl );
call rtnadrs42;
stdout.put( "adrs2=", eax, nl );
call aorigin;
stdout.put( "origin=", eax, nl );

end t;


Here's the output I got:

adrs1=0400_2004
adrs2=0400_2010
origin=0400_2010

The address for var4 (adrs1 output) is reasonable and expected.
The address for var4_2 (adrs2 output) is unexpected and not at all what I intended
(it should be 0400_2040 if I've understood what your code is supposed to be doing and
I've adapted it correctly).

The final value for align_origin (origin output) is also unexpected.
Intuition suggests that this should have the value 0400_2009 (unless the linker
just happened to find and sneak in some other .data section that was exactly seven
bytes long, possible, but I doubt this occurred). Does FASM automatically align each
new section on a 16-byte boundary? (shades of DOS segments!)

Now I believe I've followed your directions (I could have screwed up somewhere, though),
yet I'm still unable to align an object on a desired boundary.

Again, I don't consider myself to be a beginner at this sort of stuff (though I will gladly
admit that I don't know the in's and out's of COFF, even though I have looked at it in
the past). If *I'm* having problems getting stuff like this to work, imagine the problems
that others are going to have. I argue that this speaks *volumes* about the need for
an ALIGN directive within FASM. It's not like aligning data and code is an uncommon
operation in assembly language :-)

In the meantime, this is the only impediment I've encountered thus far that is
preventing me from generating FASM code from HLA; so a workable solution that
lets me align objects to a boundary (actually, I limit it to a power of two in HLA IIRC)
would be great. Given that COFF sections are aligned on 4096 byte page boundaries
in memory, one should be able to align to any boundary up to that limit.

Thanks for any help you can provide,
Randy Hyde
Posted on 2003-01-13 22:00:32 by rhyde

align_origin = $
;Okay, let's align var4_2 on a 64-byte boundary:

rb (40h-1)-($-align_origin+40h-1) mod 40h

This actually does nothing, because $ is already 0, which is aligned to every possible value.


Does FASM automatically align each
new section on a 16-byte boundary?

In object formats like COFF sections are not yet aligned. So it's a matter of linker (I can't guarantee anything about linker).
And if FASM aligns sections to any boundary in executable formats, it's exactly said in the documentation, what is the value of that boundary.
Posted on 2003-01-14 02:33:20 by Tomasz Grysztar

I always wanted a directive like ALIGN, but more... for example, I need to align code on an 16 + 4 boundary. Some silly code works best that way, or is it the silly processor? :)
Did you see my align (with alignment and alignmentoffset) NASM and FAsm macros? :)
It was in some thread.. I'm not at home now, if you don't find it, I'll just send them when I'm back.
Posted on 2003-01-14 03:45:33 by Maverick

For FASM:



; Offset must be > -Alignment and < Alignment. You can omit the Offset parameter (i.e. = 0).
MACRO ALIGN Alignment,Offset {
IF <Offset> EQ <>
REPEAT (Alignment-1)-(($+Alignment-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
ELSE
REPEAT (Alignment-1)-(($+Alignment-Offset-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
END IF
}

When I get some time there's definitely something I must finish to develop for my compiler's x86 back-end: a full-blown ALIGN statement.
That is, besides alignment and alignment offset, it has to produce ASM instructions other than NOP, to fill the required gap.

Just to make some examples:


1 byte:
$90 - NOP

2 bytes:
$8B $C0 - MOV EAX,EAX
$8B $DB - MOV EBX,EBX
$8B $C9 - MOV ECX,ECX
$8B $D2 - MOV EDX,EDX

3 bytes:
$8D $40 $00 - LEA EAX,[EAX+$00]
$8D $52 $00 - LEA EDX,[EDX+$00]

4 bytes:
$8D $44 $20 $00 - LEA EDX,[EDX+$00]
$8D $54 $22 $00 - LEA EDX,[EDX+$00]

5 bytes:
$66 $8D $54 $22 $00 - LEA DX,[EDX+$00]

6 bytes:
$8D 80 00 00 00 00 - LEA EAX,[EAX+$00000000]
$8D 92 00 00 00 00 - LEA EDX,[EDX+$00000000]

7 bytes:
$8D $04 $05 $00 $00 $00 $00 - LEA EAX,[EAX*1+0x00000000]

8 bytes:
$66 $8D $04 $05 $00 $00 $00 $00 - LEA AX,[EAX*1+0x00000000]

The LEA 16bit,[..] instructions ain't good on Athlons, because they are decoded as Vector ones.
The reasons why in my above examples I listed register variants is to avoid dependancies. My back-end has no problem choosing the right variant, since it has a track of previously executed instructions. I suppose this would be harder to implement in a assembler, since normally those don't analyze the code.

Of course each CPU model has to have its own code generator.
Moreover, there's a certain pad threshold where jmp short becomes faster.

I've already wrote such a generator.. but it's in the beta stage, and only for my Athlon.

I wish I could freeze time for 10 years, finish all my crap, and restart time.. to use it instead of having a lot of development to finish before.
Posted on 2003-01-14 06:20:15 by Maverick

I always wanted a directive like ALIGN, but more... for example, I need to align code on an 16 + 4 boundary. Some silly code works best that way, or is it the silly processor? :)


align 16
rb 4

is the general way to do it (assuming you don't need to actually execute this
block of bytes, in which case you'd probably want to fill it with appropriate
four-byte NOPs.

Ditto for alignment to some value that's not a power of two -- not too difficult to
synthesize if you've got an alignment to an address that is a power of two.
It's getting the alignment to the appropriate power of two boundary in the first
place that's difficult to achieve.
Randy Hyde
Posted on 2003-01-14 21:54:07 by rhyde


For FASM:



; Offset must be > -Alignment and < Alignment. You can omit the Offset parameter (i.e. = 0).
MACRO ALIGN Alignment,Offset {
IF <Offset> EQ <>
REPEAT (Alignment-1)-(($+Alignment-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
ELSE
REPEAT (Alignment-1)-(($+Alignment-Offset-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
END IF
}




Hmmm...
Are you using multiple sections in your code?
I tried the following and still I got the error:

flat assembler version 1.43
ft.asm [24] ALIGN [6]:
ALIGN 4, 0
error: invalid use of symbol.



format MS COFF

; Offset must be > -Alignment and < Alignment. You can omit the Offset parameter (i.e. = 0).
MACRO ALIGN Alignment,Offset
{
IF <Offset> EQ <>
REPEAT (Alignment-1)-(($+Alignment-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
ELSE
REPEAT (Alignment-1)-(($+Alignment-Offset-1) mod Alignment)
NOP ; DB 0 if you prefer
END REPEAT
END IF
}


section '.data' data readable writeable
align_origin = $

var1 db ?
var2 dw ?
;rb (4-1)-($-align_origin+4-1) mod 4
ALIGN 4, 0
var4 dd ?
var1_2 db ?
Posted on 2003-01-14 22:09:12 by rhyde


In object formats like COFF sections are not yet aligned. So it's a matter of linker (I can't guarantee anything about linker).
And if FASM aligns sections to any boundary in executable formats, it's exactly said in the documentation, what is the value of that boundary.


COFF section objects specify a require alignment value (IIRC).
You specify the alignment that the entire section must be aligned upon
and it is upto the linker to ensure that it creates a combined module with that
portion of the section so aligned.

So, for example, were I to stick a directive like "ALIGN 40H" within a section,
and that was the largest ALIGNment in the section, then the entire section
would have to be aligned on a 40H boundary. COFF sections have to be
aligned on some power of two boundary, which is why most assemblers
enforce this.

Does FASM combine all the sections with the same name and attributes into
a single section for the linker? Or will it output multiple sections with the
same names and attributes as separate sections? (I'm assuming the latter,
based on FASM philosophy.) In any case, doing an ALIGN under COFF is
not that difficult. Just keep track of the largest ALIGN value in a given section
and make sure that the entire section is specified to be aligned on that
particular boundary. Then the little macro you've supplied would work perfectly
for alignment since we know each section begins on a reasonable boundary.

It doesn't look that hard to do, but I suspect that this is something the assembler
will have to do for me unless FASM provides a way to specify the section alignment
value in a SECTION statement.
Randy Hyde
Posted on 2003-01-14 22:38:24 by rhyde
Hmmm...
Are you using multiple sections in your code?
I tried the following and still I got the error:

Try this one:


;Offset must be > -Alignment and < Alignment
MACRO ALIGN Alignment,Offset {
IF <Offset> EQ <>
REPEAT (Alignment-1)-(($-SECTION_START+Alignment-1) mod Alignment)
NOP
END REPEAT
ELSE
REPEAT (Alignment-1)-(($-SECTION_START+Alignment-Offset-1) mod Alignment)
NOP
END REPEAT
END IF
}

You've to define SECTION_START.
Posted on 2003-01-15 03:20:31 by Maverick
I agree with Privalov, the programmer should be able to control the way an align should work. For example, my particular variant on ALIGN uses $FF as the fill byte - I'm designing a new BIOS and a blank on an EPROM/FLASH is $FF - not $00 or NOP...

On the otherhand - ALIGN with a couple of parameters to fill most peoples needs may work okay...

-Anthony
Posted on 2003-01-15 06:59:06 by DoubleDutchDesigns
I agree with Privalov, the programmer should be able to control the way an align should work. For example, my particular variant on ALIGN uses $FF as the fill byte - I'm designing a new BIOS and a blank on an EPROM/FLASH is $FF - not
I agree with Privalov, the programmer should be able to control the way an align should work. For example, my particular variant on ALIGN uses $FF as the fill byte - I'm designing a new BIOS and a blank on an EPROM/FLASH is $FF - not $00 or NOP...
Agreed.
On the otherhand - ALIGN with a couple of parameters to fill most peoples needs may work okay...
or NOP...
Agreed.
On the otherhand - ALIGN with a couple of parameters to fill most peoples needs may work okay...
Not agreed.. "most" means already limiting for some, which is frustrating.

Since the MACRO solution has some problems, here's what I can propose (as ALIGN design), which in my experience would fullfill *all* needs:

Provide ALIGN as a stand-alone assembler statement.

ALIGN alignment
alignes to alignment

ALIGN alignment,offset
alignes to alignment plus offset

ALIGN alignment,offset,reference_label
as above but takes as "starting point" reference the label

alternatively the reference_label can be expressed by means like:
ALIGNREF=...
which sets the reference label of ALIGN (I'd prefer all in one statement, anyway).

Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.

Finally, add a preprocessor variable that holds the maximum alignment required.. so that can then be used to know what will have to be the whole section's alignment on load.

This all should say the definitive word on the ALIGN problem..
Posted on 2003-01-15 07:07:02 by Maverick

Randall Hyde:
COFF section objects specify a require alignment value (IIRC).

No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.


Randall Hyde:
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?

As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.


Maverick:
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.


Yes, it can:


macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db , D, , , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
..align_size = ..align_size mod 8
if ..align_size = 7
db D, , , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
else if ..align_size = 6
db D, , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE], [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
else if ..align_size = 5
db , D, , , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
else if ..align_size = 4
db D, , , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
else if ..align_size = 3
db D, , [QUOTE]
[I]Randall Hyde:[/I]
COFF section objects specify a require alignment value (IIRC).
[/QUOTE]
No, the don't. ELF sections do (and fasm currently by default sets it to 4, as "as" does, but I'll probably make it customizable in future), but COFF section headers don't containt any "alignment" field. I can send you some more information (PDFs) about these object formats if you need to check.

[QUOTE]
[I]Randall Hyde:[/I]
Does FASM combine all the sections with the same name and attributes into
a single section for the linker?
[/QUOTE]
As I said it before, fasm creates the section in exactly the count and order you've specified. I recommend checking it with some hex viewer, you'll see the things better that with my explanations.

[QUOTE]
[I]Maverick:[/I]
Moreover, later, make ALIGN generate not only NOP, but also MOV/LEA or JMP statements to provide better padding code than just NOPs. This can't easily (or at all) be done with MACROs.
[/QUOTE]

Yes, it can:
[code]
macro codealign value
{
..align_size = (value-1)-($-align_origin+value-1) mod value
times ..align_size/8 db $66, $8D, $04, $05, $00, $00, $00, $00
..align_size = ..align_size mod 8
if ..align_size = 7
db $8D, $04, $05, $00, $00, $00, $00
else if ..align_size = 6
db $8D, $80, $00, $00, $00, $00
else if ..align_size = 5
db $66, $8D, $54, $22, $00
else if ..align_size = 4
db $8D, $44, $20, $00
else if ..align_size = 3
db $8D, $40, $00
else if ..align_size = 2
db $8B, $C0
else if ..align_size = 1
db 90h
end if
}
[/code]

[QUOTE]
[I]Maverick:[/I]
This all should say the definitive word on the ALIGN problem..
[/QUOTE]
else if ..align_size = 2
db B, $C0
else if ..align_size = 1
db 90h
end if
}



Maverick:
This all should say the definitive word on the ALIGN problem..

IMHO there is no any real problem. And I think it's good to force programmer to think about what he's really doing - I was designing fasm in the way that it shouldn't do anything if it's not absolutely sure it is correct.

I'm sorry if you find some of my answers a bit unpolite or icomprehensible, but I'm a bit tired now... Please understand.
Posted on 2003-01-15 08:13:54 by Tomasz Grysztar