20 Basic Practices in Assembly Language Programming

[Zen]

Another MASM Assembly Language Programming article from CodeProject:
20 Basic Practices in Assembly Language Programming, CodeProject, by Zuoliu Ding.

...Intended,...I think for novices,...and, me,...

[rrr314159]

Considering he's attempting the impossible - a quick summary of assembler for novices - the article is quite good. He's too casual about using xchg which locks memory and therefore is slow. Maybe that only matters in a multi-core environment? - But of course that's standard these days. More nits could be picked; no such article can satisfy everyone, but it's a good try. If you don't think so, let's see you do better!

[hutch--]

With a quick scan, his reference material looks OK and much of it is just good programming practice but nothing beats the Intel manuals once you can get your head around them. I am always wary of any form of "politically correct" notions of how you write code and particularly with assembler code, architectural freedom is one of its greatest advantages. Others have written optimisation techniques, Agner Fog did very influential work as well as one of the Intel manuals but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

After that, then try it on different processor versions and learn the joys of average performance across a variety of different processors.  :P

XCHG was slow on a single core PIV, it never got any better on multicore hardware. Try and forget old DOS style instructions, they were super heros on a 286, anything committed to processor microcode is there for backwards compatibility reasons.

[Gunther]

20 Basic Practices in Assembly Language Programming, CodeProject, by Zuoliu Ding.

The article is good for novices. But there are other sources, too.

... but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

That's the right approach.

Gunther

[jj2007]

More nits could be picked;

6. Another good reason to avoid PUSH and POP

If you forget to make PUSH and POP in pair, an error could happen, and Hutch will eat you alive

:P

[hutch--]

 

> and Hutch will eat you alive

I can tolerate people doing stupid things as long as they don't try and inflict it on me.  :P

[rrr314159]

... but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

That's the right approach.

Agree 100%, when you want the fastest code rely only on your own clock timings. However - we're talking "novice" here.

A beginner shouldn't worry about speed so much, there's a lot more to learn. For instance, they should be shown how to study coding examples, like those from masm32 libraries. Macros are often neglected - that's one good thing about this tutorial, it goes into them a fair amount. How to find bugs. Modular code design. Common errors to watch out for, as in jj2007's "tips, tricks and traps" - like eax can get blown away by a Windows call. This tutorial mentions ecx's volatility in loop instructions. That sort of thing is more important for beginners.

Generally, learning all those instructions and what to do with them is the hard part, worry about speed later.

[Gunther]

Hi rrr314159,

Agree 100%, when you want the fastest code rely only on your own clock timings. However - we're talking "novice" here.

A beginner shouldn't worry about speed so much, there's a lot more to learn. For instance, they should be shown how to study coding examples, like those from masm32 libraries. Macros are often neglected - that's one good thing about this tutorial, it goes into them a fair amount. How to find bugs. Modular code design. Common errors to watch out for, as in jj2007's "tips, tricks and traps" - like eax can get blown away by a Windows call. This tutorial mentions ecx's volatility in loop instructions. That sort of thing is more important for beginners.

That's right and there are a lot of other precious sources, for example:

• Paul Hsieh's site
• Mark Larson's Assembly Optimization Tips for Beginners, Intermediate and Advanced

Gunther

[hutch--]

 

And one day someone will actually read the Intel ABI (Application Binary Interface) and stop preaching nonsense about how you don't have to bother if you can get something to run on at least one version of Windows.

[rrr314159]

And one day someone will actually read the Intel ABI (Application Binary Interface) and stop preaching nonsense about how you don't have to bother if you can get something to run on at least one version of Windows.

That's probably the same day pigs will fly.

[hutch--]

 

> That's probably the same day pigs will fly.

That has been my experience.  :P

Why write system defined reliable code when you can cobble together garbage that crashes on other Windows versions.

A voice crying in the wilderness etc .....

[Raistlin]

I want to rant.....

I read the post and and got mad at the opening statements - saw the xchg thing and some other crap - and got madder. Then browsed the net and saw more of the same.

Why do they keep on telling people that assembly language should be used sparingly; and inline; and for small projects; and more....(CRAP)

People should know:
-----------------------
- Writing large projects as assembly applications are typically MUCH smaller & MUCH more efficient than the bloatware high-level languages spit out. This has real impacts
   especially in today's world of heterogeneous hardware that need to integrate for functionality.
