ASM Community

Dont get hung up on structures.. they are not a hassle at all... The point of structures is yes, to localize alot of data under one premise (or tag name). However, they are still a bit abstract from ASM programming, which is why i suspect you have been having problems in the past. They are simply a template to help organize data, but they are NOT data in themselves. I better go to examples at this point :) I could say..

Point1_x  dd 0
Point1_y  dd 0
Point2_x  dd 0
Point2_y  dd 0 etc. etc.

And in using them i would have to reference each member directly:

mov eax, Point2_y

or

lea ebx, Point1_x
mov eax,   ; 12'th byte after the first as defined above

This is ok, but it would be easier to use data if they are grouped together as one type of data:

My_Point struc
   x   dd  ?
   y   dd  ?
My_Point ends

and in .data
  
  Point1  My_Point  <0,0>  ; initialize x,y to 0,0
  Point2  My_Point  <2,0>  ; initialize x,y to 2,0

or in .data?
   
  Point3  My_Point <>  ; uninitialized data 
  Point4  My_Point <>

The in the data segments, the stucture is used as a template to allocate the amount of memory (dd's) in the order they appear in the template. This is why i say stucts are NOT data in themselves. Now, if i were to disassemble the data segment of this one or the pervious above, they data would be in the same order (point1's x data, point1's y data, point2's x data, point2's y data). The difference is by simply telling MASM this will by a structured define, you can skip the redundancy of typing it all out in order. The code to use these are now:

  mov eax, Point2.y  

  ; y is the structure member that masm used to determin the offset
  ; this is the same as
  ;    lea ebx, Point2
  ;    mov eax,   ; 4 bytes after the first (y data)

One of the benifits is the fact the data HAS to be grouped together as prescibed in the structure template.. my origional example of separated data IS grouped together, but doesnt has to be. It could be a random like such:

Point1_x dd 0
MyFlag   dd 0
Point1_y dd 0
Point2_x dd 0
IsOn     dd 0
Point2_y dd 0

If i were asked to have the address to a point in this setup, you couldnt do it, because MyFlag is inbetween Point1_x and Point1_y:

invoke SomeFunct, addr Point1_x

will be used as:

mov ebx, Point1_x  ; base address of a point
mov eax,      ; get the x data
mov eax,  ; get the y data (assumed 4 bytes after the base)

The problem here is, 4 bytes after the first is MyFlag!!!! Using structures insures this problem is always taken care of (assuming the structure is defined in the correct order). Taking this a step further, you can also NEST structures to build more complex bounded data:

My_Circle sturct
  Center  My_Point <>
  Radius  dd       ?
My_Circle ends

Colored_Circle struct
  Circle  My_Circle <>
  Color   dd        ?
Colored_Circle ends

By simple defining in .data?

  RGB_Circle  Colored_Circle  <>

i have allocated memory in the data segment in this order:

RGB_Circle:  4 bytes, Referenced as (this).Circle.Center.x
            +4 bytes, Referenced as (this).Circle.Center.y
            +4 bytes, Referenced as (this).Circle.Raduis
            +4 bytes, Referenced as (this).Color

NOTE: (this) refers to the name of the defined data for 'this' structure type,
in this case it would be RGB_Circle.Circle.Center.x

ALSO NOTE: the 'SIZEOF Colored_Circle' command would return the above
evaluation = 16 bytes.

As a final thought, the use of stuctures are also advantageous when dealin with them as pointer, by simply passing a simple 4 byte pointer, it can be used to directly reference (in the above case) 16 bytes of data. (this speeds up your function calling, because less is being pushed on the stack).

; my fuction used a colored circle...
My_Fuction proc lpColored