Can I have something like this:
blah dw 33, 19, 04
Within a standard procedure (PROC/ENDP)?
yes cork you could do something like this:
CorksProc proc blah:dword, blahblah:dword
.data
BlahStr db 'Corks blah string',0
.code
; do something
ret
CorksProc endp
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
For illustrating what red wrote, here both methods:
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
Thanks guys.
Is it generally acceptable to use ".data" within a procedure? Is it commonly done?
Quote from: jj2007 on July 20, 2010, 12:36:30 AM
For illustrating what red wrote, here both methods:
Thanks jj2007 for the nice illustration via code!
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.
Quote from: hutch-- on July 20, 2010, 01:52:24 AM
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?
Quote from: hutch-- on July 20, 2010, 01:52:24 AMWhen 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
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
Could anybody speculate a little about the difference, if any,
between:
invoke MyTest1, offset AppName, offset Hello
invoke MyTest2, offset AppName, offset Hello
and
invoke MyTest1, offset AppName, addr Hello
invoke MyTest2, offset AppName, addr Hello
The result is the same, at least in this case.
:bg
> Wot? Is this sentence supposed to be comprehensible?
Only if you speak English.
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.
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.
Quote from: hutch--
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.
Yep,
Pre-processor 1st pass is the action, I have been bittten by this one before.
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?