- The claim is that high-level languages should only be used for high complexity abstracted & object orientated work. (Take that ! - you snobs)
- There is academic peer reviewed proof (see post: current assembly resources...) that handwritten assembly programming outperforms state of the art compilers always.
- Writing tutorials for assembly language should exclude DOS environments initially (my opinion & observation) - as it deters newbies... not sexy enough to grab their attention.
- Telling people it's difficult to learn and is error prone, has long debug times etc. as disadvantages or 'when not to use assembly' is just plain legacy. Visual IDE's anyone?
- My current project as some might know (something in the lines of grid computing - can't say much at present); would not be possible without assembly language, this must
   be true of other types of projects as well. If you can think it - you can do it - But only assembly provides the means.   

[hutch--]

Funny story from long ago, when Iczelion and myself were hammering out the earliest versions of MASM32, we kept hearing how writing in assembler was illegal, immoral, fattening, rotted your sox and gave you zits, could not be written reliably, was impossible to debug and did not work any better. A year or so later all we heard was numb silence as missiles (properly written assembler software) went whizzing past them at one tenth the size. Slightly later Microsoft re-released ML.EXE and it has been one of the "boys toys" in VC/VS ever since.

I don't have any problems with high level languages, in places where you are shoveling chyte, anything will do and if you are not writing speed critical software, often good results can be produced by a high level language but when push comes to shove, if you want it to be powerful, fast and flexible, you write it in assembler. It has never been for the faint of heart, they should stick to server side scripting, JAVA or visual garbage generators.  :P

[jj2007]

I want to rant...

assembler was illegal, immoral, fattening, rotted your sox and gave you zits

I fully support you, of course, also by demonstrating that projects in the +10k lines range can be done (A guide to the RichMasm editor) :P

However, it's not that clear-cut:
Writing projects in VGGs is easy and produces, well, garbage.
Writing pure assembler is fun but produces, well, very small executables

The highest productivity comes, IMHO, with macros and a good library. Example:

Code Select Expand

  Dim My$()
  Let My$(1)=Input$("What's your hobby? ", "assembler programming")
  Let My$(0)="You entered ["+My$(1)+"]"
  Print My$(0)

Same as 44 lines of pure assembler:

Code Select Expand

push 0                                                         ; ÚArg2 = 0
push 5                                                         ; ³Arg1 = 5
call MbArrayDim                                                ; ÀSkelMbEmpty.MbArrayDim
mov dword ptr [MbErrLine], 0B
push 1
push 5
call MbArrayGet
push offset ra_lbl2                                            ; ASCII "assembler programming"
push offset ra_lbl3                                            ; ASCII "What's your hobby? "
pushad
fxsave [MbXs]
mov eax, 4E4
push eax
push eax
call SetConsoleCP                                              ; Jump to kernel32.SetConsoleCP
call SetConsoleOutputCP                                        ; Jump to kernel32.SetConsoleOutputCP
fxrstor [MbXs]
popad
call MbInputStrP                                               ; ÀSkelMbEmpty.MbInputStrP
mov dword ptr [MbErrLine], 0B
push 7F
push 80000001
call MbPrint
mov dword ptr [MbErrLine], 0C
push 0
push 5
call MbArrayGet
mov dword ptr [MbErrLine], 0C
push 1
push 5
call MbArrayGet
mov dword ptr [MbErrLine], 0C
push offset MbLs1                                              ; ASCII "You entered ["
push 7F
push offset MbLs2
push 80000003
call MbPrint
mov dword ptr [MbErrLine], 0D
push 0
push 5
call MbArrayGet
push 7F
push 1
call MbPrint

Now, one interesting observation is that it would look only marginally more orderly in C/C++ 8)

Like Hutch with PowerBasic, I grew up with GfaBasic, and have written fairly big projects in that language (a mix of Basic and Pascal, I've been told). Not all Basic dialects are decent programming languages, many are crappy, and standardisation is lacking.

But some are damn good, PowerBasic for example. GfaBasic was top in the 16-bit era, but they failed to port it, that's why I had to do that ;-)

In the process of doing so in MASM, I also was more or less obliged to touch C - header files etc. Some here in the forum (mainly Erol) pushed me to look at Pelles C, which is a decent programming environment. But overall, for somebody used to simple Basic, C/C++ is torture and a can of worms. It is more difficult than assembler, and the result is Bloat without the Power. Try a C equivalent to the code posted above...

Plus, launching that behemoth of Visual Studio gives me the creeps - in the time that it takes to start it, to create a new project and to "configure" it, I would have already coded the entire source in MasmBasic, in a single file instead of a dozen "modules" spread all over the place.

MasmBasic is my personal thing, but for those who prefer another syntax: Check out the \Masm32\help\ folder, in particular hlhelp.chm and masmlib.chm - as Hutch wrote above, the Masm32 library pushed assembly back on the scene of serious programming.

Of course, pure assembler is good for playing with instructions and learning to move values in registers and memory locations etc - the typical stuff they will teach in a university course on assembler. But for productive work, you must accept the use of macros. And just in case that you are one of those who believe that macros produce less efficient code: Post an example. One is enough 8)

[HSE]

If you can think it - you can do it ... only assembly provides the means.

:t