Can i have a DB, DW or DD allocation WITHIN a procedure?

[cork]

Can I have something like this:
    blah dw 33, 19, 04

Within a standard procedure (PROC/ENDP)?

[rags]

yes cork you could do something like this:

Code Select Expand


CorksProc proc blah:dword, blahblah:dword

.data
      BlahStr db 'Corks blah string',0
.code

; do something
    ret
CorksProc endp


[redskull]

Generally, you can have a db anywhere you like; it merely "defines a byte" at that point in code.  The problems you face, however, are that A) execution will continue right through it, unless you take measures to jump around it or otherwise avoid it, B) references to that label will be absolute, which can cause problems if your procedures are nested or multi-threaded, and C) various protection measures can make it difficult to write to code areas, which are normally read only.

-r

[jj2007]

For illustrating what red wrote, here both methods:

Code Select Expand

include \masm32\include\masm32rt.inc

MyTest1 PROTO: DWORD, :DWORD
MyTest2 PROTO: DWORD, :DWORD

.code
AppName db "Masm32 is great!", 0
Hello db "A message:", 0

start:
invoke MyTest1, offset AppName, addr Hello
invoke MyTest2, offset AppName, addr Hello
exit

MyTest1 proc arg1:DWORD, arg2:DWORD
LOCAL lv1, lv2, locbuf[260]:BYTE
jmp @F
TheBlah1 db "Welcome to the first blah", 0
@@:
  MsgBox 0, offset TheBlah1, arg2, MB_OK
  ret
MyTest1 endp

MyTest2 proc arg1:DWORD, arg2:DWORD
LOCAL lv1, lv2, locbuf[260]:BYTE
.data
TheBlah2 db "Welcome to the second blah", 0
.code
  MsgBox 0, offset TheBlah2, arg2, MB_OK
  ret
MyTest2 endp

end start


[cork]

Thanks guys.

Is it generally acceptable to use ".data" within a procedure? Is it commonly done?

[cork]

For illustrating what red wrote, here both methods:

Thanks jj2007 for the nice illustration via code!

[hutch--]

cork,

When you use a .DATA then .CODE setup the assembler still puts the data in the .DATA section so there is no problems doing it. You do need to be aware of the order you use this technique as it can be messed up at assembly time if the data is called before it is initialised.

What also can be done but is more problematic is to embed data in the code section, either by jumping over it or putting it at the end of a proc as data embedded in the code section is read only and if you try and modify it you get a write protection fault. In times past guys used to set the code section as read/write but that is a security problem and clashes with DEP on late OS versions.

[japheth]

You do need to be aware of the order you use this technique as it can be messed up at assembly time if the data is called before it is initialised.

Wot? Is this sentence supposed to be comprehensible?

[jj2007]

When you use a .DATA then .CODE setup the assembler still puts the data in the .DATA section so there is no problems doing it. You do need to be aware of the order you use this technique as it can be messed up at assembly time if the data is called before it is initialised.

Entirely comprehensible indeed, but still: Hutch, could you show us an example where that happens, please?
Thanks :bg

[sinsi]

If you go the .data/.code way remember that the variable in .data is global in scope, not local to the proc, so the name has to be unique.

hutch, is that how you speak over there? calling data?  :bdg

[frktons]

Could anybody speculate a little about the difference, if any,
between:

Code Select Expand


   invoke MyTest1, offset AppName, offset Hello
   invoke MyTest2, offset AppName, offset Hello


and

Code Select Expand


   invoke MyTest1, offset AppName, addr Hello
   invoke MyTest2, offset AppName, addr Hello
  ::)
The result is the same, at least in this case.

[hutch--]

 :bg

> Wot? Is this sentence supposed to be comprehensible?

Only if you speak English.

Code Select Expand


IF 0  ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
                      Build this template with "CONSOLE ASSEMBLE AND LINK"
ENDIF ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include\masm32rt.inc

    item PROTO

    .code

start:
   
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    call main
    inkey
    exit

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

main proc

    invoke item

    ret

main endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

item proc

    print OFFSET text,13,10

    .data
      text db "this is a test",0
    .code

    ret

item endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

end start


Generates this result.

Code Select Expand


Microsoft (R) Macro Assembler Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Assembling: H:\asm6\sa\sa.asm
H:\asm6\sa\sa.asm(33) : error A2006:undefined symbol : text
print(1): Macro Called From
  H:\asm6\sa\sa.asm(33): Main Line Code
H:\asm6\sa\sa.asm(33) : error A2114:INVOKE argument type mismatch : argument : 1

print(1): Macro Called From
  H:\asm6\sa\sa.asm(33): Main Line Code
_
Assembly Error
Press any key to continue . . .


Seems a little knowledge is dangerous, did you guys get this technical data off the back of a Kellogs Corn Flakes packet ?

Put the .DATA / .CODE block BEFORE the print call and it builds OK.

[clive]

Seems a little knowledge is dangerous, did you guys get this technical data off the back of a Kellogg's Corn Flakes packet ?

ROTFL, reminds me of one of the coach drivers from college yelling at car owners in the bus lane....

Oddly enough it appears to be more of a MACRO issue (parameter fully known in first pass, .code/.data has little to do with it), because "LEA eax, text" works just fine for forward references. The forward reference also fails with the print macro if the .code/.data pair is removed and the string is placed in the code segment.

On architectures like the ARM and 68K it is quite common to park the constant "literals" immediately after the subroutine code, and use short offset PC relative addressing to load it. Works well for address agnostic code, code in ROM, and cache locality. Doing PC/IP relative accesses on the x86 is a bit more of a hack.

[hutch--]

Yep,

Pre-processor 1st pass is the action, I have been bittten by this one before.

[dedndave]

i recall wanting a fixed-address define with a local label and tried using DD ? inside a proc
that didn't work out so well   :bg

as for placing data inside the code segment, you can do that
it works ok for constants, mainly (things like branch vector tables)

for variables, you can use VirtualProtect to change the permission for the memory block (once during init)
seems like it defeats the purpose - and i don't see any real advantage in doing that
better off sticking it in data or data?