|
-
Sep 27th, 2006, 10:17 PM
#1
Thread Starter
New Member
ASM Question
now this might be a completely stupid question but i am gonna ask it anyway :P
Ok in x86 ASM i see they have
General Registers
Segment Registers
Pointer Registers
My question is these in regular programming language (VB,C++ etc)
General Registers would be like global variables?
Segment Registers would be variables that only exist in that function or in ASM the code block?
Pointer Registers would be pointers to data inside the code blocks that alter the segment registers/general registers?
now this might be wayyyyyy off the mark but i figure i would take a stab at it to see if i have a general idea of this ASM stuff 
i read c++ on and off no pro but i like to do it as a hobby to to know
-
Sep 28th, 2006, 05:06 AM
#2
Re: ASM Question
You're 100% wrong. Registers are always for pretty transient variables, and you cannot really compare them to variables of a higher-level language in any way.
All the buzzt
 CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
-
Sep 28th, 2006, 09:06 AM
#3
Addicted Member
Re: ASM Question
You're 100% wrong. Registers are always for pretty transient variables, and you cannot really compare them to variables of a higher-level language in any way.
Yes that is true. But when you use assembly language, especially when you translate a high-level algorithm -
You basically use eax, ecx, edx - and if you preserve ebx, ebp, esi, edi those can become in handy as well for being 'variables'. However these as 'global variables' is not quite correct as these 'variables' are global to the entire computer OS, drivers and all.
Preservation is the key.
Segment registers are generally unused in 32-bit usermode programming with the exception of the FS segment register which is used for Structured Exception Handling (SEH)
Common conventions are ESI, EDI for arrays & strings
ESP, EBP for stack
EAX for putting in a result (especially on function returns)
ECX for counter
EDX for data
EBX (I can't remember off the top of my head )
Cheers.
-
Sep 28th, 2006, 09:14 AM
#4
Re: ASM Question
 Originally Posted by Raedwulf
But when you use assembly language, especially when you translate a high-level algorithm -
You basically use eax, ecx, edx - and if you preserve ebx, ebp, esi, edi those can become in handy as well for being 'variables'.
Yes, but that's all function-local stuff. And registers are, as I said, extremely volatile. You must preserve some of them yourself across function calls, for example.
The global variables of hlls are only representable by reserving some real memory for them.
However these as 'global variables' is not quite correct as these 'variables' are global to the entire computer OS, drivers and all.
Not quite. Each execution context has its own set of registers - the physical registers will probably be shared, but logically each process has its own set.
EBX (I can't remember off the top of my head  )
Used as the base for address calculations, usually.
All the buzzt
 CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
-
Sep 28th, 2006, 10:34 AM
#5
Addicted Member
Re: ASM Question
 Originally Posted by CornedBee
Not quite. Each execution context has its own set of registers - the physical registers will probably be shared, but logically each process has its own set.
Yeah i forgot to include that - the OS preserves them if i am correct.
Cheers.
-
Nov 2nd, 2006, 03:37 PM
#6
New Member
Re: ASM Question
Hi guys
I haven't programmed ASM in years [8086 code on a 33Mhz 286 in 1993...lol] but I found using the registers as defined [eg: cx for counts, ax, bx for math] was just good coding. They can be utilized any way you wish but when performing LIFO pushes and pops it just kept everything a little more organized.
-
Nov 4th, 2006, 06:10 AM
#7
Member
Re: ASM Question
Forget registers as variables. Assembler has four directives what's called sections, namely .DATA-section, .DATA?-section, .CONST-section and .CODE-section.
.DATA-section contains initialized data of your program. These data is stored in your program and will therefor affect the size of your executable file. Example
Code:
szAppName db "MyProgram",0
.DATA?-section contains uninitialized data of your program. In this section you just preallocate memory but not initialize it. The advantage of uninitialized data is it doesn't take space in the executable file. You only tell the assembler how much space you need when the program is loaded into memory.
.CONST-section contains declaration of constants used by your program. Constants in this section can never be modified in your program. It also affect the size of the executable file.
.CODE-section is where your codes reside.
I would compare .data, .data? and .const with VB Global or Public declarations.
In assembler you also have LOCALS. I would compare it with VB Dim in a Sub or Function or Private declarations. These locals ar volatile variables.
Locals are just preloocating stack space. For example I have a process
Code:
MyProcess proc hWin:dword
LOCAL lineno:DWORD
LOCAL linecount:dword
LOCAL buffer[32]:BYTE
LOCAL hDC:HDC
LOCAL rect:RECT
LOCAL hRgn:DWORD
There are 4 dwords, a buffer of 32 bytes and a rect structure of 4 dwords, totaly 64 bytes. Now you have to prelocate stack space for those locals. First save the stackframe with
Code:
push ebp
mov ebp,esp
and then prelocate stack space for your locals by decreasing the stackpointer with the number of bytes[/code]
sub esp,64[/code]
As you understand these locals hold garbage before you have put your values to them.
When you leave your process you must restore the frame pointer and release stack space
Code:
mov esp,ebp
pop ebp
and finally find the return address. In this case there is on process argument so you have to write .
This seems to be very complicated but if you use masm there are masm syntax that will do this work for you.
-
Nov 5th, 2006, 02:27 PM
#8
Re: ASM Question
The .data? section is called .bss in many assemblers. Never assume that any two assemblers work even approximately the same, even if they're for the same platform.
All the buzzt
 CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
-
Nov 6th, 2006, 12:09 PM
#9
Member
Re: ASM Question
Well, I'm working with masm32 but know some about GOASM, FASM, TASM or whatever they are called. But I have not come across .bss section as coding directive for uninitiated data. however I agree the directives differs between different assemblers.
In masm you have the directive .CODE [name]. If name is not specified the segment is called _TEXT.
The .DATA directive gives the segment name _DATA and .DATA? directive gives _BSS. For example if you want your dll lib to share uninitialized data you give the link.exe option /section:.bss,s.
Correct me if I am wrong.
Edit: Sorry Fasm directive is "section '.bss'" I recall.
Last edited by minor28; Nov 6th, 2006 at 12:23 PM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|