I give in, I need help

Index > Main > I give in, I need help

Author

Thread

WytRaven

Joined: 08 Sep 2004
Posts: 45
Location: Canberra, Australia

WytRaven 08 Sep 2004, 09:23

I have been trying very hard to figure out this assembler stuff on my own and finally have decided that I must swallow my pride and ask a question.

I have been trying to figure out local variables in procedures. I understand that one must create a stack frame by juggling esp and ebp and subtracting enough space from esp to provide for local data (or using the 'enter' instruction). My understanding of the implementation appears to be somewhat flawed Shocked

I have been trying to suss out the implementation by reading the source of some of the 'proc' macros provided with FASM but must admit that they are wasted on me at present...without any commenting whatsoever in the macro source I am having an awful time trying to decipher macro syntax.

I will instead offer a description of what I am trying to achieve and hope that someone can provide a solution accompanied by a thorough explanation.

I am building a MS COFF object file which provides a bunch of public functions which will be called using the cdecl calling convention. I have managed to get the functions to be called correctly via C++ no problem. My issues begin when I try to start using local variables (the stack in other words).

One of my functions includes the task of creating a window. At present I am using a WNDCLASS structure declared in the .bss section and this works fine. In the interests of memory efficiency I want to define my WNDCLASS on the stack in my function's stack frame. I have read some material I found on the basic method and also Intel's reference on the 'enter' instruction. I'm just not getting something...

Can anyone shed some light on this subject please? Here's what I thought was supposed to do it for me (there's an extra 4 bytes allocated for a hWnd variable as well.

Code:

cproc _ICEInit,szName,iWidth,iHeight
 enter   44,0
                 
   ;Initialise window class
    xor             eax,eax                                                 ;Zero EAX register
  mov             [ebp],eax                                               ;wc.style
   mov             dword [ebp-4],WndProc                                   ;wc.lpfnWndProc
     mov             [ebp-8],eax                                             ;wc.cbClsExtra
      mov             [ebp-12],eax                                    ;wc.cbWndExtra
      mov             [ebp-16],eax                                    ;wc.hInstance
       mov             [ebp-20],eax                                    ;wc.hIcon
   mov             [ebp-24],eax                                    ;wc.hCursor
 mov             dword [ebp-28],COLOR_BTNFACE+1 ;eax     ;wc.hbrBackground
   mov             [ebp-32],eax                                    ;wc.lpszMenuName
    mov             eax,[szName]
        mov             [ebp-36],eax                                    ;wc.lpszClassName
   
    ;Register window class
      invoke RegisterClass,ebp
...
...
...

_________________
All your opcodes are belong to us

08 Sep 2004, 09:23

WytRaven

Joined: 08 Sep 2004
Posts: 45
Location: Canberra, Australia

WytRaven 08 Sep 2004, 13:02

Ok I figured it out...I discovered the LEA instruction, plus I finally dound one of the examples that demonstrates the proc macro's initilisation of local variables ability...

The working code is as follows for anyone else that is as new as me to all this

Code:

cproc _ICEInit,szName,iWidth,iHeight

       .wc             WNDCLASS
    .hwnd   dd ?
        
    enter
       
    xor             eax,eax                                                         ;Zero EAX register
  mov             [.wc.style],eax
     mov             [.wc.lpfnWndProc],WndProc
   mov             [.wc.cbClsExtra],eax
        mov             [.wc.cbWndExtra],eax
        mov             [.wc.hInstance],eax
 mov             [.wc.hIcon],eax
     mov             [.wc.hCursor],eax
   mov             [.wc.hbrBackground],COLOR_BTNFACE+1 ;eax
    mov             [.wc.lpszMenuName],eax
      mov             eax,[szName]
        mov             [.wc.lpszClassName],eax
     lea             eax,[.wc]                                                       ;Calculate actual address
   
    ;Register window class
      invoke RegisterClass,eax
...
...
...

_________________
All your opcodes are belong to us

08 Sep 2004, 13:02

Imagist

Joined: 13 Jun 2004
Posts: 114
Location: Pennsylvania (USA)

Imagist 09 Sep 2004, 05:48

I'm sort of new (I've been here a while, but I haven't put enough time into learning this to be very good) but I don't see why you need local variables. Why not just use the registers for temporary stuff? They are faster anyway.

09 Sep 2004, 05:48

WytRaven

Joined: 08 Sep 2004
Posts: 45
Location: Canberra, Australia

WytRaven 09 Sep 2004, 06:29

Mainly because I cant place a WNDCLASS structure in registers and then pass the address pointing to the structure to RegisterClass.

There aren't enough registers, and more to the point, the fact that RegisterClass is expecting the members of WNDCLASS to be in consecutive memory locations not registers.

The reason I wanted to use the stack instead of predefined data in my .data section (which is what you will see in most examples) is a matter of size optimization.

Hope that helped Very Happy

_________________
All your opcodes are belong to us

09 Sep 2004, 06:29

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 09 Sep 2004, 14:32

WytRaven wrote:

The reason I wanted to use the stack instead of predefined data in my .data section (which is what you will see in most examples) is a matter of size optimization.

Actually using local structure instead of global, doesn't make smaller the size of the application, because you have to write more instructions filling up the structure. The structure defined in initialized data memory needs only few of the fields to be filled in run-time (hInstance for example) and thus the summary size (data + code) becomes slightly smaller. (approx 3..5 bytes).

Using local structures actually makes the code more "clear" and readable, and reduces code/data dependencies.

Regards.

09 Sep 2004, 14:32

WytRaven

Joined: 08 Sep 2004
Posts: 45
Location: Canberra, Australia

WytRaven 09 Sep 2004, 17:34

Sorry I should have been clearer...

What I meant was that I only use that structure once...I don't see the need to waste RAM with a permanent copy lying around throughout my progs lifetime. A bit analy retentive I know Rolling Eyes

I tend to use 'size optimisation' to refer to both image size and RAM footprint. Very Happy

Yeah, yeah I can hear it already...'with today's computers RAM footprint isn't a big deal' etc...if that was my way of thinking I wouldn't be screwing around with ASM now would I... Twisted Evil

_________________
All your opcodes are belong to us

09 Sep 2004, 17:34

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 09 Sep 2004, 23:34

If you want to save memory for those structures used for single times you will find it valuable the help of virtual directive. You could use over and over the same small slice of RAM without loosing simplicity. Fasm rocks!

Some time ago I've done a test where everithing was local, even the MSG was in stack frame. I suffer from your same malady Wink

09 Sep 2004, 23:34

Matrix

Joined: 04 Sep 2004
Posts: 1166
Location: Overflow

Matrix 09 Sep 2004, 23:39

You forgot to mention speeds, because memory writes take a lot of time.

MATRIX

09 Sep 2004, 23:39

< 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