Some suggestions and questions about the 'locals' macro

Index > Windows > Some suggestions and questions about the 'locals' macro

Author

Thread

Dasn

Joined: 22 Nov 2004
Posts: 11

Dasn 09 Aug 2009, 23:50

Hi guys,
The following code (without utf8.inc) can be successfully compiled. But if I include the 'utf8.inc' (i.e. un-comment the first line) it will be not.

Code:

;include 'encoding\utf8.inc'
include 'win32axp.inc'

.code
proc    _Test
        locals
                szText1  du 'Hello world', 0
                szText2  TCHAR 'hello', 0
        endl
        ret
endp

start:
        call    _Test
        invoke  ExitProcess, 0
.end start

In the documentation, I found

Quote:

To declare the local variable you can use the local macroinstruction, followed by one or more declarations separated with commas, each one con-
sisting of the name for variable followed by colon and the type of variable – either one of the standard types (must be upper case) or the name of data structure.

It only says about the 'local' should use standard types , but says nothing about 'locals' (actually it uses Data Definations).

Q) Are 'du' and 'TCHAR' macros supposed to work in 'locals'?

Anyway, I also think that standard types is a little confusing here. What is a "standard type"? I searched the document and found nothing related to it (i.e. the "standard type" hasn't been defined in the documentation) . Finally I searched 'dword' and found they mean uppercase "Size Operators" while not standard types. So I don't think the "standard types " is accurate, right? Smile

09 Aug 2009, 23:50

bitRAKE

Joined: 21 Jul 2003
Posts: 4165
Location: vpcmpistri

bitRAKE 10 Aug 2009, 02:01

I don't use those macros, but the description describes something like:

Code:

local mydd:DWORD, mybb:BYTE

...it doesn't mention the locals/endl macros. Guess that doesn't help much.

Looking at the \INCLUDE\MACRO\PROC32.INC file, it does appear to initialize the local data in locals/endl. I'd have to dive in deeper using the FAS file tools to see what the pre-processor is doing. Maybe, try swapping the include order? No, that didn't work.

It isn't the TCHAR, but the DU causing the error.

Code:

szText1:  du 'Hello world', 0

...seems to work - which gives us more insight on the problem.

10 Aug 2009, 02:01

shoorick

Joined: 25 Feb 2005
Posts: 1614
Location: Ukraine

shoorick 10 Aug 2009, 04:57

http://board.flatassembler.net/topic.php?t=9251

10 Aug 2009, 04:57

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 10 Aug 2009, 06:45

This definitely should be corrected, thanks for reminding me.

10 Aug 2009, 06:45

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 12 Aug 2009, 11:37

I had to update both the encoding macros and the proc macros to fix this issue. Please download the latest fasmw package for the corrected includes.

12 Aug 2009, 11:37

madmatt

Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA

madmatt 12 Aug 2009, 12:05

Hi,
Had to comment out this line for the 'proc32.inc' before fasmw would recompile:

Code:

macro deflocal@proc name,def,[val] \{ name def val \}

must have been left in by accident Smile

, I assume the new macro is right below it.

[edit] and, defining a DQWORD variable gives me an 'invalid argument' error. in the local macro, and in the locals/endl macro's.

Last edited by madmatt on 12 Aug 2009, 12:43; edited 3 times in total

12 Aug 2009, 12:05

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 12 Aug 2009, 12:20

No, this additional line is required for the fix to work fully, I only forgot to remove the backslashes. Uploading the another update right now.

12 Aug 2009, 12:20

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 12 Aug 2009, 12:57

Uploaded all the corrections. Now it should work for all types.

12 Aug 2009, 12:57

madmatt

Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA

madmatt 12 Aug 2009, 13:45

Don't know if you saw my latest edit, so I'll make a new post. The local macro works good now. Thanks! Cool

But get an 'illegal instruction' when defining a DQWORD in the locals/endl macro combo. Have to ask this, would it be possible to align the DQWORD local variables/arrays to a 16 byte boundry Question

I would assume this variable type would be mostly used for sse instructions only, and it would be nice to have this done automatically.

12 Aug 2009, 13:45

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 12 Aug 2009, 14:24

madmatt wrote:

Don't know if you saw my latest edit, so I'll make a new post. The local macro works good now. Thanks! But get an 'illegal instruction' when defining a DQWORD in the locals/endl macro combo.

You cannot define DQWORD variable this way. You have to use "local" macro, or "label" followed by double "dq", etc.

madmatt wrote:

Have to ask this, would it be possible to align the DQWORD local variables/arrays to a 16 byte boundry I would assume this variable type would be mostly used for sse instructions only, and it would be nice to have this done automatically.

The problem is that in 32-bit case locals themselves are not guaranteed to be aligned on 16 byte boundary (only 4 byte one). You'd have to modify proc prologue to get such alignment.
And if you made such a prologue, it may be possible to re-define "align" as a macro so that it would work inside "locals" block.

12 Aug 2009, 14:24

madmatt

Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA

madmatt 12 Aug 2009, 15:36

all right, thanks. sounds like it would be easier just to define general purpose sse global variables. or, you could define an extra dqword for your variable or array and align it manually before use with:

Code:

lea esi, [ssevarorarray]
and esi, $fffffff0
add esi, 16

12 Aug 2009, 15:36

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 12 Aug 2009, 17:03

Quote:

The problem is that in 32-bit case locals themselves are not guaranteed to be aligned on 16 byte boundary (only 4 byte one). You'd have to modify proc prologue to get such alignment.

How about 64-bit case? Do FASM macros quarantee usual 16-byte alignment for locals? (provided that function is called properly, eg RSP & 0xF = Cool

12 Aug 2009, 17:03

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 12 Aug 2009, 18:55

Yes, they do. Both the default and the static-RSP variant.

[EDIT]As it was pointed out in the other thread, this is not true in general. The static-RSP variant aligns the stack frame only when there are some calls (with "fastcall" interface) made inside the procedure, otherwise it does not. In general it guarantees only the 8-byty alignment. This gives even more reasons to design a system that would allow to use "align" inside the "locals" blocks.[/EDIT]

12 Aug 2009, 18:55

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum