Ассемблер хэл: Засвар хоорондын ялгаа

Content deleted Content added
б Bot: Migrating 47 interwiki links, now provided by Wikidata on d:q165436 (translate me)
No edit summary
Мөр 1:
{{Орчуул}}
 
[[File:Motorola 6800 Assembly Language.png|thumb|Motorola MC6800-ийн Ассемблер хэл]]
Ассемблер хэл нь [[компьютер]], [[Микроконтроллер|микроконтроллер]], болон бусад програмчлагддаг төхөөрөмжүүдийг програмчилдаг, кодны мөр бүр нь нэг [[машин код]]той харгалздаг [[доод түвшний програмчлалын хэл]] юм. [[Компьютерын архитектур]] бүрд өөр өөр ассемблер хэл байдаг.
Line 63 ⟶ 61:
====Өгөгдлийн хэсэг====
Хувьсагч болон элементүүдэд өгөгдөл олгох командууд юм. Өгөгдлийн хэмжээ, төрөл, байрлал зэргийг заадаг. Мөн өөр програмд ашиглаж болдог, эсвэл зөвхөн програм дотроо ашигладаг эсэхийг зааж өгдөг.
 
====Assembly directives====
Assembly directives, also called pseudo opcodes, pseudo-operations or pseudo-ops, are instructions that are executed by an assembler at assembly time, not by a CPU at run time. They can make the assembly of the program dependent on parameters input by a programmer, so that one program can be assembled different ways, perhaps for different applications. They also can be used to manipulate presentation of a program to make it easier to read and maintain.
 
(For example, directives would be used to reserve storage areas and optionally their initial contents.) The names of directives often start with a dot to distinguish them from machine instructions.
 
Symbolic assemblers let programmers associate arbitrary names (''[[label (programming language)|label]]s'' or ''symbols'') with memory locations. Usually, every constant and variable is given a name so instructions can reference those locations by name, thus promoting [[self-documenting code]]. In executable code, the name of each subroutine is associated with its entry point, so any calls to a subroutine can use its name. Inside subroutines, [[GOTO]] destinations are given labels. Some assemblers support ''local symbols'' which are lexically distinct from normal symbols (e.g., the use of "10$" as a GOTO destination).
 
Some assemblers, such as NASM provide flexible symbol management, letting programmers manage different [[namespace (computer science)|namespaces]], automatically calculate offsets within [[data structure]]s, and assign labels that refer to literal values or the result of simple computations performed by the assembler. Labels can also be used to initialize constants and variables with relocatable addresses.
 
Assembly languages, like most other computer languages, allow comments to be added to assembly [[source code]] that are ignored by the assembler. Good use of comments is even more important with assembly code than with higher-level languages, as the meaning and purpose of a sequence of instructions is harder to decipher from the code itself.
 
Wise use of these facilities can greatly simplify the problems of coding and maintaining low-level code. ''Raw'' assembly source code as generated by compilers or disassemblers—code without any comments, meaningful symbols, or data definitions—is quite difficult to read when changes must be made.
 
===Macros===
Many assemblers support ''predefined macros'', and others support ''programmer-defined'' (and repeatedly re-definable) macros involving sequences of text lines in which variables and constants are embedded. This sequence of text lines may include opcodes or directives. Once a macro has been defined its name may be used in place of a mnemonic. When the assembler processes such a statement, it replaces the statement with the text lines associated with that macro, then processes them as if they existed in the source code file (including, in some assemblers, expansion of any macros existing in the replacement text).
 
Note that this definition of "macro" is slightly different from the use of the term in other contexts, like the [[C programming language]]. C macro's created through the #define directive typically are just one line, or a few lines at most. Assembler macro instructions can be lengthy "programs" by themselves, executed by interpretation by the assembler during assembly.
 
Since macros can have 'short' names but expand to several or indeed many lines of code, they can be used to make assembly language programs appear to be far shorter, requiring fewer lines of source code, as with higher level languages. They can also be used to add higher levels of structure to assembly programs, optionally introduce embedded debugging code via parameters and other similar features.
 
Macro assemblers often allow macros to take [[parameter (computer science)|parameter]]s. Some assemblers include quite sophisticated macro languages, incorporating such high-level language elements as optional parameters, symbolic variables, conditionals, string manipulation, and arithmetic operations, all usable during the execution of a given macro, and allowing macros to save context or exchange information. Thus a macro might generate a large number of assembly language instructions or data definitions, based on the macro arguments. This could be used to generate record-style data structures or "unrolled" loops, for example, or could generate entire algorithms based on complex parameters. An organization using assembly language that has been heavily extended using such a macro suite can be considered to be working in a higher-level language, since such programmers are not working with a computer's lowest-level conceptual elements.
 
Macros were used to customize large scale software systems for specific customers in the mainframe era and were also used by customer personnel to satisfy their employers' needs by making specific versions of manufacturer operating systems. This was done, for example, by systems programmers working with [[IBM]]'s Conversational Monitor System / Virtual Machine ([[VM/CMS]]) and with IBM's "real time transaction processing" add-ons, Customer Information Control System [[CICS]], and [[Airline Control Program|ACP]]/[[Transaction Processing Facility|TPF]], the airline/financial system that began in the 1970s and still runs many large [[computer reservations system]]s (CRS) and credit card systems today.
 
It was also possible to use solely the macro processing abilities of an assembler to generate code written in completely different languages, for example, to generate a version of a program in [[COBOL]] using a pure macro assembler program containing lines of COBOL code inside assembly time operators instructing the assembler to generate arbitrary code.
 
This was because, as was realized in the 1960s, the concept of "macro processing" is independent of the concept of "assembly", the former being in modern terms more word processing, text processing, than generating object code. The concept of macro processing appeared, and appears, in the C programming language, which supports "preprocessor instructions" to set variables, and make conditional tests on their values. Note that unlike certain previous macro processors inside assemblers, the C preprocessor was not [[Turing completeness|Turing-complete]] because it lacked the ability to either loop or "go to", the latter allowing programs to loop.
 
Despite the power of macro processing, it fell into disuse in many high level languages (major exceptions being C/C++ and [[PL/I]]) while remaining a perennial for assemblers.
 
Macro parameter substitution is strictly by name: at macro processing time, the value of a parameter is textually substituted for its name. The most famous class of bugs resulting was the use of a parameter that itself was an expression and not a simple name when the macro writer expected a name. In the macro:
<tt>
foo: macro a
load a*b
</tt>
the intention was that the caller would provide the name of a variable, and the "global" variable or constant b would be used to multiply "a". If foo is called with the parameter <tt>a-c</tt>, the macro expansion of <tt>load a-c*b</tt> occurs. To avoid any possible ambiguity, users of macro processors can parenthesize formal parameters inside macro definitions, or callers can parenthesize the input parameters.<ref>{{Cite web
|url=http://msdn.microsoft.com/en-us/library/503x3e3s%28v=VS.90%29.aspx
|title=Macros (C/C++), MSDN Library for Visual Studio 2008
|publisher=Microsoft Corp.
|accessdate=2010-06-22
}}</ref>
 
===Support for structured programming===
Some assemblers have incorporated [[structured programming]] elements to encode execution flow. The earliest example of this approach was in the [[Concept-14 macro set]], originally proposed by Dr. H.D. Mills (March, 1970), and implemented by Marvin Kessler at IBM's Federal Systems Division, which extended the S/360 macro assembler with IF/ELSE/ENDIF and similar control flow blocks.<ref>{{Cite web
|url=http://skycoast.us/pscott/software/mvs/concept14.html
|title=Concept 14 Macros
|publisher=MVS Software
|accessdate=May 25, 2009
}}</ref> This was a way to reduce or eliminate the use of [[GOTO]] operations in assembly code, one of the main factors causing [[spaghetti code]] in assembly language. This approach was widely accepted in the early '80s (the latter days of large-scale assembly language use).
 
A curious design was [[A-natural]], a "stream-oriented" assembler for 8080/[[Z80]] processors{{Citation needed|date=January 2009}} from [[Whitesmiths|Whitesmiths Ltd.]] (developers of the [[Unix]]-like [[Idris (operating system)|Idris]] operating system, and what was reported to be the first commercial [[C (programming language)|C]] [[compiler]]). The language was classified as an assembler, because it worked with raw machine elements such as [[opcodes]], [[processor register|registers]], and memory references; but it incorporated an expression syntax to indicate execution order. Parentheses and other special symbols, along with block-oriented structured programming constructs, controlled the sequence of the generated instructions. A-natural was built as the object language of a C compiler, rather than for hand-coding, but its logical syntax won some fans.
 
There has been little apparent demand for more sophisticated assemblers since the decline of large-scale assembly language development.<ref name="assembly-language?cat=technology">{{Cite web|url=http://www.answers.com/topic/assembly-language?cat=technology|title=assembly language: Definition and Much More from Answers.com|accessdate=2008-06-19|author=Answers.com}}</ref> In spite of that, they are still being developed and applied in cases where resource constraints or peculiarities in the target system's architecture prevent the effective use of higher-level languages.<ref>[http://neshla.sourceforge.net/ NESHLA: The High Level, Open Source, 6502 Assembler for the Nintendo Entertainment System]</ref>
 
==Use of assembly language==
 
===Historical perspective===
Assembly languages date to the introduction of the [[stored-program computer]]. The [[Electronic Delay Storage Automatic Calculator|EDSAC]] computer (1949) had an assembler called ''initial orders'' featuring one-letter mnemonics.<ref>{{cite book | last1 = Salomon | title = Assemblers and Loaders | url = http://www.davidsalomon.name/assem.advertis/asl.pdf | accessdate = 2012-01-17 | page = 7 }}</ref> [[Nathaniel Rochester (computer scientist)|Nathaniel Rochester]] wrote an assembler for an [[IBM 701]] (1954). SOAP (Symbolic Optimal Assembly Program) (1955) was an assembly language for the [[IBM 650]] computer written by Stan Poley.<ref>{{cite web | url = http://www.columbia.edu/cu/computinghistory/650.html | title = The IBM 650 Magnetic Drum Calculator | accessdate = 2012-01-17}}</ref>
 
Assembly languages eliminated much of the error-prone and time-consuming [[first-generation language|first-generation]] programming needed with the earliest computers, freeing programmers from tedium such as remembering numeric codes and calculating addresses. They were once widely used for all sorts of programming. However, by the 1980s (1990s on [[microcomputer]]s), their use had largely been supplanted by [[high-level language]]s{{Citation needed|date=November 2009}}, in the search for improved [[programming productivity]]. Today assembly language is still used for direct hardware manipulation, access to specialized processor instructions, or to address critical performance issues. Typical uses are [[device driver]]s, low-level [[embedded system]]s, and [[real-time computing|real-time]] systems.
 
Historically, a large number of programs have been written entirely in assembly language. Operating systems were entirely written in assembly language until the introduction of the [[Burroughs MCP]] (1961), which was written in [[Executive Systems Problem Oriented Language|ESPOL]], an Algol dialect. Many commercial applications were written in assembly language as well, including a large amount of the [[IBM mainframe]] software written by large corporations. [[COBOL]], [[FORTRAN]] and some [[PL/I]] eventually displaced much of this work, although a number of large organizations retained assembly-language application infrastructures well into the '90s.
 
Most early microcomputers relied on hand-coded assembly language, including most operating systems and large applications. This was because these systems had severe resource constraints, imposed idiosyncratic memory and display architectures, and provided limited, buggy system services. Perhaps more important was the lack of first-class high-level language compilers suitable for microcomputer use. A psychological factor may have also played a role: the first generation of microcomputer programmers retained a hobbyist, "wires and pliers" attitude.
 
In a more commercial context, the biggest reasons for using assembly language were minimal bloat (size), minimal overhead, greater speed, and reliability.
 
Typical examples of large assembly language programs from this time are IBM PC [[DOS]] operating systems and early applications such as the [[spreadsheet]] program [[Lotus 1-2-3]]. Even into the 1990s, most console video games were written in assembly, including most games for the [[Sega Mega Drive|Mega Drive/Genesis]] and the [[Super Nintendo Entertainment System]] {{Citation needed|date=February 2007}}. According to some industry insiders, the assembly language was the best computer language to use to get the best performance out of the [[Sega Saturn]], a console that was notoriously challenging to develop and program games for.<ref>[http://www.eidolons-inn.net/tiki-index.php?page=SegaBase+Saturn Eidolon's Inn : SegaBase Saturn<!-- Bot generated title -->]</ref> The popular arcade game [[NBA Jam]] (1993) is another example. Assembly language has long been the primary development language for many popular home computers of the 1980s and 1990s (such as the [[Sinclair ZX Spectrum]], [[Commodore 64]], [[Commodore Amiga]], and [[Atari ST]]). This was in large part because BASIC dialects on these systems offered insufficient execution speed, as well as insufficient facilities to take full advantage of the available hardware on these systems. Some systems, most notably the Amiga, even have IDEs with highly advanced debugging and macro facilities, such as the freeware [http://www.theflamearrows.info/homepage.html ASM-One assembler], comparable to that of [[Microsoft Visual Studio]] facilities (ASM-One predates Microsoft Visual Studio).
 
''The Assembler for the [[VIC-20]]'' was written by Don French and published by ''French Silk''. At 1,639 bytes in length, its author believes it is the smallest symbolic assembler ever written. The assembler supported the usual symbolic addressing and the definition of [[character string]]s or hex strings. It also allowed address expressions which could be combined with [[addition]], [[subtraction]], [[multiplication]], [[division (mathematics)|division]], [[logical AND]], [[logical OR]], and [[exponentiation]] operators.<ref>{{Cite web|url=http://www.radiks.net/~jimbo/art/int7.htm|title=Speaking with Don French : The Man Behind the French Silk Assembler Tools|date=2004-05-21|accessdate=2008-07-25|author=Jim Lawless|publisher=| archiveurl= http://web.archive.org/web/20080821105848/http://www.radiks.net/~jimbo/art/int7.htm| archivedate= 21 August 2008 <!--DASHBot-->| deadurl= no}}</ref>
 
===Current usage===
There have always been debates over the usefulness and performance of assembly language relative to high-level languages. Assembly language has specific niche uses where it is important; see below. But in general, modern [[optimizing compiler]]s are claimed<ref>{{cite web|last=Rusling|first=David A.|title=The Linux Kernel|url=http://tldp.org/LDP/tlk/basics/sw.html|accessdate=Mar 11, 2012}}</ref> to render high-level languages into code that can run as fast as hand-written assembly, despite the counter-examples that can be found.<ref name="goto">{{Cite web|url=http://www.nytimes.com/2005/11/28/technology/28super.html?_r=1 |title=Writing the Fastest Code, by Hand, for Fun: A Human Computer Keeps Speeding Up Chips |publisher=New York Times, John Markoff |date=2005-11-28 |accessdate=2010-03-04}}</ref><ref name="bit-fild">{{Cite web|url=http://hardwarebug.org/2010/01/30/bit-field-badness/ |title=Bit-field-badness |publisher=hardwarebug.org |date=2010-01-30 |accessdate=2010-03-04| archiveurl= http://web.archive.org/web/20100205120952/http://hardwarebug.org/2010/01/30/bit-field-badness/| archivedate= 5 February 2010 <!--DASHBot-->| deadurl= no}}</ref><ref name="gcc-mess">{{Cite web|url=http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/ |title=GCC makes a mess |publisher=hardwarebug.org |date=2009-05-13 |accessdate=2010-03-04| archiveurl= http://web.archive.org/web/20100316212040/http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/| archivedate= 16 March 2010 <!--DASHBot-->| deadurl= no}}</ref> The complexity of modern processors and memory sub-systems makes effective optimization increasingly difficult for compilers, as well as assembly programmers.<ref name="GreatDebate1">{{Cite web|url=http://webster.cs.ucr.edu/Page_TechDocs/GreatDebate/debate1.html|title=The Great Debate|date=|accessdate=2008-07-03|author=Randall Hyde| archiveurl= http://web.archive.org/web/20080616110102/http://webster.cs.ucr.edu/Page_TechDocs/GreatDebate/debate1.html| archivedate= 16 June 2008 <!--DASHBot-->| deadurl= no}}</ref><ref name="compiler-fails1">{{Cite web|url=http://hardwarebug.org/2008/11/28/codesourcery-fails-again/ |title=Code sourcery fails again|publisher=hardwarebug.org |date=2010-01-30 |accessdate=2010-03-04| archiveurl= http://web.archive.org/web/20100402221204/http://hardwarebug.org/2008/11/28/codesourcery-fails-again/| archivedate= 2 April 2010 <!--DASHBot-->| deadurl= no}}</ref> Moreover, and to the dismay of efficiency lovers, increasing processor performance has meant that most CPUs sit idle most of the time,{{Citation needed|reason=Mainframes normally run with a high CPU loading factor.|date=January 2011}} with delays caused by predictable bottlenecks such as [[I/O]] operations and [[paging]]. This has made raw code execution speed a non-issue for many programmers.
 
There are some situations in which developers might choose to use assembly language:
* A stand-alone executable of compact size is required that must execute without recourse to the [[Run-time system|run-time]] components or [[library (computer science)|libraries]] associated with a high-level language; this is perhaps the most common situation. For example, firmware for telephones, automobile fuel and ignition systems, air-conditioning control systems, security systems, and sensors.
* Code that must interact directly with the hardware, for example in [[device driver]]s and [[interrupt handler]]s.
* Programs that need to use processor-specific instructions not implemented in a compiler. A common example is the [[circular shift|bitwise rotation]] instruction at the core of many encryption algorithms.
* Programs that create vectorized functions for programs in higher-level languages such as C. In the higher-level language this is sometimes aided by compiler [[intrinsic function]]s which map directly to SIMD mnemonics, but nevertheless result in a one-to-one assembly conversion specific for the given vector processor.
* Programs requiring extreme optimization, for example an inner [[Control_flow#Loops|loop]] in a processor-intensive algorithm. [[Game programmer]]s take advantage of the abilities of hardware features in systems, enabling games to run faster. Also large scientific simulations require highly optimized algorithms, e.g. [[linear algebra]] with [[Basic Linear Algebra Subprograms|BLAS]]<ref name="goto"/><ref name="bench">{{cite web|url=http://eigen.tuxfamily.org/index.php?title=Benchmark-August2008 |title=BLAS Benchmark-August2008 |publisher=eigen.tuxfamily.org |date=2008-08-01 |accessdate=2010-03-04}}</ref> or [[DCT (math)|discrete cosine transformation]] (e.g. [[SIMD]] assembly version from [[x264]]<ref>{{cite web|url=http://git.videolan.org/?p=x264.git;a=tree;f=common/x86;hb=HEAD |title=x264.git/common/x86/dct-32.asm |publisher=git.videolan.org |date=2010-09-29 |accessdate=2010-09-29}}</ref>)
* Situations where no high-level language exists, on a new or specialized processor, for example.
* Programs need precise timing such as
** [[real-time computing|real-time]] programs such as simulations, flight navigation systems, and medical equipment. For example, in a [[fly-by-wire]] system, telemetry must be interpreted and acted upon within strict time constraints. Such systems must eliminate sources of unpredictable delays, which may be created by (some) interpreted languages, automatic [[garbage collection (computer science)|garbage collection]], paging operations, or [[preemptive multitasking]]. However, some higher-level languages incorporate run-time components and operating system interfaces that can introduce such delays. Choosing assembly or lower-level languages for such systems gives programmers greater visibility and control over processing details.
** cryptographic algorithms that must always take strictly the same time to execute, preventing [[timing attack]]s.
* Situations where complete control over the environment is required, in extremely high security situations where [[Trusting trust#Reflections on Trusting Trust|nothing can be taken for granted]].
* [[Computer virus]]es, [[bootloader]]s, certain [[device driver]]s, or other items very close to the hardware or low-level operating system.
* [[Instruction set simulator]]s for monitoring, tracing and [[debugging]] where additional overhead is kept to a minimum
* [[Reverse-engineering]] and modifying program files such as
**existing [[binary file|binaries]] that may or may not have originally been written in a high-level language, for example when trying to recreate programs for which source code is not available or has been lost, or cracking copy protection of proprietary software.
** [[Video game]]s (also termed [[ROM hacking]]), which is possible via several methods. The most widely employed is altering program code at the assembly language level.
* [[Self modifying code]], to which assembly language lends itself well.
* [[calculator gaming|Games]] and other software for [[graphing calculator]]s.<ref>{{Cite web|url=http://tifreakware.net/tutorials/89/a/calc/fargoii.htm|title=68K Programming in Fargo II|date=|accessdate=2008-07-03|author=| archiveurl= http://web.archive.org/web/20080702181616/http://tifreakware.net/tutorials/89/a/calc/fargoii.htm| archivedate= 2 July 2008 <!--DASHBot-->| deadurl= no}}</ref>
 
Assembly language is still taught in most [[computer science]] and [[electronic engineering]] programs. Although few programmers today regularly work with assembly language as a tool, the underlying concepts remain very important. Such fundamental topics as [[binary arithmetic]], [[memory allocation]], [[stack (data structure)|stack processing]], [[character set]] encoding, [[interrupt]] processing, and [[compiler]] design would be hard to study in detail without a grasp of how a computer operates at the hardware level. Since a computer's behavior is fundamentally defined by its instruction set, the logical way to learn such concepts is to study an assembly language. Most modern computers have similar instruction sets. Therefore, studying a single assembly language is sufficient to learn: I) the basic concepts; II) to recognize situations where the use of assembly language might be appropriate; and III) to see how efficient executable code can be created from high-level languages.
<ref>{{Cite web|url=http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/fwd.html|title=Foreword ("Why would anyone learn this stuff?"), ''op. cit.''|date=1996-09-30|accessdate=2010-03-05|author=Hyde, Randall| archiveurl= http://web.archive.org/web/20100325155048/http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/fwd.html| archivedate= 25 March 2010 <!--DASHBot-->| deadurl= no}}</ref> This is analogous to children needing to learn the basic arithmetic operations (e.g., long division), although [[calculator]]s are widely used for all except the most trivial calculations.
 
===Typical applications===
 
*Assembly language is typically used in a system's [[Booting|boot]] code, ([[BIOS]] on IBM-compatible [[Personal Computer|PC]] systems and [[CP/M]]), the low-level code that initializes and tests the system hardware prior to booting the OS, and is often stored in [[Read-only memory|ROM]].
 
*Some compilers translate high-level languages into assembly first before fully compiling, allowing the assembly code to be viewed for [[debug]]ging and optimization purposes.
 
*Relatively low-level languages, such as [[C (programming language)|C]], allow the programmer to embed assembly language directly in the source code. Programs using such facilities, such as the [[Linux kernel]], can then construct abstractions using different assembly language on each hardware platform. The system's [[software portability|portable]] code can then use these processor-specific components through a uniform interface.
 
*Assembly language is valuable in [[reverse engineering]]. Many programs are distributed only in machine code form which is straightforward to translate into assembly language, but more difficult to translate into a higher-level language. Tools such as the [[Interactive Disassembler]] make extensive use of disassembly for such a purpose.
 
*Assemblers can be used to generate blocks of data, with no high-level language overhead, from formatted and commented source code, to be used by other code.{{Citation needed|date=March 2012}}
 
==Related terminology==<!-- This section is linked from [[Assembly language]] -->
* '''Assembly language''' or '''assembler language''' is commonly called '''assembly''', '''assembler''', '''ASM''', or '''symbolic machine code'''. A generation of IBM mainframe programmers called it '''ALC''' for ''Assembly Language Code'' or '''BAL'''<ref>Techically BAL was only the assembler for '''BPS'''; the others were macro assemblers.</ref> for '''Basic Assembly Language'''. Calling the language '''assembler''' might be considered potentially confusing and ambiguous, since this is also the name of the utility program that translates assembly language statements into machine code. However, this usage has been common among professionals and in the literature for decades.<ref>Stroustrup, Bjarne, ''The C++ Programming Language'', Addison-Wesley, 1986, ISBN 0-201-12078-X: ''"C++ was primarily designed so that the author and his friends would not have to program in assembler, C, or various modern high-level languages.'' [use of the term ''assembler'' to mean ''assembly language'']"</ref> Similarly, some early computers called their ''assembler'' their '''assembly program'''.<ref>Saxon, James, and Plette, William, ''Programming the IBM 1401'', Prentice-Hall, 1962, LoC 62-20615. [use of the term ''assembly program'']</ref>)
* The computational step where an assembler is run, including all macro processing, is termed '''assembly time'''. The assembler is said to be "assembling" the [[source code]].
* The use of the word '''assembly''' dates from the early years of computers (''cf.'' [[Short Code (Computer language)|short code]], [[speedcoding|speedcode]]).
* {{anchor|Cross assembler}}A '''cross assembler''' (see also [[cross compiler]]) is an assembler that is run on a computer or [[operating system]] of a different type from the system on which the resulting code is to run. Cross-assembling may be necessary if the target system cannot run an assembler itself, as is typically the case for small embedded systems. The computer on which the cross assembler is run must have some means of transporting the resulting [[machine code]] to the target system. Common methods involve transmitting an exact byte-by-byte copy of the machine code or an [[ASCII]] representation of the machine code in a portable format (such as [[SREC (file format)|Motorola]] or [[Intel HEX|Intel]] [[hexadecimal]]) through a compatible [[Interface (computing)|interface]] to the target system for execution.
* An '''assembler directive''' or ''pseudo-opcode'' is a command given to an assembler "directing it to perform operations other than assembling instructions."<ref name="Salomon"/> Directives affect how the assembler operates and "may affect the object code, the symbol table, the listing file, and the values of internal assembler parameters." Sometimes the term ''pseudo-opcode'' is reserved for directives that generate object code, such as those that generate data.<ref>{{cite web|last=Microsoft Corporation|title=MASM: Directives & Pseudo-Opcodes|url=http://flint.cs.yale.edu/cs422/doc/art-of-asm/pdf/CH08.PDF|accessdate=March 19, 2011}}</ref>
* A '''meta-assembler''' is "a program that accepts the syntactic and semantic description of an assembly language, and generates an assembler for that language." <ref>[http://www.encyclopedia.com/doc/1O11-metaassembler.html (John Daintith, ed.) A Dictionary of Computing: "meta-assembler"]</ref>
 
==Ассемблеруудын жагсаалт==
* [[Ассемблерууд]]
 
==Further details==
For any given personal computer, mainframe, embedded system, and game console, both past and present, at least one – possibly dozens – of assemblers have been written. For some examples, see the [[list of assemblers]].
 
On [[Unix]] systems, the assembler is traditionally called [[as (Unix)|as]], although it is not a single body of code, being typically written anew for each port. A number of Unix variants use [[GNU Assembler|GAS]].
 
Within processor groups, each assembler has its own dialect. Sometimes, some assemblers can read another assembler's dialect, for example, [[TASM]] can read old [[MASM]] code, but not the reverse. [[FASM]] and [[Netwide Assembler|NASM]] have similar syntax, but each support different macros that could make them difficult to translate to each other. The basics are all the same, but the advanced features will differ.<ref name="Hyde">{{Cite web|url = http://webster.cs.ucr.edu/AsmTools/WhichAsm.html|title = Which Assembler is the Best? |accessdate = 2007-10-19|author = Randall Hyde| archiveurl= http://web.archive.org/web/20071018014019/http://webster.cs.ucr.edu/AsmTools/WhichAsm.html| archivedate= 18 October 2007 <!--DASHBot-->| deadurl= no}}</ref>
 
Also, assembly can sometimes be portable across different operating systems on the same type of [[CPU]]. [[Calling convention]]s between operating systems often differ slightly or not at all, and with care it is possible to gain some portability in assembly language, usually by linking with a [[C (programming language)|C]] library that does not change between operating systems.{{Citation needed|date=March 2011}} An [[instruction set simulator]] can process the [[object code]]/ [[binary file|binary]] of ''any'' assembler to achieve portability even across [[platform (computing)|platform]]s with an overhead no greater than a typical bytecode interpreter.{{Citation needed|date=March 2011}} This is similar to use of microcode to achieve compatibility across a processor family.
 
Some higher level computer languages, such as [[C (programming language)|C]] and [[Borland Pascal]], support [[inline assembler|inline assembly]] where sections of assembly code, in practice usually brief, can be embedded into the high level language code. The [[Forth (programming language)|Forth]] language commonly contains an assembler used in CODE words.
 
An [[emulator]] can be used to debug assembly-language programs.
 
==Example listing of assembly language source code==
 
<!-- Copyright Notice: I wrote this program and release it to the public domain, OldCodger2 -->
 
<code>
Example: x86, 32 bit, using NASM.
Note: this is a subroutine not a complete program.
178 ;ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
179 ;
180 ; counts a zero terminated ASCII string to determine it's size
181 ; in: eax = start address of the zero terminated string
182 ; out: ecx = count = the length of the string
183
184 zstr_count: ; entry point
185
186 00000030 B9FFFFFFFF mov ecx, -1 ; init the loop counter, pre-decrement to compensate for the increment
187
188 .loop:
189 00000035 41 inc ecx ; add 1 to the loop counter
190
191 00000036 803C0800 cmp BYTE [eax + ecx], 0 ; compare the value at the string's [starting memory address Plus the loop offset], to zero
192 0000003A 75F9 jne .loop ; if the memory value is Not Equal to Zero then jump to the label called '.loop'
; otherwise continue to the next line of code.
193
194 .done:
195 ; we don't do a final increment, because even though the count is base 1, we
196 ; do not include the zero terminator in the string's length.
197 0000003C C3 ret ; return to the calling program
198
</code>
 
 
The above is the List output of NASM, the first column (on the left) is simply the line number in the listing and is otherwise meaningless. This subroutine was extracted from a much larger program, that's why it does not start at zero. The next (second) column is the relative address, in hex, of where the code will be placed in memory. The third column is the actual compiled code. For instance, B9 is the x86 opcode to (load) MOV ECX with an immediate value; the FFFFFFFF is a -1 in 2's complement binary arithmetic (32 bits).
 
The lines with colons are symbolic labels, the labels do not create code, they are a way to tell the assembler that we want to be able to reference those locations. The .done: label is only there for clarity of where the program ends, it does not serve any other purpose. Putting a dot '.' in front of a label is a feature of NASM, it declares the label as local to the subroutine.
 
==See also==
* [[Compiler]]
* [[Disassembler]]
* [[High Level Assembly]]
* [[Instruction set]]
* [[Little man computer]] – an educational computer model with a base-10 assembly language
* [[Microassembler]]
* [[Typed assembly language]]
 
==References==
{{Reflist|colwidth=30em}}
 
==Further reading==
* [http://www.asmcommunity.net/book/ ''ASM Community Book''] "An online book full of helpful ASM info, tutorials and code examples" by the ASM Community
* Jonathan Bartlett: ''[http://programminggroundup.blogspot.com/ Programming from the Ground Up]''. Bartlett Publishing, 2004. ISBN 0-9752838-4-7<br />Also available online [http://download.savannah.gnu.org/releases-noredirect/pgubook/ProgrammingGroundUp-1-0-booksize.pdf as PDF]
* Robert Britton: ''MIPS Assembly Language Programming''. Prentice Hall, 2003. ISBN 0-13-142044-5
* Paul Carter: ''PC Assembly Language''. Free ebook, 2001.<br />[http://drpaulcarter.com/pcasm/ Website]
* Jeff Duntemann: ''Assembly Language Step-by-Step''. Wiley, 2000. ISBN 0-471-37523-3
* Randall Hyde: ''The Art of Assembly Language''. No Starch Press, 2003. ISBN 1-886411-97-2<br />Draft versions [http://webster.cs.ucr.edu/AoA/index.html available online] as PDF and HTML
* Peter Norton, John Socha, ''Peter Norton's Assembly Language Book for the IBM PC'', Brady Books, NY: 1986.
* Michael Singer, ''PDP-11. Assembler Language Programming and Machine Organization'', John Wiley & Sons, NY: 1980.
* Dominic Sweetman: ''See MIPS Run''. Morgan Kaufmann Publishers, 1999. ISBN 1-55860-410-3
* John Waldron: ''Introduction to RISC Assembly Language Programming''. Addison Wesley, 1998. ISBN 0-201-39828-1
 
==External links==
{{Wiktionary|assembly language}}
{{Wikibooks|Subject:Assembly languages}}
* [http://www.atariarchives.org/mlb/introduction.php Machine language for beginners]
* [http://www.asmcommunity.net/ The ASM Community], a programming resource about assembly.
* [http://www.int80h.org/ Unix Assembly Language Programming]
* [http://www-03.ibm.com/systems/z/os/zos/bkserv/r8pdf/index.html#hlasm IBM High Level Assembler] IBM manuals on mainframe assembler language.
* [http://c2.com/cgi/wiki?LearningAssemblyLanguage PPR: Learning Assembly Language]
* [http://www.azillionmonkeys.com/qed/asmexample.html Assembly Language Programming Examples]
* [http://www.grc.com/smgassembly.htm Authoring Windows Applications In Assembly Language]
* [http://win32assembly.online.fr/tutorials.html Iczelion's Win32 Assembly Tutorial]
* [http://mark.masmcode.com/ Assembly Optimization Tips] by Mark Larson
 
{{Programming language}}
 
{{DEFAULTSORT:Assembly Language}}
[[Category:Assembly languages|*Assembly language]]
[[Category:Assemblers|*Assembler]]
[[Category:Programming language implementation]]
 
[[ml:അസംബ്ലി ഭാഷ]]
[[pl:Asembler#Język asemblera]]