Thankx for helping :grin:

Will check out GoAsm :cool:
Posted on 2004-05-28 23:12:35 by telophase
Hi telophase,

Though I certainly recomend GoAsm, especially for non-English users it is not for everyone. For example there are no .IF/.ENDIF or .REPEAT .WHILE etc macros, it is for assembly language as assembly not diguised as a high level language. But if you use a non-western character set you can use your own language for labels, for example this is just fine in GoAsm...

??:

cmp edx,20
jl ??

or

invoke ?????????, 123

????????? FRAME ????????

ret
endf
Posted on 2004-05-28 23:18:29 by donkey
i know about the proc syntax but i remember i had read somewhere in ur posts only
some thing like :


FindItem FRAME hlv,iStart,pLVFINDINFO

pop eax
RET
ENDF

What is this frame stuff :confused:
Posted on 2004-05-28 23:39:52 by telophase
The PROC statement in MASM just sets up a stack frame, in GoAsm it is more aptly named FRAME. They are the equivalent of PROC/ENDP.

FRAME/ENDF
Posted on 2004-05-28 23:45:54 by donkey
Oh!!!! Got it :grin:
Posted on 2004-05-28 23:53:46 by telophase
What if i still wann use MASM and use delta method for referencing for eg:

.code

myvar dd 0

start:

call delta

delta:
pop ebp
sub ebp,OFFSET delta

mov ,'$'

end start

Is the above gonna be possible? :notsure:
Posted on 2004-05-28 23:57:11 by telophase
I still thinking.. masm can not resolve forward references....

That is very ... very interesting :D

I cant believe it :)

very very ....


Have a nice day or night.
Posted on 2004-05-29 00:01:45 by rea
What if i still wann use MASM and use delta method for referencing for eg:

.code

myvar dd 0

start:

call delta

delta:
pop ebp
sub ebp,OFFSET delta

mov ,'$'

end start

Is the above gonna be possible?


Shouldn't take longer than 50 milliseconds to compile, why not just try it ?
Posted on 2004-05-29 00:03:10 by donkey

I still thinking.. masm can not resolve forward references....

That is very ... very interesting :D

I cant believe it :)

very very ....


Have a nice day or night.


MASM can resolve forward references, the problem is that the INVOKE pseudo macro in MASM is crap and chokes on all forward references. It also uses LEA to calculate the address of local variables, another thing GoAsm doesn't do.
Posted on 2004-05-29 00:04:54 by donkey
aaa, then I understand a little best , thx


Have a nice day or night.
Posted on 2004-05-29 00:06:12 by rea
Yesss!!!!

Thankyou People!!

I worked out smooth :grin:
Posted on 2004-05-29 00:09:05 by telophase
I will have to make the text section writable before i proceed right?

Or the program will crash !:sweat:
Posted on 2004-05-29 00:10:45 by telophase
Hi telophase


Here is the assembled version by donkey (attached).


Regards,
Posted on 2004-05-29 02:23:36 by The SharK
Hey I tried to put data in a code section but whenever I wrote to it , I got an exception! My guess is that you may have to keep constants only.
Posted on 2004-05-29 14:50:02 by x86asm
Use the linker switch /SECTION ... /SECTION:.text,rwe (read+write+executable)
Posted on 2004-05-29 14:57:27 by f0dder

Use the linker switch /SECTION ... /SECTION:.text,rwe (read+write+executable)

ohh, thanks f0dder! now I can :D
Posted on 2004-05-29 19:54:53 by x86asm
Here is a little trick I use if I'm inserting text to be displayed on the fly. Rather simple, just make sure the label is not on the same line as the BYTE definition.



.386
.model flat,stdcall
option casemap:none

include windows.inc
include user32.inc
include kernel32.inc
includelib user32.lib
includelib kernel32.lib

