The MASM Forum

Hello community,

I have some questions but since this is my first post let me first introduce my self to show I'm not looking for trouble.

I'm not new to programming, my background is C++ and PowerShell which are two languages I'm proficient with and have written several working projects so far,
however I don't publicly share any of my projects except only one which you can find in my signature below if you whish to see.

Other major projects I work on include GUI framework and various utility libraries which I personally use to write new stuff, however the reason why I don't share them is
either due to incompatible licenses or because I wish to keep certain stuff for myself.

However when it comes to ASM I'm a new born, so far I've managed to set up a comfortable dev environment and getting some books to help in studying assembly.
The reason why I decided to learn assembly is because so far I have many times stumbled upon various scenarios that require knowing assembly and then I felt bad
for not understanding code or how to do this or that...

I wanted to start learning with nasm assembler because of nicer syntax but due to lack of modern books for X86-64 on Windows I'm it seems forced to use ml64 to make learning
as fast as possible, even though I dislike the syntax of MS assembler.

Here is my starting question!
I see ml64 is Microsoft assembler and what really confuses me is the MASM32 project on this site, I see there is MASM SDK that is presumably open source?
I quickly skimmed trough wikipedia site HERE (https://en.wikipedia.org/wiki/Microsoft_Macro_Assembler) and it doesn't seem to say that MS's ml64 is open source.

So I wonder how is the ml64 that is distributed with Windows SDK different from MASM SDK published on this site?
I assume there is some historical stuff and I would also like to know if there is some difference between MS's software license and masm SDK license?
what starting resources ex. links can you share to help me understand more about masm and MS's assembler?

The Microsoft binaries in the masm32 SDK were an agreement With Microsoft Australia back in 1997. You get any later stuff directly from Microsoft under their conditions.

The 32 and 64 bit SDKs are NOT OPEN SOURCE and never have been. They are copyright FREEWARE.

To use the 64 bit version binaries (ML64 - LINK, you need to obtain them directly from Microsoft.

> I quickly skimmed trough wikipedia site HERE and it doesn't seem to say that MS's ml64 is open source.

ML64 is Microsoft proprietry software, it is not open source.

Welcome brazer :thumbsup:
Good luck

Thank you guys, appreciate your responses!  :smiley:

Welcome to the forum, brazer!

Welcome to the world of low(er)-level programming.

One question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless you're coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

BTW, since you're an experienced C programmer, I'm sure you'll find that it's not difficult at all to translate C to ASM. In fact, that might be a good way for you to approach learning assembler: take a simple C program and translate it. You might want to look at some existing simple assembly-language programs and copy them. I always start my programs from templates I have, rather than trying to write from scratch. I'd suggest a GUI (windowed) application rather than a console (command-window) one, but that's up to you.

Hope to hear news of your first successful "Hello, world!" program soon.

Welcome to the Forum :thup:

Quote from: NoCforMe on January 15, 2023, 12:19:31 PMOne question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless your coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

Correct. However, if you plan to call asm routines from C, and your C compiler likes the 64-bit World, then it's a different story.

I have significant experience in 64-bit land (http://masm32.com/board/index.php?topic=9266.msg111052#msg111052) but do 99% of my coding in 32-bit. It's mostly a matter of habit and taste. I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

Don't be talked out of 64 bit MASM just because a few want to live in the past. Its capable of handling bigger data and written properly, its also faster. Its also current where 32 bit Windows is in its twilight. If you are writing 64 bit C/C++, you need to learn how to call 64 bit MASM procedures, that is among the reasons why 64 bit MASM exists as 64 bit Microsoft C/C++ does not handle inline assembler.

brazer,

welcome to the forum and have a lot of fun. As far as 64 bit programming is concerned, you can trust Hutch's arguments in any case.

Good luck.

Thank you guys for welcome!

Quote from: NoCforMe on January 15, 2023, 12:19:31 PM
One question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless you're coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

It's probably silly reason but why 64-bit is because I feel that learning old concepts first and then new concepts later would take more time than going straight to x64.
I look at it in similar way as to whether one should be learning C before C++ or jumping straight to C++ and save some time.

Can't say for sure but I think understanding 32 bit asm won't be that hard once I get a grasp of x64?
To my current knowledge the only difference is address size, use of segment registers and 64bit specific register names, is there anything else that is significant?

Quote from: hutch-- on January 15, 2023, 04:35:51 PM
Don't be talked out of 64 bit MASM just because a few want to live in the past. Its capable of handling bigger data and written properly, its also faster. Its also current where 32 bit Windows is in its twilight. If you are writing 64 bit C/C++, you need to learn how to call 64 bit MASM procedures, that is among the reasons why 64 bit MASM exists as 64 bit Microsoft C/C++ does not handle inline assembler.

Don't worry I won't be drawn away  :mrgreen:, I already took my path and also I'm obsessed to use cutting edge techniques.

Quote from: jj2007 on January 15, 2023, 01:31:25 PM
I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

Interesting because I'm not able to imagine the benefits of 32bit programming except if you target 32 bit OS or if you want or need reduced memory use which is neglectable for small programs on today's computers.
What makes x64 bit learning curve steeper? I assume it's mostly about how code is written rather than new register names or address size?

Quote from: brazer on January 15, 2023, 11:07:57 PM

Quote from: jj2007 on January 15, 2023, 01:31:25 PM
I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

Interesting because I'm not able to imagine the benefits of 32bit programming except if you target 32 bit OS or if you want or need reduced memory use which is neglectable for small programs on today's computers.
What makes x64 bit learning curve steeper? I assume it's mostly about how code is written rather than new register names or address size?

An example:
WinMain proc
LOCAL msg:MSG
  wc equ [rbx.WNDCLASSEX] ; we use an equate for better readability
  lea rbx, wcx
  mov wc.hInstance, rv(GetModuleHandle, 0)
  mov wc.hIcon, rv(LoadIcon, rax, IDI_APPLICATION)
  mov wc.hIconSm, rax ; the rv macro returns results in rax
  mov wc.hCursor, rv(LoadCursor, NULL, IDC_ARROW) ; get a cursor
  jinvoke RegisterClassEx, rbx ; the window class needs to be registered
  wsStyle=WS_OVERLAPPEDWINDOW or WS_VISIBLE or WS_CLIPCHILDREN
  jinvoke CreateWindowEx, 0, wc.lpszClassName, Chr$("Hello World"), wsStyle, 300+320*@64, 127, 300, 200, NULL, rv(LoadMenu, wc.hInstance, 100), wc.hInstance, NULL
  msgLoop: inc eax
shr eax, 1
je @F ; quit if GetMessage returned 0 (exit OK) or -1 (error), or if CwEx failed
  jinvoke TranslateMessage, addr msg ; translates virtual-key messages into character messages
jinvoke DispatchMessage, addr msg ; dispatches a message to a window procedure
jinvoke GetMessage, addr msg, 0, 0, 0 ; retrieve a message from the queue, and return a BOOL
  jmp msgLoop
@@: jinvoke ExitProcess, msg.wParam
WinMain endp

a) looks suspiciously similar to most standard main functions in assembly
b) assembles as 64- or 32-bit code, just by setting a single switch
c) lots of stuff going on under the hood

So it's all the same? No, because you probably want to touch the bare metal, so you want to go under the hood, and there the learning curve kicks in. Google x64 stack alignment shadow space to get a glimpse of it :cool:

Btw there is no .if eax>ecx or similar in that snippet above. Strangely enough, the snippet assembles with ML64, UAsm and AsmC. If there was a .Repeat  ... inc eax ... .Until eax>100, it would assemble with UAsm and AsmC but not with MASM. Micros*t decided that all that hi level crap that we were used to in 32-bit land was no longer necessary for the 21th Century, so they dropped it. Hutch has created workaround macros, but they won't work with the WatCom clones (UAsm and AsmC). Which is not a problem when coding hello world apps, but when you approach the 10,000 lines, you might appreciate that the clones are a factor 5 or so faster...

My advice? None. Do as you please, you have plenty of choice :bgrin:

brazer,

x64 Windows has a more complex architecture, its stack is complicated and if it is not aligned correctly, it just won't run. A pure mnemonic procedure will run OK but any external calls require correct alignment. ML64 is not trying to be a C/C++ compiler, its a low level assembler and supplied with VS to handle the lack of inline assembler.

For free standing executables, making library modules is simple enough if you know how to write the ML64 code. Others come and go but ML64 is backed by the OS vendor, Microsoft. It is not a warmed over 32 bit assembler but a dedicated 64 bit Windows assembler.

Just be warned that the learning curve with 64 bit MASM is complicated but if you master it, it has the hoot and is more than capable of producing reliable fast 64 bit apps.

64bit biggest advantage is let you alloc almost all 64gb memory,but mostly usage is cg programs and video processing,you have plenty of 16 64 bit register,16 XMM/YMM regs in 64bit
while 32bit restricted to 3.5gb memory and winapi uses 3 registers,so push 3 regs/pop 3 regs after call to use most 32bit registers also fewer 8 XMM/YMM regs


I dont know what your goal is after not being asm newbie
cpp,you use lots of OOP there are some who made MASM OOP
some are also into SSE SIMD 128bit programming like me
here we mostly keep it restricted to use SSE2 to be make it run on older computers
all kinds of programming in asm,even few who make DOS programs

