Label vs PTR

[RuiLoureiro]

...
It is probably not advisable to mix up your code and use both forms?
Cheers,
Steve N.

Hi Steve,
               For me, one name for one variable is too much
               and then, i prefer to define variables as dwords
               (for true/false i define a dword) and i prefer to use dword ptr [varname]
                Instead of mov   eax, varname i like to use mov   eax, dword ptr [varname]
               When or if i want to see what is in the upper word i use word ptr [varname + 2]
                etc. etc.
                We have problems if we define a variable as a byte and somewhere we use
                cmp           eax, dword ptr [varname]. Its wrong, of course.
Cheers  :U
RuiLoureiro

[ic2]

Many ask this question MANY times since 2001 when masm32 came in kicking butt.  This will always be one of the top10 questions forever.  So I did another  google a minute ago to find old news  *like I never did it before.  Same tune, new day*.

Wow ... Off  the bat, King Google gave this thread Top level with a vs as the LABEL ... that's fast.

http://www.google.com/search?q=ptr+vs+label&hl=en&ie=ISO-8859-1&btnG=Search

Label vs PTR
http://www.masm32.com/board/index.php%3FPHPSESSID%3D79c214658d4afc1361791f92691b68af%26topic%3D10938.0 - 38k -


Anyway, who need type checking if you are an assembler who knows how to write your own secure  code.  Type checking only slow thing down because it want to HELP you or itself.

I verified this though saved pages on my HD,  it was Qage who said this and I never forgot his line:  NOTHING IS FASTER THAN A JUMP

I agree with RuiLoureiro, use ALL form with-in in your code for personal reference and proof of concept.  It cost you NOTHING these days.  Why worry.  This is not 1993.

So now you know why: If you need help use type checking and PTR and all those other goodies that masm want to give you but if you choose to do things for yourself, as what a true assembler is suppose to be all about,  I got one thing to say... "HAVE A NICE FLIGHT"  and don't meet me there, beat me there ...  if you can.  hee hee

[PBrennick]

We have problems if we define a variable as a byte and somewhere we use
                cmp           eax, dword ptr [varname]. Its wrong, of course.

That is an override; it is NOT wrong nor will it cause problems as long as you consider the endian situation.

Paul

[RuiLoureiro]

                We have problems if we define a variable as a byte and somewhere we use
                           cmp           eax, dword ptr [varname]. Its wrong, of course.

That is an override; it is NOT wrong nor will it cause problems as long as you consider the endian situation.
Paul

Hi Paul,  :U
               we cannot use dword ptr or word ptr if we define a variable as a BYTE.
Read an run this:
the solution is correct but we get «There is no solution»

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
    .586
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
Val1        dd 5
Val2        dd 6

Sum         db ?                          ; variable is BYTE
Junk        dd 33333333h
    .code
; ####################################
start:
       
        push    Val2        ; = 6
        push    Val1        ; = 5
        call    TwoAdd
        ; »»»»»»»»»»»»»
        ; The Sum is 11
        ; »»»»»»»»»»»»»
        cmp     dword ptr [Sum], 11  ; we cannto use DWORD PTR
        jne     short @F
       
        print   ustr$(eax)
        print   chr$(13, 10)   
        inkey   "Thats the solution..."
        exit

@@:     print   ustr$(eax)
        print   chr$(13, 10)
        inkey   "There is no solution..."
        exit
;----------------------------------------------------   
TwoAdd      proc
            push ebp
            mov  ebp, esp
   
            mov  eax, [ebp+8]    ; val1
            add  eax, [ebp+12]   ; val2

            mov  [Sum], al

            pop  ebp
            ret  8
TwoAdd      endp
; «««««««««««««««««««««««««««««««««««««««««««««
end start

Rui

[MichaelW]

we cannot use dword ptr or word ptr if we define a variable as a BYTE

This would be a problem with the number of elements in the variable, not with the type of the variable. For example:

variable db 4 dup(0)

This would work for either access, the TYPE operator would return 1, and the SIZEOF operator would return 4.

[PBrennick]

... which means I am correct and your code needs to be adjusted. I am NOT saying it is a good idea or a bad idea. All I am saying is that we all do that all the time to move data quickly in blocks instead of bytes. A lot of string copy routines use overrides and because there is no type checking it will always work. But as I stated before, there CAN be an endian problem but, if there is, it is the fault of the programmer.

Paul

[RuiLoureiro]

we cannot use dword ptr or word ptr if we define a variable as a BYTE

For example:
variable db 4 dup(0)

MichaelW,
               Yes i know, but thats not the problem. The problem is with the code
                i posted before. So, my example doesnt need to be adjusted. The example
                shows what it shows, Paul. When i define a variable as a dword i use it
                as a dword and not as a byte and when i define a variable as a byte i use
                it as a byte and not as a word or dword.
                With variable defined as 4 bytes
                we can access as we want. As byte, as word, as dword, etc. It depends ...
                When i use a name like variable it stands for an address for 4 bytes like
                when i used Sum but now for 1 byte only
Rui

[jj2007]

Before it gets too ideological, here a very practical example (just imagine that "version" sits in an include file that you don't really want to open). I vaguely remember some hll dialects call that a UNION.

Code Select Expand

include \masm32\include\masm32rt.inc

.code
v4 LABEL dword ; a 32 bit integer
version db "Ver3.dll", 0 ; a string

start:
.if v4=="2reV"
MsgBox 0, offset version, "This is the second version of my dll:", MB_OK
.elseif v4=="3reV"
MsgBox 0, offset version, "This is the third version of my dll:", MB_OK
.else
MsgBox 0, offset version, "Unknown version: ", MB_OK
.endif
exit

end start

[RuiLoureiro]

Before it gets too ideological, here a very practical example ...

Hi  jj2007,
                In this particular case, it does the same, but v4 is better than dword ptr

include \masm32\include\masm32rt.inc
.code
;v4   LABEL dword   ; a 32 bit integer
version   db "Ver3.dll", 0   ; version is a string

start:
   .if       dword ptr version =="2reV"
           MsgBox 0, offset version, "This is the second version of my dll:", MB_OK
   .elseif  dword ptr version =="3reV"
           MsgBox 0, offset version, "This is the third version of my dll:", MB_OK
   .else
           MsgBox 0, offset version, "Unknown version: ", MB_OK
   .endif
   exit

end start

Another version

; «««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
    .586
.code
version   db "Ver2.dll", 0    ; a string
start:

   .if     byte ptr [version + 3]=="2"

      MsgBox 0, offset version, "This is the second version of my dll:", MB_OK

   .elseif byte ptr [version + 3]=="3"

      MsgBox 0, offset version, "This is the third version of my dll:", MB_OK
   .else
      MsgBox 0, offset version, "Unknown version: ", MB_OK
   .endif
   exit
end start

Rui  :U

[PBrennick]

Good luck with your programming Rui.

Paul

[MichaelW]

Hi Rui,

It's a matter of terminology. Without looking closely at the previous posts, I assumed that the uppercase BYTE was a type specifier, so I interpreted "define a variable as a BYTE" as "define a variable of type BYTE (which could be a byte array)". You apparently meant it as "define a variable as a single byte", and for that you are right, accessing that single byte as some other size will not work.