guys,
There is dd, etc...
whats the equivalent for sdword?
I'd say it would be a DW as they both take up 4 bytes.
A pseudo HLL notation for a DWORD that is evaluated as signed. Assemblers have a 32 bit hole that you plonk data into, how you evaluate it makes it signed or unsigned.
Oh, I see. It's clear they use the same space and so on, but what would be the reason to declare it as sdword?
Because I've been declaring sdword variables as sdword.
foo struct
aaa dd ?
bbb sdword ?
foo ends
well, at least it helps organizing the code design
I'd just declare it as a 'dw'.
I pretty much declare anything going by the space it takes. As Hutch said, it doesn't really matter, it's just 'space'.
Quote from: Lonewolff on April 22, 2018, 02:49:04 PM
I'd just declare it as a 'dw'.
I pretty much declare anything going by the space it takes. As Hutch said, it doesn't really matter, it's just 'space'.
Hmm, I think I'll stick to sdword. It's the same space but it makes it clearer in the design, mainly for cmps, which must be dealt accordingly
Wolf,
A DW data size is 16 bit, it needs to be DD for 32 bit. What Alex is using is using a form of strong typing to equate the DWORD to an SDWORD which is simply a HLL notation for a signed 32 bit value.
Ah, I always get the notation mixed up. I keep forgetting the first 'd' is declaration. I mixed up dw as meaning double word. :icon_rolleyes:
As you saw in my first reply, I said 4 bytes (32 bit).
include \masm32\include\masm32rt.inc
.data
MyDW dd -100
MySDW SDWORD -100
.code
start:
.if MyDW<0
print "MyDW is below zero", 13, 10
.else
print "MyDW is NOT below zero", 13, 10
.endif
.if MySDW<0
print "MySDW is below zero", 13, 10
.else
print "MySDW is NOT below zero", 13, 10
.endif
inkey chr$(13, 10, "clear enough?")
exit
end start
Hutch & cia,
One last question, please... I've already spent some time trying to figure it out
mov ecx, offset man
mov eax, TYPE man
.IF eax == Player <== man is a Player struct
con "yep, it's right Alex"
.ENDIF
assume ecx: ptr Player ;<== Player is hard coded, I'd like to get the TYPE of man
con "%d %d", [ecx].x, [ecx].y
assume ecx:nothing
In the above code, assume ecx: ptr ... Player is hard coded. I'd like to get the struct of man in there, but "assume ecx: ptr eax" obviously doesn't work.
how can I do this?
Quote from: jj2007 on April 22, 2018, 05:08:08 PM
include \masm32\include\masm32rt.inc
.data
MyDW dd -100
MySDW SDWORD -100
.code
start:
.if MyDW<0
print "MyDW is below zero", 13, 10
.else
print "MyDW is NOT below zero", 13, 10
.endif
.if MySDW<0
print "MySDW is below zero", 13, 10
.else
print "MySDW is NOT below zero", 13, 10
.endif
inkey chr$(13, 10, "clear enough?")
exit
end start
Yep.
any great macro/EQU/MAGIC/etc I could substitute sdword for something like foo sdw ? (it's for aesthetical purposes really!)
sdw equ <SDWORD>
MySDW sdw -100
Not that I advocate that, though. I rarely need SDWORD, but if I need one, I want it to stand out of the crowd:
MbArrayPlot proc arrID, arrTypeAndFlags, apMargins, DotCol, DotSize, xStart, xEnd1 ; 31.3.18, 1990 bytes; testbed
LOCAL oldBrush, oldPen, arrSize, xEnd, mrgLeft, mrgTop, ebxSave, ctRegions, curRegion:SDWORD
LOCAL yRange:REAL4, yMin:REAL4, xRange:REAL4, xMin:REAL4 ; order is important for movups; point count is xEnd-xStart
LOCAL apW, apH, m2xInit, minorX, minorY, ptY, ptX:SDWORD, curY:REAL4, valymax:REAL4, fct:REAL4, LenYval ; , ptCt
LOCAL ctPolyAll, ctPolySub, pAllXY, pHandles, pColours
LOCAL pSubPolyStart, ctVertex, pVertexCounts[1600]:DWORD ; 1. tmp position for closing sub-vertex, 2. array of integers
ClearLocals
How many milliseconds does it take to see that there are two SDWORDs? ;)
P.S.:
.IF eax == Player <== man is a Player struct
con "yep, it's right Alex"
.ENDIF
That may work but it's dangerous because eax just carries the size of Player. It would say yep for any other structure that happens to have that size. Masm and its clones have a possibility to check the type, but it's done in macros. For illustration here an excerpt of the ChkNum macro; note that it delivers different values for DWORD and REAL4 (tmp$ is the name of a variable):
; decide: push the arg itself, or a pointer to the arg?
if (type(tmp$) eq DWORD) or (type(tmp$) eq SDWORD)
NumSize = MbDword
elseif (type(tmp$) eq WORD) or (type(tmp$) eq SWORD) ;; needs wp flag
NumSize = MbDword
aPass$ CATSTR <wp:>, arg
elseif type(tmp$) eq BYTE ;; byte: needs bp flag
NumSize = MbDword
aPass$ CATSTR <bp:>, arg
elseif type(tmp$) eq REAL4 ;; dword or real4: direct push
NumSize = MbReal4
elseif type(tmp$) eq REAL8
NumSize = MbReal8
aPass$ equ <pupo> ;; others: push a pointer to the var
elseif type(tmp$) eq REAL10
NumSize = MbReal10
aPass$ equ <pupo>
elseif type(tmp$) eq QWORD
% echo x=<argX>
NumSize = MbQword
aPass$ equ <pupo>
else
% echo unknown type: tmp$
.err
endif
EXITM %NumSize
Cheers JJ, well... it's a bit of fun
ps: I missed your whole explanation and only saw it now! Thanks once again JJ. I'll have a look
If you want something that looks like strong typing,
LONG equ <DWORD>
Its probably already in the include file but I have not looked. :P
Quote from: hutch-- on April 22, 2018, 06:24:27 PM
If you want something that looks like strong typing,
LONG equ <DWORD>
Its probably already in the include file but I have not looked. :P
Not really! It was just a cosmetic thing in my structure declaration, sdword is fine really.
But one thing I am realizing in asm: every time we ask something, we learn twice as much as one asked.
Hi LordAdef :biggrin:
look at this code, I'll not comment it ;)
299: .if (SDWORD PTR eax > 1)
00007ff7d29e1803 83 F8 01 cmp eax, 0x1
00007ff7d29e1806 7E 05 jle 0x7ff7d29e180d
300: mov ecx, 1
00007ff7d29e1808 B9 01 00 00 00 mov ecx, 0x1
301: .endif
302: .if ( eax > 1)
00007ff7d29e180d 83 F8 01 cmp eax, 0x1
00007ff7d29e1810 76 05 jbe 0x7ff7d29e1817
303: mov ecx, 2
Hi Habran, thanks!
I just want to say I do know the difference btw the two!
Call me a geometric freak, but all I wanted was a short for sdword as with dd, for the simple fact I want my struct definitions to be all aligned... and I like to use sdword in the declaration, so things get clear when coding.
foo struct
a dd ?
b dd ?
c sdword ? <== this vertical unalignment drives me crazy, believe it or not
d dd ?
foo ends
I got away with this:
foo struct
a dd ?
b dd ?
c sdw ? <== looks better and I still know c is sdword
d dd ?
foo ends
Quote from: LordAdef on April 23, 2018, 03:31:48 AM
I want my struct definitions to be all aligned...
You can check the align directive. :t
8)
Quote from: felipe on April 23, 2018, 03:44:01 AM
Quote from: LordAdef on April 23, 2018, 03:31:48 AM
I want my struct definitions to be all aligned...
You can check the align directive. :t
8)
I meant "visual" alignment Felipe
... as in one interrogation mark below the other ......
:greenclp: Gotcha!
Seriously, i think aligning text format when coding should only be considered from left to right, otherwise you will be more concerned with appearance of text, rather than meaning of code :idea:.
:lol: Sorry.
Quote from: felipe on April 23, 2018, 03:59:09 AM
:greenclp: Gotcha!
Seriously, i think aligning text format when coding should only be considered from left to right, otherwise you will be more concerned with appearance of text, rather than meaning of code :idea:.
:lol: Sorry.
I agree with you! But in fact this is something personal. Unorganized things prevent me from thinking.
In fact, code formatting is very important. And I give you and example:
I recently changed the way I was tabbing my code. I noticed Marinus has a larger tab space between the mnemonics and the rest. It is so much easier for me to read Marinus's style of formatting that I adopted his way, and I'm feeling my code is a lot clearer.
Quote from: felipe on April 23, 2018, 03:59:09 AM
...otherwise you will be more concerned with appearance of text, rather than meaning of code...
But also a nicely formatted source code makes it easier to read, especially if posting for others to view.
btw re: formatting
"hard" tabs in others' source code drives me nuts!
I use QE as my editor, and when I view some other source code with multiple nested statements, the code can get so far to the right of the screen and..... :dazzled:
I prefer QEs method of using 4 spaces substitute for tab, rather than the 'hard' tab.
just my two cents worth
Quote from: rsgrn on April 23, 2018, 04:16:57 AM
Quote from: felipe on April 23, 2018, 03:59:09 AM
...otherwise you will be more concerned with appearance of text, rather than meaning of code...
But also a nicely formatted source code makes it easier to read, especially if posting for others to view.
btw re: formatting
"hard" tabs in others' source code drives me nuts!
I use QE as my editor, and when I view some other source code with multiple nested statements, the code can get so far to the right of the screen and..... :dazzled:
just my two cents worth
yet, something that makes life really hard is when one gives martian-crazy-long-unreadable names. Come on...
iSFD_D_GEThstgePTR_ dd 2300
invoke Ishd_USHD_ADBE_TTT, iSFD_D_GEThstgePTR_
Quote from: RussG on April 23, 2018, 04:16:57 AMI prefer QEs method of using 4 spaces substitute for tab, rather than the 'hard' tab.
Hutch will certainly agree with you. I prefer tabs, because it happens often that I have to shift a bunch of lines to the right etc - but that is just another holy war ;-)
Related: Sometimes I see this sort of code formatting:
mov eax, ecx
sub eax, edx
mul ecxIt's driving me nuts, because it forces the eye to jump half a meter to the right to see the operand. IMHO an excellent method to introduce bugs :icon_mrgreen:
Quote from: jj2007 on April 23, 2018, 06:37:19 AM
Quote from: RussG on April 23, 2018, 04:16:57 AM
Related: Sometimes I see this sort of code formatting:
mov eax, ecx
sub eax, edx
mul ecx
It's driving me nuts, because it forces the eye to jump half a meter to the right to see the operand. IMHO an excellent method to introduce bugs :icon_mrgreen:
Oh, this one is awful too!
I know that editor choice is like the choice of girlfriends but there are some fundamentals in code formatting that make the difference between readable code and code that is so obscure that you would not waste your time apart from disassembling it to gain some clarity. A lesson that all of the old fellas learnt long ago was to both format code so it could be read easily AND properly comment code so that you knew what it did a year or so later.
Quote from: hutch-- on April 23, 2018, 11:26:37 AM
I know that editor choice is like the choice of girlfriends but there are some fundamentals in code formatting that make the difference between readable code and code that is so obscure that you would not waste your time apart from disassembling it to gain some clarity. A lesson that all of the old fellas learnt long ago was to both format code so it could be read easily AND properly comment code so that you knew what it did a year or so later.
This is something I learned here! To be honest, I was saved many times by my sometimes over commented code. I over comment, and with time I clean what is really excessive. It's been working for me this way