OK, I must trust you guys it will be tricky and time consuming, every beginning sucks..
btw. I found one good and funny reason why here (https://masm32.com/why.htm)

Quotebut the main reason is simply because you can

Lol, I really like that one, it gives a special kind of motivation :thumbsup:

Hi brazer,

Welcome to the Masm Forum.

Quote from: brazer on January 15, 2023, 11:07:57 PM
To my current knowledge the only difference is address size, use of segment registers [...]

Forget segment registers; that went out the window with 16-bit DOS programming on the 8088. No need to touch them, so long as you're not attempting to write kernel code.

Appreciate new replies!

Btw. guys, I wonder how do you format your source files?

Do you do it all yourself by hand?
Do you have some custom made formatters that suit your taste?
And are there some general conventions or online guidelines on how source files should be formatted?

Because I couldn't find any for MASM, I'm currently writing a very simple formatter which I plan to execute on demand from vscode,
because copying sample code from books results in pretty messed up code and adjusting each line is not very pleasant job.

Quote from: brazer on January 16, 2023, 09:31:48 AMhow do you format your source files?

What exactly do you mean? How would you format this little proc?

Format-wise, I see some elements:
- "uses" instead of manually preserving esi and edi
- pString and sLen, instead of pString:DWORD and sLen:DWORD (i.e. using the defaults)
- name of proc in column zero, same for Locals
- afterwards, 2 spaces for the first level, one or more tabs for the next .if etc levels
- mov eax, 123 (not mov eax,   123 or mov eax,123)
- comments separated from code by tabs (you can easily relaunch the tabs vs spaces war here...)

Is that what you mean with formatting?

AdjDlg proc uses esi edi pString, sLen
LOCAL xPosC, yPosC, rc:RECT
  ClearLocals
  invoke GetClientRect, hWnd, addr rc
  .if eax
push edi
mov edi, offset wp ; enable wpos
m2m wpos.wpl.iLength, WINDOWPLACEMENT ; needed once for *etWindowPlacement
mrm wpos.ReHeight, rc.bottom
mrm xPosC, rc.right
mov eax, tbw
movi edx, 511 ; limit tbw to 511
.if eax>edx
xchg eax, edx
mov tbw, edx
.endif
  .endif
  ret
AdjDlg endp

I don't want to get into a fight with my friend JJ here, but I must point out that what he presented here is NOT standard assembly language coding; it's done with a tool that he has constructed called MasmBasic which combines elements of BASIC programming with "pure" assembly language. It's a great tool, but one that I've never used. Just so you know, because some of the constructs here simply won't work with standard MASM (the Micro$oft assembler, ml).

Other than that, this is one possible way to format assembly-language source code. There are others. I prefer a much more straightforward look, one that doesn't involve C-like indentation and the use of macros as seen here. But to each his own.

Here's a small example of how I like to format my code:


;====================================================================
; FillMem (where, howMuch, what)
;====================================================================

FillMem PROC where:DWORD, howMuch:DWORD, what:DWORD

MOV ECX, howMuch
JECXZ exit99

PUSH EDI
MOV EAX, what
MOV EDI, where
REP STOSB
POP EDI

exit99: RET

FillMem ENDP


I prefer the explicit PUSH/POP sequence rather than letting the assembler bracket the PROC with "USES", so I know where that pushing and popping is taking place.

Quote from: NoCforMe on January 16, 2023, 07:09:16 AM
Forget segment registers;

The FS and GS segments are still functional in 64-bit mode.

Well, do you ever need to manipulate them?

brazer,

One thing you do need is a decent editor, one with auto indent and matching tab replacement so your formatting is consistent. The trick with writing assembler code is to lay it out so you can read it next time. Long ago I have written auto formatters (mainly for the practice) but when you are serious, you format manually, you get accuracy and readability and with practice, you get fast enough.

Code formatting is very much a matter of personal taste but making it readable (to you) is important if you have to come back to code you have written some years ago.

Now commenting is also a matter of personal taste, over do it and your code turns into a cluttered mess, under do it and you suffer the WTF problem.

Quote from: NoCforMe on January 16, 2023, 10:55:11 AM
I don't want to get into a fight with my friend JJ here, but I must point out that what he presented here is NOT standard assembly language coding; it's done with a tool that he has constructed called MasmBasic which combines elements of BASIC programming with "pure" assembly language.

David, you are becoming paranoid: with the exception of ClearLocals (my apologies), there is not a trace of MasmBasic in what I posted. There are plenty of sources in \Masm32\examples\*.asm that are formatted similar to my example. In many of them, you will find someproc uses esi edi arg. Get used to it, it saves unnecessary typing and lets you concentrate on good, coherent code.

As to "elements of BASIC programming", almost 100 of the Masm32 SDK examples use the print macro (for example, there are many others). If you hate Basic so much, take on a fight with Hutch, it's his macro.

Sorry, my bad. I saw a bunch of what are obviously macros (ClearLocals, m2m, mrm), plus some undeclared stuff (wp, wpos) that I assumed was from MasmBasic. Nevermind.

Still, to me it illustrates why you might not want to use macros. (I don't use them at all.) There are so many of them, it's easy to get name collisions if you're not familiar with them, and they sometimes make it less obvious what's going on, since there's now a lot of stuff happening "behind the scenes". Just my 2¢ worth.

mov edi, offset wp ; enable wpos
m2m wpos.wpl.iLength, WINDOWPLACEMENT ; needed once for *etWindowPlacement
mrm wpos.ReHeight, rc.bottom

m2m and mrm are Masm32 SDK macros, wp is obviously a standard global variable, wpos is obviously a standard global structure. I suppose using e.g. mov wc.hIcon, rv(LoadIcon, eax, IDI_APPLICATION) would also be an evil offense to the bare metal religion?

push 32512
push eax
call LoadIcon
mov wc[24], eax

Much "purer", right?

I do understand why some folks shy away from macros but masm in both 32 and 64 bit are MACRO ASSEMBLERS and its part of their design. Documentation helps (if you bother to read it) but there is much hack code that you need to get through with the least amount of brain utilised so you can use your brain resources on the stuff that matters, mnemonic coding in algorithms where speed matters.

Quote from: hutch-- on January 16, 2023, 01:34:53 PM
I do understand why some folks shy away from macros but masm in both 32 and 64 bit are MACRO ASSEMBLERS and its part of their design.

Amen :thumbsup:

Quote from: NoCforMe on January 16, 2023, 01:24:31 PMStill, to me it illustrates why you might not want to use macros. (I don't use them at all.)

proc at the beginning and ret at the end of a procedure are macros, you shouldn't use them.

Real Men^TM use formatting such as:
mov eax, 123
mov [Myvar], eax
cmp eax, 0
je EaxWasZero
nop
EaxWasZero:

Softies from the macro brigade prefer...
mov eax, 123
mov Myvar, eax
.if eax
nop
.endif
... because they have more important things to do than praying to the Bare Metal God.

Well, since we're into it now, JJ, might as well take the next step.

1. I'm not a "bare metal" programmer and don't care for that style at all. And yes, I do use a few macros: RET, because I don't want my brain to have to keep track of how many parms are on the stack and have to put a "LEAVE" in every time, and INVOKE, since push-push-call is a pain in the ass.

2. You stated out that "wp is obviously a standard global variable, wpos is obviously a standard global structure". Not obvious to me at all. Here I'll inject a bit of advice to the OP, if I may: I have a system for identifying variables. Much simpler than "Hungarian notation", which is also a pain in the ass in my view. I have 3 types of identifiers:

• Global variables always start with uppercase: MasterControlTable
• Local variables (i.e., on the stack) always start with lowercase: fileHandle
• Constants start with a dollar sign: $mainWindowWidth

Works for me; reduces confusion as to where variables are. Even if you don't like this specific scheme, I suggest coming up with some kind of naming scheme that makes sense to you. As we all know, one of the big problems with programs, especially when they get big, is "name management". Please don't use indecipherable 6-character FORTRAN names!

Oh, and my last piece of advice: Use comments. Lots of them. They're not for other people, though they can be very helpful to them; they're for you. For when you come back to your code 6 months or a year later and try to figure out just what the hell you were trying to do.

 :biggrin:

You guys are too sophisticated for me, while I regularly use descriptive naming for variables, the only method I use is simple prefixes, "h" for handles (in most instances), "p" for pointers in most instances, I don't distinguish between LOCAL and GLOBAL variables as I use name separation between them and draw the distinction on the basis of required scope.

"h" and "p" are good. My point was that it's good to have some kind of system. Nothing like looking at your own code and trying to sort out dozens of names

Quote from: jj2007 on January 16, 2023, 10:34:14 AM
What exactly do you mean? How would you format this little proc?

I see, no guidelines but personal taste, I may change my mind with time but for now I would indent everything except procedure labels and line comments,
and keep inline comments on equal distance and a bit of space and sectioning here and there, therefore something like this:


; Comment at the start of line

AdjDlg proc uses esi edi pString, sLen

LOCAL xPosC, yPosC, rc:RECT
ClearLocals
invoke GetClientRect, hWnd, addr rc

.if eax
push edi
mov edi, offset wp ; enable wpos
m2m wpos.wpl.iLength, WINDOWPLACEMENT ; needed once for *etWindowPlacement
mrm wpos.ReHeight, rc.bottom
mrm xPosC, rc.right
mov eax, tbw
movi edx, 511 ; limit tbw to 511

.if eax>edx
xchg eax, edx
mov tbw, edx
.endif
.endif

ret
AdjDlg endp



@NoCforMe
Certainly like your style

Quote from: hutch-- on January 16, 2023, 12:35:48 PM
One thing you do need is a decent editor, one with auto indent and matching tab replacement so your formatting is consistent. The trick with writing assembler code is to lay it out so you can read it next time. Long ago I have written auto formatters (mainly for the practice) but when you are serious, you format manually, you get accuracy and readability and with practice, you get fast enough.

Code formatting is very much a matter of personal taste but making it readable (to you) is important if you have to come back to code you have written some years ago.

I did suspect it's personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

It seems the biggest dilemma as to what to indent is symbols, macros, directives etc. since there is many of these and anything except mnemonics and comments.
But OK, if it's personal preference then it better stays so.

I'm pretty sure a lot of stuff is personal perference not just coding style, editors, debuggers and what not, easy to spark a fight over these things hehe :biggrin:

Yes, editors (and the other stuff you mentioned) are definitely personal preferences. Not trying to push it, but I just posted a new version of my editor (http://masm32.com/board/index.php?topic=10319.msg117632#msg117632) which I've been using for the last couple months to edit assembly-language source. You might try it out. There are, of course, others here; there's Qeditor (by Hutch) in the MASM32 package, and I think others as well. Anyhow, if you feel like it, give mine a spin. I can tell you that it is stable and won't crash, even if it isn't 100% finished. (I call it 90% done with 90% to go.)

Something else: you heard mention of MasmBasic here. This is JJ's creation, truly a labor of love. It's a complete integrated environment, I guess you could call it an IDE, for assembly programming that includes a ton of useful stuff, including a RichEdit editor, debugging tools, lots of stuff. I don't use it myself because it's too much of a "toaster" for me (stick in a slice of bread and out pops the toast). But that's just me; I like to "roll my own". But lots of folks really like using it. It's included in the MASM32 download, and if you have any questions JJ can answer them, of course.

Lots of ways you can go here ...

There is also different taste in assembler, ml or uasm
Good thing to use a debugger to single-step thru code to get better understanding how it works
When fpu registers move up/downposition, you can use many fp registers and correct after run debugger to correct st0-st7
SSE packed compares that produces masks 0 or 0ffffh
Understand flags
For me any text editor can be used to write code,even on my Android tablets

Quote from: brazer on January 16, 2023, 03:51:07 PM

Code Select Expand


; Comment at the start of line

AdjDlg proc uses esi edi pString, sLen

LOCAL xPosC, yPosC, rc:RECT
ClearLocals
invoke GetClientRect, hWnd, addr rc

.if eax
push edi
.endif

ret
AdjDlg endp

My version:
AdjDlg proc uses esi edi pString, sLen  ; Comment at the start of proc
LOCAL xPosC, yPosC, rc:RECT
  ClearLocals
  invoke GetClientRect, hWnd, addr rc
  .if eax
push edi
  .endif
  ret
AdjDlg endp

Assembly is a "vertical" language: many short instructions. No uppercase stuff unless it's Windows constants.
My procedures are often more than 40 lines long, so inserting empty lines means I see less lines - no good. My "main thread" starts in column 2, every .if or .Repeat adds a tab. When you reach level 5 or 7, it becomes important :biggrin:

Again, that's mostly personal preference - but there also merely technical considerations:
- all my procs have their names in column 0 and their endp, too
- all my macros have their names in column 0 and their endm, too

The reason is a function of my editor that allows me to select proc, then right-click a popup and choose "Select proc or macro". The editor looks for <CrLf>somename proc, then <CrLf>somename endp, and voilà, you can press Ctrl X to move safely an entire 500-line procedure to another place or file.

As others have said, use whatever you like but be coherent. Many of us like automating such stuff, and self-inflicted rules help a lot ;-)

Quote from: NoCforMe on January 16, 2023, 05:24:20 PMMasmBasic ... is included in the MASM32 download

Thanks, David. MasmBasic and its editor, RichMasm, are not included in the Masm32 SDK, there are a separate download (http://masm32.com/board/index.php?topic=94.0) and a dedicated sub-forum (http://masm32.com/board/index.php?board=57.0), but they build on the Masm32 SDK and are fully compatible with it. Installation details are here (https://www.jj2007.eu/Masm32_Tips_Tricks_and_Traps.htm), a glimpse at the additional functions here (http://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1019).

Here is a sample of my own personal style for pure mnemonic code. Pure 64 bit with /LARGEADDRESSAWARE option.

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

NOSTACKFRAME

char_fill proc

  ; rcx = memory address
  ; rdx = byte count
  ; r8  = char

    sub rcx, 1
  @@:
    add rcx, 1
    mov BYTE PTR [rcx], r8b
    sub rdx, 1
    jnz @B

    add rcx, 1
    mov BYTE PTR [rcx], 0       ; zero terminate fill

    ret

char_fill endp

STACKFRAME

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

Quote from: NoCforMe on January 16, 2023, 05:24:20 PM
Yes, editors (and the other stuff you mentioned) are definitely personal preferences. Not trying to push it, but I just posted a new version of my editor (http://masm32.com/board/index.php?topic=10319.msg117632#msg117632) which I've been using for the last couple months to edit assembly-language source. You might try it out. There are, of course, others here; there's Qeditor (by Hutch) in the MASM32 package, and I think others as well.

I've run it and clicked around, you've surely put a lot of time crafting it, good job!, I also looked at screenshots of others here (https://masm32.com/board/index.php?topic=7655.0)
at first glance there are benefits over vscode like toolbar buttons and easy to access snippets in your editor, it certainly feels more close to an IDE than just editor.

However I'm really used to vscode and have already spent days configuring it for asm and launching external debugger.

Quote from: daydreamer on January 16, 2023, 07:24:55 PM
Good thing to use a debugger to single-step thru code to get better understanding how it works

Certainly agree, debugger is probably our best friend, I use WinDbg Preview (https://apps.microsoft.com/store/detail/windbg-preview/9PGJGD53TN86?hl=en-us&gl=us) mainly because it allows docking windows to my liking and because of good dark theme,
it's also launchable from command line with customized setup which is very useful for integration with vscode.

Hopefully some useful info for you here. This regards the "Sacred Registers".

In C, you're insulated from this, but when you start writing assembly language, there are some "gotchas" you need to be aware of. One of them is how certain registers need to be handled. (This post applies to 32-bit programming; 64-bit has similar but different register usages.)

Review: the X86 has 4 "general-purpose" registers, EAX, EBX, ECX, EDX, plus some specialized ones: ESI, EDI, ESP, EBP. (I don't include the instruction pointer, EIP, since this is only implicitly manipulated by the programmer, through CALL or JMP.) 3 of the 4 GP registers are considered "scratch", meaning you can change them at will without regard to saving them, unless you need them for some use in your code. That means that you cannot expect these registers to be preserved across any subroutine calls.

The exception is EBX, which is one of the Sacred Registers. This has 2 consequences:

• You must save and restore EBX if you use it in your code
• You can expect EBX to be preserved across any function call, including all the Win32 calls

So if you need EBX for some reason in your code, you need to do something like this:


PUSH EBX ;Save sacred register
MOV EBX, EAX
SHL EBX, 1

... ;Do some more stuff

POP ;Restore sacred reg.


(or if this code is inside a PROC, you can add USES EBX to the proc declaration so the assembler will PUSH and POP it for you)

If you have some code where you need to make repeated references to some piece of data, a structure or other entity, you can set EBX to that item and use it across any number of function calls, like so:


LOCAL aStruct:SOME_STRUCT

PUSH EBX ;Save the sacred register

LEA EBX, aStruct ;Point to the structure
MOV [EBX].SOME_STRUCT.aMember1, $someValue
MOV [EBX].SOME_STRUCT.aMember2, $someOtherValue

INVOKE <some Win32 API function>

; EBX still points to our structure:
MOV [EBX].SOME_STRUCT.aMember3, $yetAnotherValue1
MOV [EBX].SOME_STRUCT.aMember4, $yetAnotherValue2

INVOKE <another Win32 API function>

POP EBX ;Restore sacred reg.
RET


Again, just be sure to preserve the original value of this register.

The other 2 sacred registers are ESI and EDI. I'll cover these in the next post about the string instructions. Like EBX, if you use these registers, be sure to save and restore them.

The X86 processors have a very handy set of instructions known as "string instructions". These are designed to easily and quickly load, store and compare arrays of memory data. They were designed for use with text (ASCII data), but they work on any kind of data; they're blissfully unaware of what kind of bytes are being transferred or compared.

The instructions are:

• LODSx:   Load data from [ESI] into AL/AX/EAX
• STOSx:   Store data @ [EDI] from AL/AX/EAX
• MOVSx:   Move data from [ESI] to [EDI]
• SCASx:   Compare data @ [EDI] to AL/AX/EAX
• CMPSx:   Compare data @ [ESI] to [EDI]

where "x" is B for byte, W for word or D for doubleword.

There's also a REP prefix for STOSx and MOVSx which repeats the operation the value in the ECX register times. REP STOSB will store AL starting at [EDI] ECX times. These instructions automatically increment (or decrement, see below) the index register being used, ESI, EDI, or both.

The SCASx and CMPSx instructions have optional prefixes: REPNE repeats the operation until the result of the comparison is "not equal", while REPE repeats while the result is "equal". (The alternate spellings, REPNZ and REPZ are just synonyms.) REPNE SCASB is very useful for searching for a byte value in an array; I use it all the time in parsing.

Like EBX, ESI and EDI are Sacred Registers, so you must preserve them if you use them (and you can expect their values to be preserved across any function calls).

So let's say you want to make a copy of a multibyte structure:

LOCAL srcRect:RECT, destRect:RECT

PUSH ESI ;Save the sacred registers
PUSH EDI
LEA ESI, srcRect
LEA EDI, destRect
MOV ECX, SIZEOF RECT
REP MOVSB
POP EDI
POP ESI


(or include USES ESI EDI in your PROC declaraction)

* Gotcha: I mentioned that the index registers auto-increment; they can also auto-decrement. This depends on the setting of the direction flag. Normally this flag is set to its default, which is auto-increment. If you use the STD ("set direction") instruction, the instructions reverse and auto-decrement. (You can restore the default with CLD.) I have never, ever found the need to mess with this flag, so my advice is to stay away from it. (If you're a paranoid programmer you can use CLD inside a critical routine, but again, I've never had the need to do this.)

NoCforMe,

Thank you this is useful info, I'm already aware of registers that need to be "preserved", including r12-r15 and xmm6-xmm15 in addition to those you mentioned.
But the rest is all new new stuff to me for which I'll come back to recall it.

I do however have some more "philosophical" questions regarding register names...
From what I gathered so far most of the registers names have abbreviations "encoded" in them ex:

  - RAX (accumulator register)
  - RBX (base register)
  - RCX (count register)
  - RDX (data register)

- Pointer registers

  - RIP (Instruction Pointer)
  - RSP (Stack Pointer)
  - RBP (Base Pointer)

- Index registers

  - RSI (Source Index)
  - RDI (Destination Index)

Knowing this it's easy to associate, remember and know what's the purpose of certain registers,
however from what I see, ex. from your examples, this is not written in stone.

ESI and EDI which are supposed to be "index registers" aren't always that? it may be used for what ever at least so it seems from your example,
I assume this applies to all other registers above and probably few others, so my question then is, what's the purpose of abbreviations if registers can be used for anything you like?

Excluding ofc. RSP, RIP which can't, but at least abbreviation for those serves their true purpose.

Quote from: brazer on January 17, 2023, 02:06:00 PM
I do however have some more "philosophical" questions regarding register names...
From what I gathered so far most of the registers names have abbreviations "encoded" in them ex:

  - RAX (accumulator register)
  - RBX (base register)
  - RCX (count register)
  - RDX (data register)

I was going to mention that: the registers on the first of this family (8086/8088) had AX, BX, CX and DX as "general-purpose" registers, except that they weren't really:

• AX: Yes, "accumulator", target of string load/store, multiplication and division
• BX: "Base": along with SI & DI the only registers you could use to reference memory and also the base register for the XLAT instruction
• CX: "Count": counter for LOOP and for ops with REP prefix
• DX: "Data" register, used to hold index of I/O port for IN & OUT

Those names are now just historical curiosities. Most of those attachments are no longer true, except that EAX is still the dividend (low word) and the quotient for DIV and the product (low word) for MUL, and still the target of those string instructions. ECX is still used as a counter for string instructions and LOOP. All of them can be used for memory references (along with ESI, EDI, ESP and EBP). Nothing special about using ESI & EDI, so long as you save and restore them.

BTW, the rule of saving the "sacred registers" has nothing at all to do with the processor; it couldn't care less what you do with those registers. It's simply a convention used by well-behaved programs under Windows (and also *nix?).

Anything you posted above about 64-bit registers I can't comment on, as I'm not familiar with that scheme. What you wrote looks right, though.


[/list]

Quote from: NoCforMe on January 17, 2023, 03:22:36 PMThose names are now just historical curiosities.

As you write immediately after, these registers are still specialised for certain tasks (xlat, lods*, div). However, you can use them all as general purpose registers, with minor limitations: you can't access the bytes of esi and edi.

Btw. you guys feel free to call me a maniac, even though most of you suggested me to format my sources by hand I just couldn't resist to automate this process,
because as I copy samples from PDF's it really get's unformatted and difficult to read sometimes.

Didn't sleep well until I made it which for now at least let's me copy and format sample code from the book without having to adjust each line, it's annoying as hell.

I've put it on public display and updated my signature below, if nothing else this signature is more appropriate for forums than the previous one since it's at least a little related to assembly lol  :smiley:

Quote from: brazer on January 17, 2023, 08:38:41 PM
Btw. you guys feel free to call me a maniac

Welcome in the club :thup:

I'd like to test your tool, but 29 files in the asmformat folder are a bit scary, and my C++ installation is broken thanks to the infamous clean temp directory of old il files (https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/command-line-error-d8037?view=msvc-170) bug. Can you post the binaries, Win7 compatible if possible?

Quote from: brazer on January 17, 2023, 08:38:41 PMsample code from the book

There are many good code samples in \Masm32\examples, don't miss them. Simple but very clear.

Btw how do you extract the code from a pdf? Sometimes I use AbleWord (http://www.ableword.net/downloads.html) for that, perhaps you have a better one?

Historical ax,bx,cx,dx,si,Di, BP, sp registers in 16bit real mode,put restrictions used in indirect addressing, but in 32bit freely mix 2 of these registers
Bx and BP = base registers,one of them combined with either si or di = index registers +scale register 2x,4x,8x
Mov ax,[bx+si+adress]
Philosophical on RIP register, might be a hint of RIP of 32 bit is coming?  :tongue: :greenclp:

Quote from: jj2007 on January 17, 2023, 08:49:34 PM
I'd like to test your tool, but 29 files in the asmformat folder are a bit scary, and my C++ installation is broken thanks to the infamous clean temp directory of old il files (https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/command-line-error-d8037?view=msvc-170) bug. Can you post the binaries, Win7 compatible if possible?

Thank you for interest, those are all small sources mostly error handling and boiler plate code which I plan to use, I've compiled executables including for windows 7 and VC++ redistributables, however VC++ redist fails to install on my Win7 virtual machine probably because system is out of date but it may work in your case.
They are here (https://github.com/metablaster/ASM-Formatter/releases/tag/v0.1.0)
Looking forward for your opinion!

Quote from: jj2007 on January 17, 2023, 08:49:34 PM
There are many good code samples in \Masm32\examples, don't miss them. Simple but very clear.

Btw how do you extract the code from a pdf? Sometimes I use AbleWord (http://www.ableword.net/downloads.html) for that, perhaps you have a better one?

I'll take a look at samples in \Masm32, but those in the book are easy to understand for a beginner, since every sample is explained in detail how it works.

I'm using normal copy\paste out of the pdf, but there are always some spaces at every start of line, and everything is on same column and sometimes on different columns,
blank lines are not preserved and it's not always the same or as presented in the book, which makes harder to focus on sections of code, but this is now solved.

Quote from: daydreamer on January 17, 2023, 10:40:22 PM
Historical ax,bx,cx,dx,si,Di, BP, sp registers in 16bit real mode,put restrictions used in indirect addressing, but in 32bit freely mix 2 of these registers
Bx and BP = base registers,one of them combined with either si or di = index registers +scale register 2x,4x,8x
Mov ax,[bx+si+adress]
Philosophical on RIP register, might be a hint of RIP of 32 bit is coming?  :tongue: :greenclp:

OK so I don't need to bother then if it's all just historical reasons, but in any case knowing the "long" names of registers makes it easier to remember and differentiate them so that's something,
since there are so many of them to remember them all at once.

Hah, I like your joke about RIP register lol  :rofl:
I don't know if and when will 32 bit systems go out of scope, likely not anytime soon yet, there is still a bunch of devices running on 32 bit CPU's.

What criteria would there have to be to drop 32 bit OS support? hardware manufacturers perhaps? probably more likely than OS vendors.

brazer,

Something we have seen before is people making the wrong assumptions while collecting a range of information about writing code in assembler. The bottom line is if you want to succeed, you will learn how to write mnemonic code and the intricacies of the Intel instruction set. Then there is the base architecture in either 32 or 64 bit and a very large range of Windows API functions.

When you have learnt enough, you will know what to use and what tools you need but unless you start writing pure mnemonic code, you will not get to the starting line.

hutch--,

I understand your point and believe you that writing code is most important.

Your assumption is correct, I must admit, I've certainly spent a whole week until now preparing my self to have all the preparatory stuff in place,
dev environment, books, choosing a debugger, tools, coding style, web resources and what not...

I'll certainly jump into writing code soon no doubt about that, for now as I discover the fundamentals I'm starting to see the beauty of assembly,
just by listening how you guys love writing assembly only gives me an additional inspiration, I see you're experts and not just some random coders hanging around.

There is one "sickness" of mine however, I really enjoy being pedantic and that sticks with me since ever like a curse, it often times consumes my time and sometimes I just can't help myself.
But I'll listen to your advice and jump into asm ASAP :wink2:

Quote from: jj2007 on January 17, 2023, 08:16:15 PM
[...] you can't access the bytes of esi and edi.

Right, unless you do something like this


MOV EAX, [ESI]
CMP AL, '.'
JE isPeriod

Quote from: brazer on January 18, 2023, 05:36:05 AM
Hah, I like your joke about RIP register lol  :rofl:
I don't know if and when will 32 bit systems go out of scope, likely not anytime soon yet, there is still a bunch of devices running on 32 bit CPU's.

What criteria would there have to be to drop 32 bit OS support? hardware manufacturers perhaps? probably more likely than OS vendors.

Not bloody likely anytime soon, if ever. Despite Micro$oft's wet dreams of everyone abandoning everything else in favor of whatever the Latest and Greatest is. For chrissakes, there are still systems out there running 16-bit DOS code that have to be maintained. So I'd say that reports of the demise of Win32 are greatly exaggerated.

Question for you: You said you were copying ASM examples out of PDF files. Did you list any such sources? I couldn't find any searching this thread. I'd be curious to see what they look like. In the meantime, there is plenty of example code posted in non-PDF format, which may be easier to deal with and re-format.

An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

Just for the heck of it, here's my assembler "skeleton" that I use to start new (GUI) programs. It creates a desktop window (with a status bar) and a window procedure, centers it on the desktop. (I have other skeletons, one for creating console apps, another for creating apps that use a dialog box as the main window, a really useful thing as it eliminates the need to create controls using CreateWindowEx(). You'll need either a resource editor, or what I use, a dialog editor (my homemade one) that creates dialog memory templates you can simply INCLUDE in your .asm source. (I'm not a big fan of using resource files; yet another file to link and keep track of.)


;============================================
; -- Skeleton --
; -- [project title here] --
;
;============================================

.nolist
include \masm32\include\masm32rt.inc
.list

;============================================
; Defines, macros, prototypes, etc.
;============================================

$mainWinWidth EQU 600
$mainWinHeight EQU 500

;===== Window styles: =====
; Change 1st 2 styles to "WS_OVERLAPPEDWINDOW" if you want a resizeable window:
$mainWinStyles EQU WS_CAPTION or WS_SYSMENU or WS_CLIPCHILDREN or WS_VISIBLE

;===== Window background colors: =====
$bkRED EQU 254
$bkGRN EQU 243
$bkBLUE EQU 199

$BkColor EQU $bkRED OR ($bkGRN SHL 8) OR ($bkBLUE SHL 16)

$SBID EQU 1111
$SBX EQU 0
$SBY EQU $mainWinHeight - $SBHeight
$SBWidth EQU $mainWinWidth
$SBHeight EQU 40
$numStatusParts EQU 4

$SB_styles EQU WS_CHILD OR WS_VISIBLE

;============================================
; HERE BE DATA
;============================================
.data

WC WNDCLASSEX < SIZEOF WNDCLASSEX, \
CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW, \
NULL, \ ;lpfnWndProc
NULL, \ ;cbClsExtra
NULL, \ ;cbWndExtra
NULL, \ ;hInstance
NULL, \ ;hIcon
NULL, \ ;hCursor
NULL, \ ;hbrBackground
NULL, \ ;lpszMenuName
NULL, \ ;lpszClassName
NULL > ;hIconSm

StatusParts DD 50, 150, 250, -1

NullString DB 0

MainClassName DB "[class name here]", 0

MainTitleText DB "[window title here]", 0

;============================================
; UNINITIALIZED DATA
;============================================
.data?

MainWinHandle HWND ?

InstanceHandle HINSTANCE ?

StatusHandle HWND ?
SBheight DD ?


;============================================
; CODE LIVES HERE
;============================================
.code

start: INVOKE GetModuleHandle, NULL
MOV InstanceHandle, EAX

CALL WinMain
INVOKE ExitProcess, EAX


;====================================================================
; Mainline proc
;====================================================================

WinMain PROC
LOCAL msg:MSG, brush:HBRUSH, wX:DWORD, wY:DWORD, gpRect:RECT

; Create  brush to set background color:
INVOKE CreateSolidBrush, $BkColor
MOV brush, EAX

; Register class for parent window:
MOV EAX, InstanceHandle
MOV WC.hInstance, EAX
MOV WC.lpfnWndProc, OFFSET MainWindowProc
MOV EAX, brush
MOV WC.hbrBackground, EAX
MOV WC.lpszClassName, OFFSET MainClassName
; INVOKE LoadIcon, InstanceHandle, 500    ; icon ID
; MOV WC.hIcon, EAX
MOV WC.hIcon, NULL
INVOKE LoadCursor, NULL, IDC_ARROW
MOV WC.hCursor, EAX
INVOKE RegisterClassEx, OFFSET WC

INVOKE GetSystemMetrics, SM_CXSCREEN
MOV EDX, $mainWinWidth
CALL CenterDim
MOV wX, EAX
INVOKE GetSystemMetrics, SM_CYSCREEN
MOV EDX, $mainWinHeight
CALL CenterDim
MOV wY, EAX

; Create our main window:
INVOKE CreateWindowEx, WS_EX_OVERLAPPEDWINDOW, OFFSET MainClassName,
OFFSET MainTitleText, $mainWinStyles, wX, wY, $mainWinWidth,
$mainWinHeight, NULL, NULL, InstanceHandle, NULL
MOV MainWinHandle, EAX

; Create the status bar:
INVOKE CreateStatusWindow, $SB_styles, OFFSET NullString, MainWinHandle, $SBID
MOV StatusHandle, EAX
MOV EDX, EAX
; Get the height of the status bar:
INVOKE GetWindowRect, EDX, ADDR gpRect
MOV EAX, gpRect.bottom
SUB EAX, gpRect.top
MOV SBheight, EAX

; Divide status bar into parts:
INVOKE SendMessage, StatusHandle, SB_SETPARTS, $numStatusParts, OFFSET StatusParts

;============= Message loop ===================
msgloop:
INVOKE GetMessage, ADDR msg, NULL, 0, 0
TEST EAX, EAX ;EAX = 0 = exit
JZ exit99
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
JMP msgloop

exit99: MOV EAX, msg.wParam
RET

WinMain ENDP

;====================================================================
; Main Window Proc
;====================================================================

MainWindowProc PROC hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
LOCAL gpRect:RECT

MOV EAX, uMsg
; CMP EAX, WM_COMMAND
; JE do_command
CMP EAX, WM_CREATE
JE do_create
CMP EAX, WM_CLOSE
JE do_close
CMP EAX, WM_SIZE
JE dosize

dodefault:
; use DefWindowProc for all other messages:
INVOKE DefWindowProc, hWin, uMsg, wParam, lParam
RET

do_command:
; MOV AX, WORD PTR wParam
; CMP AX, ---- ;Check command code here.
; JE ---

do_create:

; Window creation code here

XOR EAX, EAX
RET

dosize:
INVOKE GetClientRect, hWin, ADDR gpRect
MOV EDX, gpRect.bottom
SUB EDX, gpRect.top
SUB EDX, SBheight
INVOKE MoveWindow, StatusHandle, 0,  EDX, gpRect.right, SBheight, TRUE

XOR EAX, EAX
RET

do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET

MainWindowProc ENDP

;====================================================================
; CenterDim
;
; Returns half screen dimension (X or Y) minus half window dimension
;
; On entry,
; EAX = screen dimension
; EDX = window dimension
;
; Returns:
; sdim/2 - wdim/2
;====================================================================

CenterDim PROC

SHR EAX, 1 ;divide screen dimension by 2
SHR EDX, 1 ;divide window dimension by 2
SUB EAX, EDX
RET ;Return w/# in EAX

CenterDim ENDP

END start


Quote from: NoCforMe on January 18, 2023, 11:18:57 AM

Quote from: jj2007 on January 17, 2023, 08:16:15 PM
[...] you can't access the bytes of esi and edi.

Right, unless you do something like this

Code Select Expand


MOV EAX, [ESI]
CMP AL, '.'
JE isPeriod

What I meant is:
al is the byte of eax
bl is the byte of ebx
cl is the byte of ecx
dl is the byte of edx
...
but that won't work for esi, edi, ebp and esp :sad:

Yes, exactly, and isn't it kind of amazing that we can do that with EAX ... EDX at this late date? I mean, I use that capability all the time (but that might be because as Hutch might accuse me, I'm programming "in the past"). Those are historical artifacts dating back to the 1980s. I'm glad Intel left them in for us to use.

Quote from: brazer on January 16, 2023, 03:51:07 PM
I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here. And my gawd, it's a lengthy bunch of crap: meticulously sectioned, painstakingly annotated. Still crap.

I mean, it's fine to have strong opinions about good formatting style: we all do. Some are better than others, of course, but in the end it's all pretty subjective. (Well, I have some formatting rules that I think are objectively better, like identifying locals vs. globals via capitalization, but if someone just doesn't like that style then it doesn't matter if it's better or not.) But to try to impose your style on the rest of the world? Buddy, that just ain't gonna work. (And I hate his use of lowercase throughout!)

If I might ask, what kind of code will you be writing? I took a quick peek at your GitHub (is that the right term?); are you a gamer? Just curious about what kind of apps you'll be creating.

Whatever you do, since we all know that assembler is not the hot current production tool, nor will it ever be, have fun with it. (That why I use it.)

Quote from: NoCforMe on January 18, 2023, 01:08:31 PM

Quote from: brazer on January 16, 2023, 03:51:07 PM
I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here.

Me too :biggrin:

    call CopyString
    inc di
    mov si, OFFSET DTA_TIME     ;Copy time, date and size
    mov cx, 4
    rep movsw
    mov ah, 4Fh                 ;Next filename
    int 21h
    jnc StoreFileName
    mov [last], bx              ;Save pointer to last file entry
    mov al, [keepSorted]        ;If returning from EXEC, need to resort

QuoteThe primary problem with this program is the formatting. The label fields overlap the mnemonic fields (in almost every instance), the operand fields of the various instructions are not aligned

                call    CopyString
                inc     di                      ;Skip zero byte (???).

                mov     si, offset DTAtime      ;Copy time, date and size
                mov     cx, 4
        rep     movsw


I thoroughly hate when coders use
mov eax
instead of
mov eax

The human eye is not happy with jumping all over the place - mov eax is easier to read and to understand :cool:

As to lowercase vs uppercase: I prefer offset somevar, much easier to read and to type.

    mov [last], bx              ;Save pointer to last file entry
    mov al, [keepSorted]        ;If returning from EXEC, need to resort

Much better:
    mov last, bx              ;Save pointer to last file entry
    mov al, keepSorted        ;If returning from EXEC, need to resort

That [bracket] crap is coming from older assemblers; not needed with MASM/UAsm/AsmC.

QuoteMost studies on the subject indicate that routines in excess of 150-200 lines of code tend to contain more bugs

One of my WndProcs has more than 1600 lines :badgrin:

Quote from: NoCforMe on January 18, 2023, 11:49:10 AM
Question for you: You said you were copying ASM examples out of PDF files. Did you list any such sources? I couldn't find any searching this thread. I'd be curious to see what they look like. In the meantime, there is plenty of example code posted in non-PDF format, which may be easier to deal with and re-format.

An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

The following are the only 2 comprehensive books (1600 pages total) about modern assembly which I use:
https://www.amazon.com/Art-64-Bit-Assembly-Language/dp/1718501080
https://www.amazon.com/Modern-X86-Assembly-Language-Programming/dp/1484240626

Reason why I prefer books over tutorials and samples on the net etc. is because books are beginner friendly, go step by step, from easy toward complex and every concept and keyword in
code samples is explained in detail.

I just finished chapter 1 out of 16 of the first book, that's some 8 code samples, one of which looks like this:

; Listing 1 - 5
; A "Hello, world!" program using the C / C + + printf() function to
; provide the output.
option casemap:none
.data
; Note: "10" value is a line feed character, also known as the
; "C" newline character.
fmtStr byte 'Hello, world!', 10, 0
.code
; External declaration so MASM knows about the C / C + + printf()
; function.
externdef printf:proc

; Here is the "asmFunc" function.
public asmFunc
asmFunc proc
; "Magic" instruction offered without explanation at this point:
sub rsp, 56
; Here's where we'll call the C printf() function to print
; "Hello, world!" Pass the address of the format string
; to printf() in the RCX register. Use the LEA instruction
; to get the address of fmtStr.
lea rcx, fmtStr
call printf
; Another "magic" instruction that undoes the effect of the
; previous one before this procedure returns to its caller.
add rsp, 56

ret                          ; Returns to caller

asmFunc endp
end


I can imagine how funny this code may look to you, but to me, I didn't understand anything how this code works until I've read the explanation,
heavy commenting and step by step explanation found in the book is very useful to me, primarily because I don't need to go google out anything nor ask questions, it's all there.

Once I finish those books, using samples, tutorials, docs and other types of resources will be easier.

Quote from: NoCforMe on January 18, 2023, 11:49:10 AM
An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

Just for the heck of it, here's my assembler "skeleton"...

snippets and templates are cool, I can imagine they are much more useful in assembly than in other languages.

I'll certainly make some of my own in the future, but for now I just need to get grasp of the very basic stuff, memorizing mnemonics, calling conventions, register names, directives,
language grammar, history and all the very basic stuff to get some confidence.

While I'm familiar with windows API, I'm certainly having difficulty understanding how your sample works, it will take some time until I get a glimpse over basics.

And my asm formatter, if you look at the sample code above it takes to format it by hand and get annoying, I'll be updating my formatter little by little as I discover new language constructs but I consider it
finished for my needs.

OK, here's another skeleton, but totally pared down: you can't get any simpler than this if you want to create a window. (A console app could be even smaller.)


;============================================
; -- Absolute Minimum Skeleton --
;
; Creates a resizeable window, and that's it.
;============================================

.nolist
include \masm32\include\masm32rt.inc
.list

;============================================
; HERE BE DATA
;============================================
.data

WC WNDCLASSEX < SIZEOF WNDCLASSEX, \
CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW, \
NULL, \ ;lpfnWndProc
NULL, \ ;cbClsExtra
NULL, \ ;cbWndExtra
NULL, \ ;hInstance
NULL, \ ;hIcon
NULL, \ ;hCursor
NULL, \ ;hbrBackground
NULL, \ ;lpszMenuName
NULL, \ ;lpszClassName
NULL > ;hIconSm


MainClassName DB "AbsMinSkel", 0
MainTitleText DB "Absolute Minimum Skeleton Demo", 0

;============================================
; UNINITIALIZED DATA
;============================================
.data?

InstanceHandle HINSTANCE ?

;============================================
; CODE LIVES HERE
;============================================
.code


start: INVOKE GetModuleHandle, NULL
MOV InstanceHandle, EAX

CALL WinMain
INVOKE ExitProcess, EAX

;====================================================================
; Mainline proc
;====================================================================

WinMain PROC
LOCAL msg:MSG

; Register class for parent window:
MOV EAX, InstanceHandle
MOV WC.hInstance, EAX
MOV WC.lpfnWndProc, OFFSET MainWindowProc
INVOKE GetStockObject, WHITE_BRUSH ;Use a Windows stock item.
MOV WC.hbrBackground, EAX
MOV WC.lpszClassName, OFFSET MainClassName
MOV WC.hIcon, NULL
INVOKE LoadCursor, NULL, IDC_ARROW
MOV WC.hCursor, EAX
INVOKE RegisterClassEx, OFFSET WC

; Create our main window:
INVOKE CreateWindowEx,
WS_EX_OVERLAPPEDWINDOW, ;EXstyles
OFFSET MainClassName,
OFFSET MainTitleText,
WS_OVERLAPPEDWINDOW or WS_CLIPCHILDREN or WS_VISIBLE, ;window is resizeable
100, ;X-pos
100, ;Y-pos
600, ;width
400, ;height
NULL, ;parent (none=desktop)
0, ;menu/ID (none needed here)
InstanceHandle, ;instance handle
0 ;param (not used here)

;============= Message loop ===================
msgloop:
INVOKE GetMessage, ADDR msg, NULL, 0, 0
TEST EAX, EAX ;EAX = 0 = exit
JZ exit99
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
JMP msgloop

exit99: MOV EAX, msg.wParam
RET

WinMain ENDP

;====================================================================
; Main Window Proc
;====================================================================

MainWindowProc PROC hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
LOCAL gpRect:RECT

CMP uMsg, WM_CLOSE
JE do_close

dodefault:
; use DefWindowProc for all other messages:
INVOKE DefWindowProc, hWin, uMsg, wParam, lParam
RET

do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET

MainWindowProc ENDP

; This sets the program entry point for Windows:
END start



I'm assuming you're familiar with Windows, specifically with the Win32 API? Creating windows and all in C? If so, it's the same in assembly language. If not, here's what you have to do to create and use a window:

• Register the window class with RegisterClassEx() *
• Create a window procedure ("proc") for the window to handle the messages it'll be getting
• Create a message loop at the end of your "mainline" procedure (main() in C)
• Create the window with CreateWindowEx() *

* You don't need to do this or create the window by hand if you use a dialog (using a resource editor), in which case the "dialog manager" takes care of all that for you.

(I unrolled the CreateWindowEx() call so you can see what all those parameters are.)

Once you create the window, you're rolling. The window procedure gets the window's messages and processes them. Here, the only one we're bothering with here is WM_CLOSE, which is received when the user gets tired of looking at this stupid window and closes it.

The message loop is the famous "message pump" that constantly gets and dispatches messages to your window procedure (actually, to ALL your window procedures--there can be many of them). Since Windows is an event-driven OS, all the interaction with a window is through the messages it receives (and the messages it and other parts of your code sends).

The window procedure ALWAYS looks like this:


<name of proc here> PROC hWin:HWND, uMsg:DWORD, wParam:DWORD, lParam:DWORD


The names of those parameters (hWin, uMsg, etc.) don't matter at all; you could call them "JoeSchmo" and they'd still work. What's important is their type (well, they're all DWORDs, QWORDs in 64-bit) and their meaning:

• hWin is the window handle (unique to this window)
• uMsg is the message being received (WM_CREATE, WM_CLOSE, etc.)
• wParam and lParam are additional data accompanying the message (depends on the message)

And be sure to forward any messages you don't handle to DefWindowProc(), so Windows can do its default thing with them.

Hopefully none of this is insulting your intelligence because you're already familiar with it.

You could actually assemble and link this li'l program if you wanted. I've attached the .exe so you can see the result (nothing to write home about).

Quote from: NoCforMe on January 18, 2023, 11:28:23 PM
I'm assuming you're familiar with Windows, specifically with the Win32 API? Creating windows and all in C? If so, it's the same in assembly language.
Hopefully none of this is insulting your intelligence because you're already familiar with it.

No far from that, you're not insulting me, Win32 API is not a problem, I just want to get to know the language before I jump into UI programming
or anything that is ahead of basics for now.

Quote from: NoCforMe on January 18, 2023, 11:28:23 PM
You could actually assemble and link this li'l program if you wanted. I've attached the .exe so you can see the result (nothing to write home about).

I couldn't assemble it because didn't install masm SDK, but I've downloaded your executable and what is truly amazing is that the executable is only 4KB.
That's really awesome, it's shows the potential of using assembly instead of HLL.

In any case a long journey is ahead of me to get comfortable with the language, everything is very different from what I'm used to.
Appreciate all of the help, I'll certainly get back to this thread to recall samples.

Quote from: NoCforMe on January 18, 2023, 01:08:31 PM

Quote from: brazer on January 16, 2023, 03:51:07 PM
I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here. And my gawd, it's a lengthy bunch of crap: meticulously sectioned, painstakingly annotated. Still crap.

I mean, it's fine to have strong opinions about good formatting style: we all do. Some are better than others, of course, but in the end it's all pretty subjective. (Well, I have some formatting rules that I think are objectively better, like identifying locals vs. globals via capitalization, but if someone just doesn't like that style then it doesn't matter if it's better or not.) But to try to impose your style on the rest of the world? Buddy, that just ain't gonna work. (And I hate his use of lowercase throughout!)

Sorry but I somehow missed this post of yours, I see formatting can be one big subjective debate but this is the only link I found and honestly didn't read it all,
I only skimmed trough and haven't formed any opinions yet because it's too early for me to make conclusions.

Quote from: NoCforMe on January 18, 2023, 01:08:31 PM
If I might ask, what kind of code will you be writing? I took a quick peek at your GitHub (is that the right term?); are you a gamer? Just curious about what kind of apps you'll be creating.

Whatever you do, since we all know that assembler is not the hot current production tool, nor will it ever be, have fun with it. (That why I use it.)

I wanted to know know game dev, but I have given up long time ago because to make games one person alone is not enough to make good games and I don't really want to waste years to work on just one
game project, most free game engines out there suck and I don't have motivation nor time to write my own, I don't know nor enjoy graphics design, pure coding is much more fun.
I made only one game so far which is a 2D roulette simulation, primarily math and calculation of odds instead of shiny graphics.

I'm not really sure what kind of code will I write in assembly, but major motivation that drives me is to boost my programming skills, I like low level programming, micro optimizations and dependency free code.

Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.
I guess I was affected by such statements so I never took a look at asm myself but I do realize now there are 2 conflicting world views between assembly coders and HLL coders, at least when it comes to pushing
personal opinions upon others.

So in the end I guess I'll be using assembly in combination with HLL to optimize portions of code and to boost skills overall but nothing serious or big.

Quote from: brazer on January 19, 2023, 09:28:24 AMAssembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.

There are occasionally cases where the C/C++ compiler is on par with assembly, but generally we are not happy if we can't beat the beast by at least a factor 2 - see The Lab (http://masm32.com/board/index.php?board=6.0) for some examples :cool:

Attached my Windows GUI template - pure Masm32 SDK code, 93 lines, 7.5kB exe, with a menu, an edit control and a WM_PAINT handler. I think it's about time to install the Masm32 SDK ;-)

brazer,

I will tell you a funny story, back in the late 90s, most academia lambasted assembler programming as unreadable, unwritable and unable to compete with then modern C compilers.

As many asm programmers are fluent in C, the solution to this dogma was done by example. My contribution was a 6k editor called "TheGun" written in 32 bit MASM and their mouths became silent. Microsoft re-released an updated ML.EXE and assembler became main stream again.

There has always been programming language wars and that will probably never change but the brutal performance of pure assembler coding keeps them honest, they may not like it, they may never be able to write it but its there for a reason, Microsoft need assemblers for their OS development.

64 bit MASM (ML64.EXE) is very low level and no joy to learn but with enough support, include files, libraries and documentation, it can deliver kick ass performance when written correctly. You just need to know how to write it.

Quote from: brazer on January 19, 2023, 09:28:24 AM

I've downloaded your executable and what is truly amazing is that the executable is only 4KB.
That's really awesome, it's shows the potential of using assembly instead of HLL.

That's because it doesn't have to drag in the entire C runtime library just to put up a simple window. We get to pick and choose exactly what code gets included in our executables.

Quote
Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.
I guess I was affected by such statements so I never took a look at asm myself but I do realize now there are 2 conflicting world views between assembly coders and HLL coders, at least when it comes to pushing personal opinions upon others.

Good. Just so long as you realize that assembly language is not, and probably will never be, a really viable development tool for commercial applications, mainly because of the portability issue, but for other reasons as well, you can have lots of fun exploring it and coming up with useful ways to apply it. Writing assembler utility routines for a HLL program isn't a bad way to go at all.

Just to be fair for C.

Quote from: TimoVJL on January 19, 2023, 11:49:49 PM
Just to be fair for C.

5,632 bytes, toolbar included - cute :thumbsup:

 :biggrin:

> Just so long as you realize that assembly language is not, and probably will never be, a really viable development tool for commercial applications, mainly because of the portability issue

This would certainly be debated by many who have written assembler code for many years. Go back to QMODEM where the later ASM version ate the earlier C version alive.

Assembler in Windows x86 - 64 is not a hobbyists social club but a tool designed for performance and it has multiple targets, object modules for Microsoft C/C++ compilers, DLLs in both 32 and 64 bit and of course, 32 and 64 bit executable files.

While some confuse the old push/call style with how ASM is or should be written, since the start of Win32, MASM has been capable of using the full API set and any Microsoft compatible library and you can write sections of asm code that are relatively high level. Being able to write hack API and library code gets much of the junk out of the way so that development time can be spent where assembler has no peers, algorithm design and code efficiency.

Timo is right, well written C/C++ can produce high quality binary code and the better C compilers usually have assemblers to go with them for when finer tuning is required.

hutch--,
great, I'm now convinced there is another "true" reason for asm beyond just enjoying it, performance.

Quote from: jj2007 on January 19, 2023, 11:34:37 AM
There are occasionally cases where the C/C++ compiler is on par with assembly, but generally we are not happy if we can't beat the beast by at least a factor 2 - see The Lab (http://masm32.com/board/index.php?board=6.0) for some examples :cool:

Factor of 2 vs compiler sounds cool, I wonder how is it measured, is it by counting CPU cycles, by counting instructions or something else? I suppose there is a tool or library for this?

Quote from: jj2007 on January 19, 2023, 11:34:37 AM
Attached my Windows GUI template - pure Masm32 SDK code, 93 lines, 7.5kB exe, with a menu, an edit control and a WM_PAINT handler. I think it's about time to install the Masm32 SDK ;-)

93 lines and 8KB in unbelievable given the features of the window, that's certainly much less than what I would need to do it in cpp, perhaps without OOP approach may be possible.

Question: I see you're using constructs, a switch case and while loop, is this specific to masm assembler? I suppose it's not possible with non MS assembler?

Sorry if this sounds noobish but if the above is true, I wonder, how is performance affected by using MS specific features compared to pure assembly? is there some drawback?

Quote from: brazer on January 20, 2023, 09:48:05 AMhow is it measured, is it by counting CPU cycles, by counting instructions or something else? I suppose there is a tool or library for this?

Macros. Have a look at The Laboratory, or at \masm32\macros\timers.asm.

QuoteQuestion: I see you're using constructs, a switch case and while loop, is this specific to masm assembler? I suppose it's not possible with non MS assembler?

Sorry if this sounds noobish but if the above is true, I wonder, how is performance affected by using MS specific features compared to pure assembly? is there some drawback?

No drawback at all. These macros generate very fast very small code under the hood, see here (http://masm32.com/board/index.php?topic=1185.0).

Quote from: jj2007 on January 20, 2023, 09:59:22 AM

Quote from: brazer on January 20, 2023, 09:48:05 AMQuestion: I see you're using constructs, a switch case and while loop, is this specific to masm assembler? I suppose it's not possible with non MS assembler?

Sorry if this sounds noobish but if the above is true, I wonder, how is performance affected by using MS specific features compared to pure assembly? is there some drawback?

No drawback at all. These macros generate very fast very small code under the hood, see here (http://masm32.com/board/index.php?topic=1185.0).

Welll, again, macros: I don't see how that could be any faster (or smaller, even) than what I do to in lieu of switch ... case ... case ... without the help of macros at all:


[in a window proc]

MOV EAX, uMsg
CMP EAX, WM_COMMAND
JE do_command
CMP EAX, WM_PAINT
JE do_paint
CMP EAX, WM_CTLCOLORBTN
JE do_btncolor
...

do_command:
[handle commands]

do_paint:
[paint your window]

do_btncolor:

... etc.


Now, I don't know exactly what all those macros do, in terms of the code they generate, but it cannot be any simpler than what I just posted, and I suspect it's more complex, with jumps around blocks of code. So again, use macros if you think it makes your code more readable (doesn't do anything for me in that department), but don't go thinking it's better than just raw assembler coding.

David,

   MOV   EAX, uMsg
   CMP   EAX, WM_COMMAND
   JE   do_command
   CMP   EAX, WM_PAINT
   JE   do_paint
   CMP   EAX, WM_CTLCOLORBTN
   JE   do_btncolor

You are doing a redundant move for the stack message arg. A message is an equate to an immediate value so you can do a direct comparison between uMsg and the message equate.

    cmp uMsg, WM_COMMAND

The technique you are suggesting is an old Turbo Assembler technique.

Have a look in "example02\tstyle" at the two examples of TASM style code.

What the heck are you talking about? I'm saving memory references, Hutch, by putting the message into a register (EAX) and comparing that instead of repeated memory comparisons (uMsg). Isn't that what you speed-obsessed coders always prefer doing?

Compare my way

CPU Disasm
Address   Hex dump          Command                                  Comments
00401381  8B45 0C        MOV EAX,DWORD PTR SS:[ARG.2]
00401384  3D 11010000    CMP EAX,111
00401389  74 0A          JE SHORT ASPIdiag.00401395
0040138B  83F8 10        CMP EAX,10
0040138E  74 13          JE SHORT ASPIdiag.004013A3
00401390  83F8 01        CMP EAX,1
00401393  74 18          JE SHORT ASPIdiag.004013AD


to your way:

CPU Disasm
Address   Hex dump          Command                                  Comments
0040136C  817D 0C 110100 CMP DWORD PTR SS:[ARG.2],111
00401373  74 20          JE SHORT ASPIdiag.00401395
00401375  837D 0C 10     CMP DWORD PTR SS:[ARG.2],10
00401379  74 28          JE SHORT ASPIdiag.004013A3
0040137B  837D 0C 01     CMP DWORD PTR SS:[ARG.2],1
0040137F  74 2C          JE SHORT ASPIdiag.004013AD


Your way has n memory references; mine only has 1. Smaller and (not that it really matters) faster.

If I'm only handling one or two messages then sure, I'll just do


CMP uMsg, WM_COMMAND
JE do_command


Sorry, I can barely make head or tails out of your English. Hard to tell what you're trying to say.

However, one thing you wrote:

Quote
go up write variables,go down write code

I know exactly what you're talking about there. It's probably the biggest drawback to my style of coding (no macros), which means that data definitions go up above under .data, and code lower down under .code. Meaning that you have to constantly switch between sections, unless you can remember all those damned names! So def. an advantage to use macros that let you define strings in the macro, for instance (or use C, which does the same thing). Still, I'll stick with my style for now.

David,

Its the usual distinction,

1. Can you clock the difference ? I doubt that.
2. Do you need to use a register in a sequential compare which is slow at best ?
3. Is it vaguely even speed related code ?

While there is nothing wrong with your code and it will work correctly, I will make you the point that it is an ancient style that yields no advantage.

I in fact have never used a TASM style dispatcher, I wrote those 2 examples over 20 years ago to show bad code design.

My own style is a switch block, clean, fast and easy to read.

Straight out of the help file.

switch variable
  case value1 ; there must be at least one (1) case statement
    ; do something here
  case value2 ; optional extra case statement(s)
    ; do something else
  default ; optional default processing
    ; do any default processing
endsw

The thing that will turn into a nightmare for you is multi-level nesting. A switch block or an if block can be nested at multiple depth levels in a clean and clear manner (indenting helps here).

Quote from: NoCforMe on January 20, 2023, 03:39:52 PMWelll, again, macros: I don't see how that could be any faster (or smaller, even) than what I do to in lieu of switch ... case ... case ... without the help of macros at all:

Code Select Expand


[in a window proc]

MOV EAX, uMsg
CMP EAX, WM_COMMAND
JE do_command
CMP EAX, WM_PAINT
JE do_paint
CMP EAX, WM_CTLCOLORBTN
JE do_btncolor
...

do_command:
[handle commands]

do_paint:
[paint your window]

do_btncolor:

... etc.


Now, I don't know exactly what all those macros do, in terms of the code they generate, but it cannot be any simpler than what I just posted, and I suspect it's more complex

There are a few cases where a switch-style macro produces more efficient code under the hood, but in general they produce exactly the code that a good coder would produce manually.

It's all about readability and maintainability. Your code is fine if the whole source is a few hundred lines long, and you have plenty of spare time. I have several sources well beyond 10,000 lines. I would go mad if I had to use jne stuff all over the place.

There is a reason why all (?) high level languages have introduced switch, select, repeat...until & friends.
There is no reason why an assembler programmer should not use them.

Except that once in his career, as a n00b, he should study what they do under the hood.

The same is true, obviously, for handy things such as
print "Hello World"

I sincerely hope, for your mental sanity, that you don't use StdOut and .data definitions for writing hello world :cool:

Quote from: jj2007 on January 20, 2023, 07:24:08 PM
The same is true, obviously, for handy things such as

Code Select Expand

print "Hello World"

I sincerely hope, for your mental sanity, that you don't use StdOut and .data definitions for writing hello world :cool:

StdOut, that's for console programs, right? Don't write many of those, and when I do I use WriteConsole() for output.

I do put my data to be "printed" (funny how we still use that BASIC verb that doesn't mean what it says) in .data, instead of the sexy way you guys put it as you illustrated. Yes, I know it's "old school" and to be honest, a bit more of a pain in the ass (as I explained to--whoops, looks like that reply got deleted: ???). But you know what? I prefer it that way. I like to have all my data organized in one place, rather than spread out all over my code, which, BTW, often exceeds several thousand lines of code, so we're not talking itsy-bitsy programs here. To me, it's manageable, yes, even without macros and embedded strings and all that stuff.

> I do put my data to be "printed" (funny how we still use that BASIC verb that doesn't mean what it says)

Use "cout" instead, much clearer :thumbsup:


Three options, side by side:

include \masm32\MasmBasic\MasmBasic.inc
.code
txHelloData     db "Hello data", 0
  Init
  int 3
  print offset txHelloData, 13, 10
  print offset txHelloData, 13, 10
  print "Hello World", 13, 10
  print "Hello World", 13, 10
  Print "Hello David", CrLf$
  Print "Hello David", CrLf$
EndOfCode

Under the hood:
Address   Hex dump          Command                                  Comments
004010BC  |.  CC            int3
004010BD  |.  68 24104000   push txHelloData                         ; /Arg1 = ASCII "Hello data"
004010C2  |.  E8 8D000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010C7  |.  68 57804000   push offset ??00EA                       ; /Arg1 = ASCII "
"
004010CC  |.  E8 83000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010D1  |.  68 24104000   push txHelloData                         ; /Arg1 = ASCII "Hello data"
004010D6  |.  E8 79000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010DB  |.  68 5C804000   push offset ??00F1                       ; /Arg1 = ASCII "
"
004010E0  |.  E8 6F000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010E5  |.  68 60804000   push offset ??00F2                       ; /Arg1 = ASCII "Hello World"
004010EA  |.  E8 65000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010EF  |.  68 6C804000   push offset ??00F8                       ; /Arg1 = ASCII "
"
004010F4  |.  E8 5B000000   call StdOut                              ; \SkelMbEmpty.StdOut
004010F9  |.  68 70804000   push offset ??00F9                       ; /Arg1 = ASCII "Hello World"
004010FE  |.  E8 51000000   call StdOut                              ; \SkelMbEmpty.StdOut
00401103  |.  68 7C804000   push offset ??00FF                       ; /Arg1 = ASCII "
"
00401108  |.  E8 47000000   call StdOut                              ; \SkelMbEmpty.StdOut
0040110D  |.  68 80804000   push offset ra_lbl2                      ; ASCII "Hello David"
00401112  |.  6A 01         push 1                                   ; /Arg2 = 1
00401114  |.  6A 02         push 2                                   ; |Arg1 = 2
00401116  |.  E8 DE130000   call MbPrint                             ; \SkelMbEmpty.MbPrint
0040111B  |.  68 80804000   push offset ra_lbl2                      ; ASCII "Hello David"
00401120  |.  6A 01         push 1                                   ; /Arg2 = 1
00401122  |.  6A 02         push 2                                   ; |Arg1 = 2
00401124  |.  E8 D0130000   call MbPrint                             ; \SkelMbEmpty.MbPrint

Option 1 (Masm32 SDK, old style):
- 20 bytes per call
- reuses txHelloData (15 bytes extra once)
- you can't see the string, it's declared far away, so you will have to add a comment to understand your own code

Option 2 (Masm32 SDK, modern style):
- 20 bytes per call
- creates a new "Hello World" and a new CrLf for each call, i.e. 15 bytes extra per call
- you can see the string right in your call

Option 3 (MasmBasic):
- 14 bytes per call (Arg3 -> ra_lbl2, /Arg2 = 1 -> push CrLf, /Arg1 = 2 -> 2 args)
- reuses "Hello David" alias offset ra_lbl2
- you can see the string right in your call

For the real bare metal fans, there is option 4, a dozen lines for each "hello world" (\Masm32\m32lib\stdout.asm):
StdOut proc lpszText:DWORD

    LOCAL hOutPut  :DWORD
    LOCAL bWritten :DWORD
    LOCAL sl       :DWORD

    invoke GetStdHandle,STD_OUTPUT_HANDLE
    mov hOutPut, eax

    invoke StrLen,lpszText
    mov sl, eax

    invoke WriteFile,hOutPut,lpszText,sl,ADDR bWritten,NULL

    mov eax, bWritten
    ret

StdOut endp

(Oops, StrLen is a Masm32 library function, is that allowed in bare metal code?)

Note the attached executable will throw an exception because of the int 3. In OllyDbg, go to Options/Options/Just-in-time/Set OllyDbg to make Olly take over when the crash happens.

Quote from: daydreamer on January 20, 2023, 11:18:26 PM
for example messagebox call with chr$,ustr$ in one long line is my preferred coding style vs in editor scroll up to write in .data section for strings+other variables,scrolll down to write in .code is * many times

I suppose an editor with a "split window" feature won't change your mind? :icon_idea:

 :biggrin:

The basic distinction I support is between "hack code" that gets things on the screen, interacts with the OS, handles file IO and all the rest of the "hacky things, versus => algorithm design ! The latter is where ASM shines, where it has the adjustment level that few others have and where it has the real speed when it matters.

Aspiring to the fastest MessageBox on the planet delivers results that go over with all the fanfare of a gnat breaking wind.

    push MB_OK
    push pTitle
    push pMessage
    push hWnd
    call MessageBoxA

Now this may be fine in 32 bit STDCALL but wait until you try it in 64 bit. A new world order, entirely different stack design, first 4 arg as registers, the old stuff does not work any longer.

Quote from: hutch-- on January 21, 2023, 06:37:48 AMthe old stuff does not work any longer.

However, MsgBox 0, "A text", "A title", MB_OK works fine in both 64- and 32-bit land. That is the power of macros.

Well, JJ, if I ever "migrate" to 64-bit (not bloody likely, but who knows?), I'll be sure to look at macros. Until then, thanks but no thanks.

Quote from: brazer on January 21, 2023, 06:23:33 AM

Quote from: daydreamer on January 20, 2023, 11:18:26 PM
for example messagebox call with chr$,ustr$ in one long line is my preferred coding style vs in editor scroll up to write in .data section for strings+other variables,scrolll down to write in .code is * many times

I suppose an editor with a "split window" feature won't change your mind? :icon_idea:

You, my friend, have hit the nail squarely on the head. Yes, a split-screen editor would be just the ticket.

And if anyone scoffs, that's exactly what I used to have with MultiEdit, a windowed editor for DOS that was just spectacular. Split windows, vertical or horizontal; select vertical blocks of text as well as horizontal; powerful macro language (oops, macros) that made it fully extensible. Lots more stuff (regular expression search and replace, etc.). I miss it. I still have it on my hard drive, but it no longer runs as of Windows 7. (It still ran under XP.) R.I.P.

Quote from: NoCforMe on January 21, 2023, 08:48:07 AMYes, a split-screen editor would be just the ticket.

Feasible, absolutely - just select some text and hit Ctrl F12. Or implement it in your own editor (http://masm32.com/board/index.php?topic=10319.0) - it's fun :thumbsup:

However, separating code and text is still very clumsy, and difficult to read. Who knows why almost nobody uses that in any HLL, The Microsoft Macro Assembler (MASM) included.

(http://www.jj2007.eu/pics/SplitEdit.png)

Hi David,

You may like this design and you don't have to use a 2 step dispatcher. This is in 64 bit but you can do the same in 32 bit MASM. Advantage is each sequential item is a code block using an exit anonymous label. (@@:).

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm64\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL var   :QWORD

    mov var, 16

    cmp var, 10
    jne @F
      conout "10 chosen",lf
  @@:

    cmp var, 12
    jne @F
      conout "12 chosen",lf
  @@:

    cmp var, 14
    jne @F
      conout "14 chosen",lf
  @@:

    cmp var, 16
    jne @F
      conout "16 chosen",lf
  @@:

    cmp var, 18
    jne @F
      conout "18 chosen",lf
  @@:

    waitkey
    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

Hutch,

When will you add a 64-bit version of \Masm32\examples\exampl07\slickhuh\slickhuh.asm to the SDK?

JJ, I just took a look at that example.

Yuck. That's got to be one of the most horrible pieces of code I've ever seen. Unless it's supposed to be a joke. What's so "slick" about it?

[after reading readme.txt]
OK, I get it, I GET IT. I wasn't wrong up there, but it warn't no great revelation neither. Nevermind ...

David,

You got it right, YUK but the amount of deliberately obscure code that used to be around needed a response. In the minds of those who produce crap like that, Slick Huh !

Quote from: NoCforMe on January 21, 2023, 09:11:51 PMWhat's so "slick" about it?

This is almost true bare metal code. Real Men^TM can improve it by poking their ideas directly into memory, like this:

    call lsc
.radix 16
dq 0C700000030A045C7
dd 3A445
dw 0
.radix 10
    mov DWORD PTR [ebp-88], OFFSET wpep

Btw these simplified .code, .data etc directives for n00bs can be easily replaced with true segment definitions:

    includelib \masm32\lib\user32.lib
.code
    ims db "Slick Huh ?", 0


    includelib \masm32\lib\user32.lib
MyCode SEGMENT DWORD PUBLIC 'CODE'
    ims db "Slick Huh ?", 0


A little late from me, but welcome to assembler Brazer.

Quote from: brazer on January 19, 2023, 09:28:24 AM
Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.
I guess I was affected by such statements so I never took a look at asm myself but I do realize now there are 2 conflicting world views between assembly coders and HLL coders, at least when it comes to pushing
personal opinions upon others.

So in the end I guess I'll be using assembly in combination with HLL to optimize portions of code and to boost skills overall but nothing serious or big.

The one major reason for me to use assembler in it's power to do almost anything you could expect a computer could do. If you ever get into such an argument, challenge the other person to write a small program to extract the square root of 123456789.987654321 (or anything similar) with the accuracy of 9,999 decimal digits and display the answer on the screen!

If you should doubt such feasibility but you may be curious, I suggest you go to ray.masmcode.com, then to the "Binary Coded Decimals" section at the bottom of the page. There, download the BCDtut where you will find a folder named WINSQR containing a small program which you can use to perform the above challenge.
(BTW, I had written such a program some 40+ years ago on a TRS-80 having a total memory of 64kb. Such is the power of assembly.)

On a separate subject, if you ever delve into writing a program requiring extensive use of floating point maths, significant improvement in the speed of execution can be obtained with assembly. Compared to the use of HLLs, the gains are generally obtained by a possible significant reduction of memory access; with 8 FPU registers, a lot of intermediate results can be retained directly inside the FPU instead of being transfered back and forth between the FPU and memory. While on the above site, you can also have a peek at the "Complex Numbers" section and download the WMANJUL folder. It contains a program generating the Mandelbrot fractal which makes a VERY intensive use of the FPU.

(My pet peeve against Microsoft is the fact that many very useful programs have been produced in the past and provided with a help file .HLP based on Microsoft's design. The support for the use of such files has been dropped entirely as of WINDOWS10. The help file in the above downloaded folder will thus be entirely useless; however, a pop-up help will appear with the F1 key at any time to indicate which key will perform which operation. Enjoy. Full screen is more enjoyable.)

Quote from: raymond on January 22, 2023, 09:02:46 AMThe support for the use of such files has been dropped entirely as of WINDOWS10

Raymond,

It is sufficient to copy the WinHlp32.exe from an older Windows version to a folder of your choice. It will run just fine on Win10. Make a test with the attachment, and promise to delete it soon, as it is copyrighted ;-)

Even easier, use JimG's post to make it work fine in Win10.

http://masm32.com/board/index.php?topic=5201.0 (http://masm32.com/board/index.php?topic=5201.0)

Quote from: jj2007 on January 22, 2023, 09:09:16 AM
It is sufficient to copy the WinHlp32.exe from an older Windows version to a folder of your choice. It will run just fine on Win10. Make a test with the attachment, and promise to delete it soon, as it is copyrighted ;-)

Believe it or not but I got the following message when I tried to download it:
         winhlp32.zip
Failed - Virus detected
:joking: :joking: :joking: :joking: :eusa_boohoo: :eusa_boohoo: :eusa_boohoo: :eusa_boohoo:
:greenclp: :greenclp: :greenclp: :greenclp: :skrewy: :skrewy: :skrewy: :skrewy:      :icon_idea:

Funny. Which AV are you using?

https://www.virustotal.com/gui/file/33068a8a5f8f61683b7412e9c2b5730beb12ca0d6f2ebda502ecfd56433edba1?nocache=1

QuoteNo security vendors and no sandboxes flagged this file as malicious

AV scanners are getting worse, I checked the details of some false positives and they were rejecting some executable file on the basis of Android phone trojans.

For Ray, try the link in the forum I mentioned, Jim Giordano's package has always worked well here.

<Funny. Which AV are you using?>

I'm using a ThinkPad laptop which was given to me about 10 years ago, initially with Win7 installed. I have upgraded up to Win10 whenever an upgrade was offered. I think the AV is Windows Defender which came with upgrades.

Quote from: hutch-- on January 22, 2023, 11:14:15 AM
AV scanners are getting worse, I checked the details of some false positives and they were rejecting some executable file on the basis of Android phone trojans.

I transfer many files between android tablets <-> PC haven't yet found av found any virus
I had to make my visual studio file folders set as exception in av,to not scan because weird behaviour delete  Obj file created by Ms cl.exe when I choose build vc cpp exe,so linker error not found. Obj file
Anyone else got such weird error?
About raymonds BCD tutorial: those x86 special BCD opcodes aren't available in 64 bit mode
I use much masm32 help files from qeditor help menu, mostly finding macros, sometimes when gonna use seldom used opcode
Better use aoa pdf files version on tablets than HTML

Quote from: NoCforMe on January 21, 2023, 08:48:07 AM
You, my friend, have hit the nail squarely on the head. Yes, a split-screen editor would be just the ticket.

And if anyone scoffs, that's exactly what I used to have with MultiEdit, a windowed editor for DOS that was just spectacular. Split windows, vertical or horizontal; select vertical blocks of text as well as horizontal; powerful macro language (oops, macros) that made it fully extensible. Lots more stuff (regular expression search and replace, etc.). I miss it. I still have it on my hard drive, but it no longer runs as of Windows 7. (It still ran under XP.) R.I.P.

Ah, well yet another personal preference, my personal preference is built a lot around MS practices aka. drop old stuff adopt new stuff ASAP.

I have some 20 Windows ISO images in backup, starting from Windows 7 to Windows 11, all versions and service packs ready to use.
However the only benefit I get from these is to say "I have ® Microsoft Windows that no one else has" because you can't simply download it anywhere, especially not the old ones.

Those old OS's are like currency, how much is one willing to pay for ® like Windows 2000 or XP or even older? huh, that's like owning old timer cars!
I very rarely use them for software testing which is a poor reason why I keep them, I prefer to say that I have MS currency on my drive which one day may be expensive,
and I hope my drive doesn't suddenly die out lol :toothy:

Quote from: raymond on January 22, 2023, 09:02:46 AM
The one major reason for me to use assembler in it's power to do almost anything you could expect a computer could do. If you ever get into such an argument, challenge the other person to write a small program to extract the square root of 123456789.987654321 (or anything similar) with the accuracy of 9,999 decimal digits and display the answer on the screen!

Thanks for the welcome!

That is certainly true, I have collected some 15 sqrt functions in the pas, only one uses inline assembly the rest is C or cpp,
none of these functions outperform standard sqrt or the intrinsic function provided by MS, so I for sure believe you that HLL is horrible for math!

Quote from: raymond on January 22, 2023, 09:02:46 AM
On a separate subject, if you ever delve into writing a program requiring extensive use of floating point maths, significant improvement in the speed of execution can be obtained with assembly. Compared to the use of HLLs, the gains are generally obtained by a possible significant reduction of memory access; with 8 FPU registers, a lot of intermediate results can be retained directly inside the FPU instead of being transfered back and forth between the FPU and memory. While on the above site, you can also have a peek at the "Complex Numbers" section and download the WMANJUL folder. It contains a program generating the Mandelbrot fractal which makes a VERY intensive use of the FPU.

Math is very interesting stuff, I'm able to imagine assembly doing fast math since from what I know all those non asm math libraries under the hood are written in assembly, carefully crafted over the years,
so no wonder nobody defeats intrinsics.

Btw. I hope I don't intrude your privacy by asking this, but you're not by any chance Raymond Chen right?
He's my favorite coder, I've learned a lot of stuff from him.

Quote from: daydreamer on January 22, 2023, 10:10:45 PM
I had to make my visual studio file folders set as exception in av,to not scan because weird behaviour delete  Obj file created by Ms cl.exe when I choose build vc cpp exe,so linker error not found. Obj file
Anyone else got such weird error?

That's well known, especially if you use WD, I have all VS associated processes added to WD exclusion list, this not only stops intruding my debugging but also intelisense and build times get faster.
Of course sources directory should be added too to WD (or any AV).

Ex. adding assembler + your files to AV exlusions.

QuoteBtw. I hope I don't intrude your privacy by asking this, but you're not by any chance Raymond Chen right?
He's my favorite coder, I've learned a lot of stuff from him.

Sorry to disappoint you but I am not the Raymond you were expecting. I'm another Raymond I hope you may be learning something from, probably about the use of the FPU. :azn:

Quote from: raymond on January 23, 2023, 04:10:17 AM

QuoteBtw. I hope I don't intrude your privacy by asking this, but you're not by any chance Raymond Chen right?
He's my favorite coder, I've learned a lot of stuff from him.

Sorry to disappoint you but I am not the Raymond you were expecting. I'm another Raymond I hope you may be learning something from, probably about the use of the FPU. :azn:

I've already taken a look at your side added to my ASM subfolder in bookmarks for future reference
When I get to more advanced chapters I'll know where to look for more info :wink2:

Ray (Raymond Filiatreault) is our resident FPU guru par excellence. You can look at his stuff in [drive:]\masm32\fpulib.

I Appreciate all the responses and help provided so far, I hope I didn't offend anyone, if I did please accept my apology.

My learning goes slow but you guys were helpful to demystify few myths, also introductory material on the main page of this site was very useful.
Expect more from me in the future when I get to face real issues worth asking help for.

Just to lead you astray, there is a tool in the MASM32 SDK called SE.EXE, its a scripting engine that runs pre-built scripts that have their own logic and can produce perfectly formatted code if you design the scripts that way. Its no joy to write the scripts but they are fun and fast to use. Knock up working base code in seconds so you can do what you like without having to shovel through hack API code just to get it up and running.

hutch--,

I don't know why but only one "Western Europe" of the 6 links to download SDK works the rest is 404:
https://masm32.com/download.htm

And the link on that site says error 500:
https://www.codingcrew.de/masm32/download.php

These 4 all work.

US site 2.
Western Europe
Australia 1
Australia 2

Also Bogdan's site in Romania.

There are some updates in the forum for the editor and a few other bits.

It looks like my Brave browser knows better than me what I want to download...

I've tried in MS Edge and it indeed works.

Btw. you said there to be SE.EXE but all that I found is se.dll.

There is a lot to SDK, can I get a shortcut or some hints to use the dll?
I suppose it's used in editor but I don't see any options to generate scripts, only menu items to format indent etc..

EDIT:
I see, it's under the "Script" menu?
That's indeed awesome to be able to insert predefined data and comments.

There are certainly many features which I don't have in VSCode.