[Home]  [Edit this page]  [Recent Changes]  [Special Pages]  [Help] 

---

x86ASMFAQ_AboutFAQ

---

About the x86 Assembly FAQ

The goal of this FAQ is to be a clearing house for ideas and common questions that are relatively independent of operating system and assembler and processor mode. At this point I expect that most x86 assembly topics will end up here. Later it would be nice to separate out mode specific questions into two other FAQs  ?a protected mode FAQ and a  ?a real mode FAQ. As for assemblers, if the question can be answered independent of assembler that is preferable, however feel free to write the code specific to the assembler you use, however give it a header stating which assembler it is as in the example. If you see code in one using one assembler feel free to add another listing using your assembler that accomplishes the same thing.

Guidelines

• Operating specific answers should be avoided if possible and should be clearly labelled otherwise.

• Same for assembler specific answers.

• Use Intel syntax everywhere unless you are posting assembler specific code that uses AT&T syntax.

• Code listings can assume at least an 80386 and should be written as if they were in protected-mode, as it is simpler and more applicable. talk:protected-mode best? Exceptions can be made for assemblers that only target real-mode or for answers specific to real-mode. The latter should note that the code is real-mode code.

• I decided on a link+anchor setup. If your answer starts to run very long it may be preferable to have the anchored site simply refer to a separate page, perhaps with a short abstract at the anchored site. However this suggests that answers should be short and to the point (a page or less is good) (this coming from me ;). talk:separate page for listings?

• Start a section if you feel it is necessary (obviously follow the layout as it is setup), but don't start them needlessly.

• ALWAYS use the [code] tags for code and use good (and preferably consistent) style for the code. ALWAYS check that your code runs correctly before posting it, though it is not necessary or preferable to post a WHOLE program. Try to limit it to just the necessary code, just make sure you test that it actually is the right code. Avoid long lines in code listings (80 character width is the common guideline.)

• Use the simplest code possible to answer the question. Avoid using complex directives (for example, TASM's SEGMENT directives.)

• Insert your question/answer where it is most appropriate, for example, it makes sense for recursion and functions to be in the same section, but not for recursion to come before functions. In effect, later questions should extend previous questions.

• Link prolificly. If you refer to another idea, link to the FAQ entry. If the FAQ entry doesn't exist and you think it should link to it anyways, and add a link+anchor to the main page (and answer the question if you can!)

• In a nutshell, try to maintain the style, layout, consistency and quality of the FAQ.

• Finally, this is Wiki. Feel free to fix typos, bad links, things that could be linked but aren't, and anything that is wrong; and feel free to contribute, feel free to change this page if you think it will help, however I suggest against changing things that would require massive rewrites of the FAQ to synchronize(e.g. majorly changing the style guidelines).

Coding style suggestions

This is my (Darius) personal style for assembly coding, nevertheless I think it is good and clarifying (especially for this). I'd like most code listings to follow this style for the most part, though minor variations that aren't confusing are fine.

In words:

• labels ALWAYS start at the first column
• code is ALWAYS indented (preferably four (4) spaces)
• there is ALWAYS a space after a comma (e.g. mov eax, 5; not mov eax,5)
• it is NOT necessary to line up operands, though you can if you want
• comments are ALWAYS aligned with each other unless they are very long
• in this situation very long comments probably shouldn't be in the listing
• memory references ALWAYS use braces (yes MASM and MASM-mode TASM, I'm looking at you)
• opcodes and pseudo-opcodes (e.g. db or resb) are all lowercase
• directives are ALL CAPS (e.g. OFFSET, DWORD PTR, ORG)
• ALWAYS put the necessary "cast" (e.g. DWORD PTR) for ambiguous code
• For code that isn't ambiguous I typically don't, but that's up to you.
• bitmasks almost certainly should be in hexadecimal or binary
• variable names can use any convention, just try to be consistent
• use vertical whitespace (blank lines) to separate things sensibly
• obviously use meaningful names

Despite the ALWAYSes, it's all a suggestion (though a STRONG suggestion.) Most of this is just making the code easier to read (i.e. if you don't leave a space after the comma it's no big deal really, it's just nicer to do it that way.) Some of it is necessary (e.g. mov BYTE PTR [es:myvar], 1) as you might very well not declare myvar in the listing, however some assemblers require this anyways. Some of it helps clarify things especially for beginners, e.g. ALL CAPS for directives makes it easier to see what's bureaucratic assembler stuff and what's assembly language code. And finally, some is just to avoid Microsoft's crackheadedness (or is it Intel's?), with this I mean the ALWAYS use braces rule. Obviously, if these rules don't quite apply to the assembler you are using, use a reasonable approximation, or whatever is considered good standard style for that assembler.

A template and an example entry

Template table of contents entry (note spaces):
*  ?Question
An example:
* What is x86 Assembly?
Template answer: 
[anchor=QuestionAnchor]
[b]Question[/b]
Answer answer answer answer.
AssemblerName:
[code]
    DIRECTIVE
    opcode operand, operand
label:
[/code]
An example answer:
[anchor=OtherLanguages]
[b]How do I use functions from other languages?[/b]
    Most assemblers have directives to declare certain symbols as external.
Once declared external you'd use the function as you normally would using the
calling conventions of the language (C's will be used as an example and as it
is the most common).  Some assemblers (e.g. TASM) also have directives to
automatically handle this (which WILL NOT be used here).  It is quite likely
that you'll need to mangle the name of the symbol for it to work correctly,
once again those are specific to the language you are trying to link in.  Once
you've assembled the file, simply link the object file containing the external
function with the object file containing your assembly code.
TASM:
[code]
;declare an external procedure printf and mangle it with an underscore (_)
EXTRN _printf: PROC 
                                ;C calling convention
    push 10                     ;push variables from right 
    push OFFSET formatstring    ;to left
    call _printf                ;so this would be printf(formatstring,10);
    add esp, 8                  ;caller cleans up the stack
[/code]

[Edit this page]  [Page history]  [What links here]  [Discuss this topic]  [Printer Friendly]