.code
start: push MB_OK
push _title
push _message
push 0
call MessageBox
jmp @f
_title:
BYTE "It Worked!",0
_message:
BYTE "~!w00t!~ I LOVE ASSEMBLY PROGRAMMING ~!w00t!~",0
@@: push 0
call ExitProcess
end start

By doing that I don't have to deal with OFFSET or ADDR, but personally I rather keep data out of the code section, I just use this if I'm doing "Printf Debugging" and I'm going to strip it out later anyways.
Posted on 2004-05-29 20:14:02 by Synfire
synfire, try "iamteh0wnz0r label byte db 090h,042h"
Posted on 2004-05-29 22:28:53 by f0dder

MASM can resolve forward references, the problem is that the INVOKE pseudo macro in MASM is crap and chokes on all forward references. It also uses LEA to calculate the address of local variables, another thing GoAsm doesn't do.


The forwarded reference problem can be solved with a simulation of invoke macro:


.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

include invoke.inc

.code
start:
_invoke MessageBox, NULL,addr MsgBoxText, addr MsgCaption, MB_OK
_invoke ExitProcess,NULL

MsgCaption db "Iczelion's tutorial no.2",0
MsgBoxText db "Win32 Assembly is Great!",0

END start
Posted on 2004-10-16 06:37:48 by Vortex
In my Testbug demonstration program, available from www.GoDevTool.com I experiment with how placing data in the code section affects speed of execution.

Here is an excerpt from Testbug's help file about this:-

Data in the code section
I was in a rebellious mood, but got my knuckles wrapped over this one (until the AMD64 came along!). Since we have been using Win32, assembler programmers feel much more relaxed about regarding the whole virtual memory area as available for our program's data and code. However, programs are still divided into data and code - but why should they be? We dutifully declare a data section and put all data in there, and then we declare a code section and put all the code in there. Writers and teachers tell us it is "bad programming practice" to do otherwise. But how do they know? We know that when we look at an executable file with a file viewer or with a debugger, the only difference between the sections appears to be the names. Why are we being such good boys and girls? Why not abolish the difference and just put everything in the code section? This test shows why, on processors below the P4 at least. On those processors access to data in the code section is much slower than access to data in the data section. Why? The answer must be that the processor and its cache are optimised to execute reading and writing instructions from the data section rather than the code section. Of course the processor knows which is which from the information fed to its descriptor registers and the segment registers by the operating system. Note the Windows operating system will not permit a "write" to the code section anyway, without a call to the API VirtualProtect to change the section's attributes. This is so even if the code section is marked "writeable" in the executable. On the P4, it seems it makes no difference to speed whether data is held in the data section or in the code section. Now that could transform the way assembler programmers write their code!
This test searches a table and returns when the correct value in the table has been found. The only difference between the "code" and the "data" tests is that in the code tests the table is declared in the code section and in the data tests the table is declared in its rightful place, the data section. The test is carried out 5000 times and the time taken for completion is tested using the api QueryPerformanceCounter. The table has 60 entries. The "early" find stops at the 5th entry, the "middle" find stops at the 30th entry and the "late" find stops at the 56th entry.
I don't give the code here because it is basically the same as the sample code I wrote for a standardised callback procedure in Windows. This code gets rid of all those long chains and conditional jumps in a window procedure. Instead it uses a table of procedures and message values. When the correct message value in the table is found the correct procedure is called to carry out the required action.

Note on AMD64
The AMD64 makes use of RIP-Relative addressing. RIP is the new 64-bit instruction pointer (it replaces EIP). The AMD64 processor can read data at an address relative to the RIP at any one time using an 32-bit offset value. Up to now relative addressing was only used for jumps to a new instruction place. For this to work, it probably makes no difference to the processor whether the data is in executable or non-executable areas and the processor may in fact be blind to this. Using RIP-relative addressing can shorten code considerably (no need for large displacement values to be included in the instruction) so development tools should endeavour to use it as much as possible.
Posted on 2004-10-17 02:57:16 by jorgon