Talk:Assembly language/Archive 1

Archive 1

Need simple program with explanations

A simple hello world program that explains the mneumonics and registers would be nice!

that tends to get a bit bulky, but for DEBUG here:

jmp 112  ; jump over the next bytes which is the string,they could code fro something like jne in which case the program might not work.

db "Hello world!",10,13,24 ; define byte "stuff" will be made into it'shex and th 10,13 is a charrage return 24 is "$" it :marks the end of the string.

mov ah,9  ; function 9 (string to stdout)

mov dx,[103]  ; using data at 103 till the $

int 21  ; interupt 21

int 20  ; interupt 20 (close)

linux asm

section .data

hello db "Hello Word",10

hellolen db $-hello

section .global

global _start

_start

mov eax,4 ;write system call

mov ebx,1 ;file descriptor for stdout (remmeber in unix "evryhting's a file"

mov ecx,hello ;adress of hello

mov edx,hellolen ;adress of the strins length

int 80h ;interupt only one for unix

mov eax,1 ;system call for close

mov ebx,0 ;exit code 0 no error

int 80h ;interupt

I haven't used DEBUG in ages but it should work.Wolfmankurd 09:16, 23 June 2007 (UTC)

optimizing compilers

"But in general, modern optimizing compilers are claimed to render high-level languages into code that runs at least as fast as hand-written assembly, despite some counter-examples that can be created."

Above statement has no basis. I am a practicing programmer and know several CPU families, and I am damn sure that today's "optimizing" compilers are not yet able to produce code which is even close to what human coder would do. I think that people who claim otherwise did not actually look at assembler output of the compilers. It's their wishful thinking.

Of course it doesn't mean that compilers are "bad" and assembler should be used instead. No, because (1) coding in assembler language is far too slow and hard to be useful for general programming, and (2) compilers are improving, albeit slower that we want them to. ;)

It simply means that if you absolutely _must_ optimize some small portion of code (e.g. numerical sumilation code which has to go over millions of trillions of data points), do not think that high level language compilers will do the work best. You can do significantly better.

From my experience, as for "leaf" code, eg. procedure doesn't call anything, just performs some algorithm (like sorting array, searching tree, etc), human can do better. For procedure which calls several other procedures, checks their return values, has some resource handling, compiler can do much better than human (human could beat it with much effort, but such code will be messy and hell to maintain, with little gain). I think we should put it this way in article, just with better wording than mine (mine english is not so good yet). Vid512 14:35, 9 November 2007 (UTC)

Metaprogramming

Seems there are some individuals interested in a concept called metaprogramming on wikipedia, which I believe is being regarded as something new. Note, Viruses can metaprogram, and why? Code and Data looks the same in assembly (well in machine code, but ever disassembled machine code with the wrong code offset?). I'm of the camp that belives all coders should begin with assembly language, at least to keep them from assuming too much. To really understand object oriented design you should try taking a course on assembly language and digital electronics. Digital_electronics are very object oriented, so much so, just by the arrangement of circuits you can program without ever writing a line of code.

Truths about assembly:

Assembly Language is a macro language version of machine code, its a one to one reltationship. Anyone can program in machine code given enough time but it offers no advantage over using assembly language (usually).

Assembly language is needed to use computers effectively in the initial stages.

Assembly language is not often cross platform compatible.

Assembly language is a general name for a style of programming language where the syntax and semantics are similar but not equal; reliant on the CPU make/model, the system architecture, and working environment of the computer. This is why there is different kinds of assembly, like 8080 assembly (IBM PC's, MSDOS, Windows), 68000 assembly (Macs, Amigas) , 6502 assembly (Commodore 64), etc..

The use of compilers afforded programmers the ability to apply their abilities to a general set of computers, rather than being stuck to a particular platform, so that programmers become masters of patterns and not wizards of a particular archiecture (not unless they prefer that kind of masochism).

Compiled programs cannot run faster than assembly programs as compileable languages are a superset of assembly language. Think of a a compiled program as a set of assembly language programs strung together. Each command in C is at least one assembly language statement, but is usually tens, hundreds, thousands of lines of assembly code.

Assembly language is not very effective for rapid prototyping (unless you are a really good assembly programmer who prefers to write in assembly code before writing a language to manage the complexity)

Assembly language is often machine dependent (not portable).

Java bytecode is not better than assembly language, its just a condensed and unreadible form of Java code (think code obfuscation and commercialization, read up on interpretive languages, Java is just a compileable interpretive language).

Sometimes stuff is coded in assembly to allow it to be sold and impossible to dis-assemble (a business/political concern).

Due to continual changes in microprocessors, investment in experience of programming in assembly is not very rewarding unless you are involved with embedded technologies. So applications programmers tend to use compilers, hardware designers tend to work with assembly language..

Data and Code are represented in machine code the same way, with bytes, so assembly programs must be executed from a particular offset in memory. The facility that a disk based operating system brings to users is the ability to relocate and access code and data over a hard disk platter, but beyond that it doesn't do anything that can't be done with some memory and a CPU.

Assembly language can be abstracted to function like the most capable object oriented language. C is less capable of this feat.

Assembly language is less forgiving than C.

Assembly programs are often written by other programs written by humans, than by humans, this is what a compiler is - a program that writes assembly programs (from instructions written by humans).

Rewriting a program in assembly is not a good way of optimizing a program (many advances in computing came from significant advancements in software design not in advancements in hardware technology), Example, MPEG/JPEG compression, MPEG audio compression, web browsers, etc. Software is like liquified hardware, hardware is like solidified software.

Analogy for younger programmers: Consider high level applications to be like boats, and cros-compilers and virtual machines to be like canals between oceans, and oceans to be the computer platforms, assembly language programs are like the water. However it breaks down when considering the distinction between aseembly languages, versus the distinction of water from one ocean or another.

--Rofthorax 06:47, 31 October 2005 (UTC)

--

Unlike in high-level languages, there is a 1-to-1 mapping from simple assembly to machine language, so that computers can translate in both directions without losing information.

this is not entirely correct. Much information is lost if the assembled executable does not contain debugging information (most executables don't). Such debugging information includes the names of variables, procedures, labels, et al. Without this information, a disassembler cannot show meaningful symbol names and as a result, disassembly listings use addresses or numbered labels which are not human readable (rendering the program almost useless except by experts with a ton of time on thier hands to figure out what each peice of data is used for). Comments and whitespace are also not stored in the executable, meaning that a disassembler cannot recover this information. It would be more correct to state that there is a logical 1-to-1 relationship. 24.198.144.163

Usefulness of assembly language.

There is some debate over the usefulness of assembly language.

Debate? over the usefulness? I think this is a bit far fetched, maybe debate over suitability for some fields of application, I think nobody with sufficient experience would debate the usefulness of asm. Maybe people who don't use asm would debate the usefulness, but that's with any tool.

In many cases, modern compilers can render higher-level languages into code as that runs as fast as hand-written assembler.

Really?? can anyone give a reference for one of these modern compilers please? I've never heard such claims by compiler authors, nor did I encounter such a compiler, I'm very doubtful about the existance of such a compiler, for which programming language? the so called 'high-level' langs of today, don't allow the programmer to express the meaning of the code enough for the compiler to have enough data to make optimisations which the programmer could see. (Nov,2003)

This is an old conversation, but here are a few comments.

• Two commonly-cited examples of highly-optimized compiling that were observed to beat hand-coded assembler are the BLISS compiler (see Wulf, The design of an optimizing compiler, Elsevier, ISBN 0444001581, originally published in the 70s) and compilers for regular expression state machines. The BLISS compiler was noted for combining bit-level operations in ways that were counterintuitive, yielding strange but very compact code. BLISS was a long time ago; more recent compiler technologies have added a range of new optimizations.
• It should be pointed out, of course, that open-source compilers are not known for being highly optimized.
• Compilers have typically done a good job at optimizing things like register allocation, locality of reference, paging efficiency, loop-invariant code, reference counting, garbage collection, and address mode usage – in other words, optimizing at the 4K level rather than the 20-byte level.
• A good but prudent assembler programmer, writing a large application, will use defensive programming and similar techniques to write clear, maintainable code. Thus certain instructions might get placed at the top or bottom of a loop, to ensure that their purpose is clear. The compiler can move or eliminate such instructions since readability of generated code is not an issue.
• Techniques like peephole optimization can take general-purpose constructs and replace them with special-purpose equivalents that might be confusing or error-prone.
• I don't regard the examples cited below as terribly illuminating. A single sixteen-bit or thirty-two-bit instruction can indeed sometimes replace a few specific higher-level statements (though the implications in a pipelined CPU are not always obvious), and not all compilers will take full advantage of this. But this is not sort of hand-optimization that I think most assembly coders spend their time on. We don't need super-fast string comparisons to look for "BOO"; we need super-fast inner loops, and this is an area where good optimizing compilers have tended to do well. (However, optimized string comparisons HAVE been a feature of many compilers, and many library calls ARE replaced by smart in-line code generation.)
• I don't think most compiler designers would agree with the assertion that hand-coded assembly will generally outperform a good compiler.
• The proof is not in how a couple of specially-selected statements get compiled. Look at large all-assembler applications, and compare their performance with comparable applications written in C or other optimized languages. Big assembly applications are often pigs.

I should point out that I am not an anti-assembler bigot, and spent a good slice of my career hand-coding super-optimized assembler. But there's no excuse for compilers that can't do as good or better. Many have. Blame Moore's Law for the fact that we haven't expected more from our day-to-day compilers. Trevor Hanson 03:24, 31 December 2006 (UTC)

I think the above quote is an overstatement. A compiler like the GCC with optimisation as high as it will go can probably out-optimise a new ASM programmer. It has been programmed with weird and wonderful shortcuts that the human just wouldn't know about. However, if you pitch a modern compiler against an experienced ASM programmer, the issue would not be optimisation, it would be time. Paul Gideon Dann (Giddie) 30/03/2004 0241 UTC

How about programming RISC chips? From what I have heard it is extremely hard to do it the optimal fashion by hand. Modern "CISC" chips aren't much better with their out-of-order execution, branch prediction and "some other nasty little" features that are way too hard (time and brain consuming) to facilitate by hand. Even for a very experienced hand. —The preceding unsigned comment was added by 83.31.219.66 (talk • contribs) .

Did _you_ try it? I did. No compiler I ever tried produced code which is not visibly suboptimal. The difference is that good compilers produce code which is suboptimal from place to place, whereas less-than-good ones produce outright awful code.

Example. Find C compiler which will generate optimal i386 code for the following C costruct:

int v(char *p) { if ((p[0]==1) & (p[1]==2)) return 1; return 0; }

Hint: optimal code should do ONE 16-bit comparison instead of TWO separate 8-bit ones. It's faster and code is shorter. I bet no current C compiler will be smart enough to do it. (NB: & instead of && is intentional, otherwise my optimization won't be 100% valid).

Example 2.

int v(char *p) { if (memcmp(p, "BOO", 4)==0) return 1; return 0; }

Just one 32-bit compare will perform this memcmp! However, you will be lucky if your C compiler will not generate whole stinkin' function call instead! Inlined string compare instruction or a small loop is what the very best C compilers do here. —The preceding unsigned comment was added by 195.212.29.171 (talk) 10:11, 29 December 2006 (UTC).

There are several challenges to the assembly-language programmer:

• Scheduling: It's very difficult to schedule instructions so that they keep all the multiple execution units of a modern processor simultaneously busy. For example, you may need to be simultaneously executing several integer instructions, an FP instruction (if available), and a branch.

• Getting instructions to the execution stage: Taking a step back, the circuits that pipeline instructions to the execution units may have a lot of data dependencies that affect whether or not those instructions actually make it to the execution units. For example, data results may or may not be "short-circuited" so they're available in the next microcycle for use by the same or another execution unit. You may also need to keep very cognizant of what's in the various cache levels of the processor (where some of the closest caches may be very small).

• Etc., etc., etc. ...

While a human could keep some of this in their heads, it's very difficult to keep all of it in mind simultaneously. It also varies greatly from implementation to implementation within a given architecture. It's really become a lot easier to Relegate all [this] Interesting Stuff to the Compiler. ;-)

Atlant 17:53, 2 June 2006 (UTC)

some low-level programming is simply easier to do in assembler.

Sometimes some high-level' programming is simply easier to do in assembler, depends what the high-level language you would compare it to at the time would 'hide' from you. for example, writing many numerical abstactions is more direct in ASM, including some work in represantations of groups.

Anyway, the point being that ease is not really dependant on the abstraction level of the code, but rather, on the abstract-idioms or details that the high-level language chose to ignore. (simplest example, C programming language, in-ability to access to carry-flag)

Generations of Programming Languages

So what is a First Generation programming language? and is there a Third Generation? Phil 15:40, Dec 8, 2003 (UTC)

See First-generation programming language, Third generation language and even Fourth-generation programming language. This naming is probably more a naming gimmick than anything else. Especially the 4th. generation languages. Rasmus Faber 15:45, 8 Dec 2003 (UTC)

My problem was that Second-generation programming language is a REDIRECT to Assembly language, so there's no cross-reference to the other generations there. Maybe a covering article showing all four generations in overview? Phil 16:43, Dec 8, 2003 (UTC)

Ah, sorry about that! Good idea. I don't think the generations warrant a page each. Rasmus Faber 16:47, 8 Dec 2003 (UTC)

---

I frankly don't know whose idea it was to name this article assembly programming language, but although it is in use and parallels the names of other articles like C programming language, I believe the term assembly language is considerably more common and entirely unambiguous. I will move this page and talk page. Derrick Coetzee 22:42, 17 Sep 2004 (UTC)

Assembly language is used specifically in dissembly, so its useless to underestimate its need in present as well as future scenario. shareplatform.com disclose its importance.

Another Book

I didn't want to spam the main page, but since you're linking to Randall Hyde's book on assembly language, I thought you might be interested in linking to my book, "Programming from the Ground Up". It's being used by both Princeton University and DeVry right now. It's Linux-specific, so I don't know if it would belong on this page or not. But if you want to add it you can link to it:

http://www.amazon.com/exec/obidos/ASIN/0975283847/

There's a slightly older online version at:

http://savannah.nongnu.org/projects/pgubook/

I didn't even see this, but I added a link to the savannah page a while back. I personally think people on wikipedia prefer a free book over a pay one, but that's just because I'm cheap.(one of the best assembly books I've read yet, BTW :D)

History and variation

IMHO, this article is a bit x86-centric, and it needs a history section. Right now it gives the impression that Lotus 1-2-3 was remarkable in using assembly. Surely the idea was born in the 1950s or earlier, and widely used? The Unix OS was noted for not being written in assembly, circa 1970.

Since 1948, and the SSEM - RaceProUK

Possibly there is a reference to some article on computer instruction sets that I missed. Jgrahn 22:41, 2 March 2006 (UTC)

Merge with Assember

I vote : yes KymFarnik 06:14, 29 April 2006 (UTC)

I vote : no Marsman57 16:50, 2 June 2006 (EDT) - My reasoning is that an Assembler may not even be written in Assembly language itself. Also, it is a distinct type of program much like a Compiler or Linker.

I vote : no - I agree with Marsman57's rationale. RayGates 22:36, 2 June 2006 (UTC)

I vote : no EjayHire 10:02 11 June 2006 (CST) - Assembly is a Language. An Assembler is a compiler that translates Assembly into machine language (or more commonly, object files which have to be linked by yet another program). The Assembler performs many other functions, such as preparsing Macros for constants, and parsing "friendly" variable and function names into stack or heap offsets. There is a fundamental difference. The closest the two ever came was the old MS-DOS debug, where you could enter assembly and it would write or execute the machine language in real time.

I vote : no - I agree with Marsman57's rationale.--ken 04:53, 4 July 2006 (UTC)

I'd have to go with 'No' as well, for reasons already stated above. RaceProUK, 4 July 2006 15:34 UTC.

I vote: no - I agree with Marsman57 ---- Shahzad

Removal of short code and speed code

Someone added to the first section of the article:

"Assembly is derived from a similar representation called short code, whose programming 'language' was of the same name. Contrast this with speed code / 'speedcoding'".

Apparently (i've just read what is on wikipedia) short code was the first programming language, so "first" that it did not even have a compiler, but was compiled by a typist!!! So in a way, short code probably arrived before the notion of assembly code. But to say that assembly derives from short code is in my openion not correct! And I dont know what speed coding is, but I think this should all be removed from the article. At least it should be put into a subsection of the article, and rewritten. What do you say?

Velle 13:31, 20 August 2006 (UTC)

You don't need an assembler to assemble

Its important to understand, that you do not need an assembler to assemble an assembly program. In the old days, it was done by hand. It still can be done by hand. —The preceding unsigned comment was added by 65.112.121.29 (talk • contribs) .

Latest revisions

I started with what was intended to be a couple of minor edits here, to address what I saw was some redundancy and missing details. Somehow this morphed into a wholesale restructuring. I realize now that this will probably be seen as wrongheaded, especially now that I've looked through the comments here in more detail. I have been working on some other material that had a very limited audience, and seem to have got into the 'bold editing' mindset.

Feel free to revert all my changes, or stick them in a sandbox or something, and we can talk about where I was going. If I don't see a bunch of flames here I will have a go at tightening up my edits, but for the moment I'll let things sit.

Sorry if I stepped on any toes here. I really was starting with a very minor point (the focus on the post-x86 universe) and some minor duplications but I must have had too much coffee today. Trevor Hanson 01:28, 18 September 2006 (UTC)

Overview

The previous edit moved the article preamble into an 'Overview' subsection. However, I believe that the preferred structure is to use a lead section before the TOC, which I have restored. I also fixed a couple of typos here (e.g. missing apostophe, self-referential link) and in the process did a little rewording/shortening which I think makes this a stronger lead section. Naturally, revert or change if you disagree. Trevor Hanson 20:04, 31 October 2006 (UTC)

'Assembly' vs. 'assembly language' vs. 'assembler'

I observe some divergence here over the language name, e.g. in some recent cleanup edits. Throughout my career (30 years), the terms assembly language and assembler have been normal and interchangeable. (One would also see assembler language.) However, I don't ever recall people talking about "programming in assembly" – a form which appears in this article. Are there any other comments on this issue? My inclination would be to follow what I believe is historical usage, i.e. to use both terms assembler and assembly language, but not to use assembly as a stand-alone language name. Trevor Hanson 18:33, 3 November 2006 (UTC)

Today there was an interesting change/revert, proposing the replacement of assembler with assembly compiler. I have never heard of an assembly compiler (and, as my comment above indicates, I have never heard assembly language referred to as just assembly). Like most contributors to this topic, I have worked with assemblers, assembly language, and assembler all my life. Moreover, a compiler is quite distinct from an assembler, a lower-level entity that performs an isomorphic map from a mnemonic language to machine instructions. It would be helpful for some of these terminology issues to get addressed here on the discussion page, rather than in comments on updates. Trevor Hanson 00:58, 7 November 2006 (UTC)

I have heard people refer to the language as "assembler", although I think that this is either a pronunciation error, or a confusion of the language with the processing tool. It would be like saying I am "programming compiler", which may be a correct statement, but is wholely ambiguous. The term "assembly compiler" is completely incorrect, and it would be more accurate to call the the programs "assemblers", or more verbosely, "assembly language assemblers". Because of the distinct differences, it is common to refer to different assemblers by their target platform such as "x86 assembler", or "8051 assembler", or when the target platform is indiscriminant, simply "assembler". Also, I see no reason why we can't abbreviate the term "assembly language" as just "assembly", because this abbreviation creates no additional ambiguity. --User:Wknight8111 (WB:Whiteknight) 14:09, 7 November 2006 (UTC)

I agree that the use of "assembler" is highly ambiguous and could easily cause confusion to somebody who does not have the experience of the editors in filtering out otherwise confusing terminology. A quick look at college level text books and dictionaries shows a clear distinction between the language and the utility program. If no objection suggest adding a " not to be confused" comment in the article if people insist on enshrining the ambiguity in a ref text. GoldenMeadows 15:06 09 November 2006

It's fine to seek for linguistic clarity and the elimination of ambiguity, but I don't see how we can do that in the face of normal professional usage. Do we really want to redefine technical language in current use because it seems ambiguous? This is like saying "a bass guitar isn't really a guitar, so let's agree to call it an electric contrabass" (a frivolous example, but you see the point). Generations of programmers have talked about (and continue to talk about) "programming in assembler." There is of course a clear distinction between assembly language and an assembler utility; but I think this distinction is apparent from the article's current overview – and from the context where the term is used. I don't see any rationale (other than pedantry) for insisting on a revisionist nomenclature that singles out a particular naming scheme, and in the process rejects normal usage. Am I being stupid about this? Who is the intended reader of the article? Trevor Hanson 20:09, 9 November 2006 (UTC)

I would use many technically imprecise/shorthand terms when speaking with experienced engineers I would not use with somebody who is not so familiar with the subject. The former have learned by experience to filter out confusing terms or without thinking so much establish the context, the latter have not. You may find it pedantic but your fellow professionals who also write books on the subject seem to suffer from this same quirk as me. Since the article is obviously not targeted towards "professionals" who already know the subject, and it does not purport to be an historical account of the development of computer languages it seemed a shame to introduce a possible source of confusion through the highly ambiguous use of the word "assembler" in the overview section of an introductory article. At best I thought it merited a footnote that mentioned how its misleading use first arose and why such ambiguity is generally avoided in ref book and articles. My interest in assembly language programming goes back to 1976 and any text book or reference work I have used has kept the two things separate i.e. "Assembly Language" and the "Assembler" utility program so its more a matter of keeping to the mainstream , and simplicity, rather than historical revisionism as you suggest. Anybody who takes up the subject seriously will soon come across this and whole lot more in the way of ambiguous terminology but maybe it will have spared the person some confusion and time if they they do not encounter it in intro articles such as this when they are grappling with basic concepts - see earlier entries in this discussion page on the same topic GoldenMeadows 14:05, 11 November 2006 (UTC)

Hmmm, well I am evidently not going to prevail in this debate. That's OK. Your argument is that the terms "assembler" (the utility) and "assembly" or "assembly language" (the language) are basically the correct, official ones. I disagree. Otherwise, I would agree with your view that the other usage is an ambiguous shorthand. My argument is that the terms are NOT used consistently now, and were not in the past. Inconsistency is different from ambiguity. Thus, in Stroustrup's venerable C Programming Language, he states "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" [emphasis added]. Conversely, on the IBM 1401, the assembler was called the "assembly program." [Saxon & Plette, Programming the IBM 1401.] However, this is basically a pointless argument. The usage you prescribe is unambiguous. If you think that inconsistency would confuse newcomers, by all means enforce a simpler terminology. I agree that a footnote in the terminology section is enough to maintain accuracy. (I would resist characterizing the alternate usage as being an error, however. That was what riled me in the first place. Calling an assembly language assembler may be inconsistent, but it's not a mistake.) Trevor Hanson 22:58, 11 November 2006 (UTC)

On looking at the comment I made to the original edit I agree that my assertion was too black and white and would indicate error -- my apologies, I should have elaborated here on the discussion page why I thought its use in an article overview was a source of confusion. I agree with the proposal regarding a footnote.GoldenMeadows 12:48, 13 November 2006 (UTC)

In poking around, I have found more recent examples of the stand-alone name assembly than I expected, though I believe this is a recent change (in my professional experience, I never recall hearing people refer to assembly language as "assembly"). I agree that this form creates no ambiguity, and since it's in current use I withdraw my objection.

However, I disagree with you that referring to the language as "assembler" is the result of a pronunciation error or confusion. In my experience, this was long the most common term used for the language – no doubt a contraction of "assembly language," but not an error. I suspect it may still be the most common usage. Here are a few contemporary examples via a quick Google:

• http://www.simotime.com/indexasm.htm: "The 370 Assembler Instruction Overview" and numerous other examples
• http://www.masm32.com/: "for programmers who are interested in either learning or writing 32 bit Microsoft assembler"
• http://home.snafu.de/nkomin/html/assembe.htm: "Why Assembler? Assembler gives you the opportunity to program right on the hardware"

Bottom line: I believe that all three names (assembly language, assembler, assembly) are in current use, and that this article (and its editors) should not choose one form over another. Trevor Hanson 19:18, 7 November 2006 (UTC)

I've known several people in my lifetime, many of whom are practicing engineers, who refer to the height of an object as the "heigth" of the object. The pronunciation is different, the spelling is different, and even though professionals are using it, it isn't correct. There is a difference between the slang words (or even the incorrect pronunciation) that people in industry are using, and what the thing is actually called. In books and other scholarly publications, I have never once seen the language, or the act of programming in that language called "assembler". The language is called either "assembly" or "assembly language", and the software the converts the pneumonics into bytecode are called "assemblers". If you can cite a source that says differently, it would be news to me. --User:Wknight8111 (WB:Whiteknight) 20:58, 15 November 2006 (UTC)

See the citations I recently added to the terminology section. (I believe you will accept Bjarne Stroustrup as a credible source. This is one example, NOT the result of an exhaustive search. If you haven't personally seen this usage, I submit that you haven't looked widely enough.) I agree that using the term "heighth" (or "heigth" as you say) is a well-known error, like saying "newcular" for "nuclear". But I do NOT agree that using the name "assembler" for the language is this kind of error. It is simply an alternate form, one that has been used in the literature for decades – like "register" versus "accumulator". There is no official authority who decides (as you put it) what the thing is actually called. (In fact, if enough professional morons misuse a term, it enters the official technical vocabulary; thus we say "graphical" instead of simply "graphic", and we have invented words like "prioritize" and "proactive". Computer scientists have also borrowed and bastardized plenty of mathematical terms; look at how we have reinvented isomorphism for example.) However, I can see that this argument is going nowhere, so I withdraw. By the way, the word is mnemonics, not pneumonics. Trevor Hanson 04:50, 16 November 2006 (UTC)

Why is machine language included here?

Why is machine language included here? Surely this material should be merged with the Machine Language article. Jpaulm 19:18, 2 December 2006 (UTC)

I agree; although for this article to stand alone, some of the basic concepts and issues may need to be summarized. Several related articles really could also use a brush-up, such as instruction set. There is duplicated material, and I don't think they present the subject matter clearly and generally enough. Trevor Hanson 23:49, 2 December 2006 (UTC)

Cut material, 12/4/2006

The following was removed by User:Ashmoo today without leaving a comment as explanation:

However, a strong case can be made that any serious programmer should learn at least one assembly language – to understand the fine structure of how computers function, to anticipate how application design choices can improve generated code, and to appreciate all the work high-level languages save.

Does this need to be removed? Is it wrong? or badly stated? or POV? (I should disclose that I think I may have written this in its current form, based on an earlier similar statement; but this is not a question of pride of authorship. If it should go, it should go.) This idea is stated in much writing about assembly language; I'm surprised to see it removed from this article, and wonder what the consensus opinion would be. Trevor Hanson 06:49, 5 December 2006 (UTC)

Sorry for chopping it without adding a comment. My thinking was, basically that WP shouldn't be 'making cases', the concept of a 'serious programmer' is ill defined and qualatative and the sentence seemed like an opinion without a source. If it can be made more definite, put into context (ie who says this IT lecturers, industry leaders, internet programmer forums?) and hopefully a notable source, I wouldn't have any issue with its reinclusion. Regards, Ashmoo 04:16, 7 December 2006 (UTC)

I see, thanks for replying. I'll see if I can come up with a good source stating this position (though I think you'd have a hard time finding many professionals who would dispute it). Trevor Hanson 21:29, 7 December 2006 (UTC)

There's a bunch of statements to that effect on the original wiki:

• "If a programmer really wants a solid foundation, there is no substitute for assembly." -- GarryHamilton WikiWikiWeb:FirstLanguageLearned
• "CeeLanguage and AssemblyLanguage ... really make you understand how the machine actually works. Thus, one of these low-down-and-dirty languages should be the FreshmansSecondLanguage?. I would favour asm over C, as it has less magic (malloc and free - too high level!)..." -- TomAnderson WikiWikiWeb:FreshmansFirstLanguage
• "assembly language (and I don't deny it's a good idea at some point, but I certainly wouldn't start with it)" -- KarlKnechtel WikiWikiWeb:FreshmansFirstLanguage
• "You need both ends of the spectrum" -- WilliamUnderwood WikiWikiWeb:FreshmansFirstLanguage
• "Only working in ASM will really teach the student where these proficiencies lie. However, these environments will also eventually drive the students mad" -- WikiWikiWeb:LearningAssemblyLanguage

Of course, on the same page there are people who disagree. Do any of these quotes meet Wikipedia article standards? --68.0.120.35 06:11, 4 October 2007 (UTC)

Looking at the site and the authors, we're faced with the usual notability problem. The contributors sound like knowledgeable and thoughtful practitioners; but from the ones I looked at, they are apparently not recognized experts; and of course, the source is not a mainstream refereed publication. I conclude that these quotes would not be regarded as ideal sources. If we were dealing with an esoteric subject with a small community of specialist practitioners, something like this might be the best one could get. But computer science education is not a fringe discipline. So we ought to be able to find authoritative textbooks, curriculum guidelines, etc. to make the point. At any rate, I think the concept has been reinserted in the article, with some supporting sources. The mere fact that so many computer science programs include assembler programming would seem to be prima facie evidence that its study has recognized value. Trevor Hanson 03:12, 5 October 2007 (UTC)

An anecdote

Hi! I spent about 20 years programming in assembly language, primarily on IBM mainframes (S/360, S/370, 43xx computers, DOS, DOS/VSE, OS/MFT, OS/MVS, etc). I've got an interesting story to relate.

In 1983 I was working in Denver, Colorado when we hired a new programmer named Olga Hnizdil. Olga had recently emigrated from Czechoslovakia, and didn't speak English very well. I was assigned the task of making sure she was reasonably familiar with assembly language. So I sat down with Olga and a simple BAL output listing, and proceeded to describe to her the various fields (location counter, assembled opcodes / data, input statement numbers, symbolic labels, mnemonics, comments -- left to right on IBM assembler SYSOUT), and to explain how they all hooked together, as best I could.

After about 10 minutes of this I noticed that Olga was just staring at me, her jaw slack in amazement. "What's wrong, Olga?" I asked. "Am I talking too fast? Is this making any sense?"

She shook her head slowly. "Are you telling me that if you want to add one more instruction to this program you can just put it in there, then run it through this assembler, and all the offsets to data items, and to other places in the program, will be fixed up by the computer itself?", she asked, incredulous. (Well, actually she didn't say it quite like that. She didn't speak English very well, then. But that was the gist of it.)

"Yes, Olga." I said. "That's exactly what I'm telling you. What's wrong with that?"

She shook her head in amazement again. "Well, in Czechoslovakia, if we added one more instruction to the program we had to go all the way through the rest of it by hand, and compensate for the extra 2 or 4 or 6 bytes that were in the program now. Sometimes it took a week just to put one new instruction into a big program!"

Olga was one happy camper right from the getgo. She could get an entire month's worth of work done in one or two days! And after that I never worried a bit about her facility as an assembly language programmer. DavidCBryant 20:20, 17 December 2006 (UTC) Bold text

Syntax

I'm trying to understand what GDB's disas's output means. For example, this function takes a double and squares it:

0x08048758 <_Z7squareBd 0>:	push   �p
0x08048759 <_Z7squareBd 1>:	mov    %esp,�p
0x0804875b <_Z7squareBd 3>:	fldl   0x8(�p)
0x0804875e <_Z7squareBd 6>:	fmul   %st(0),%st
0x08048760 <_Z7squareBd 8>:	leave  
0x08048761 <_Z7squareBd 9>:	ret    

I get the impression this is AT&T assembly syntax, but that page doesn't exist here and the page I found the most information on could be more helpful. Should this syntax be mentioned in this article? —Ben FrantzDale 21:30, 8 February 2007 (UTC)

Links

I have found that MenuetOS has a WP page, so have added the link to the LI under ext. links, though it is obviously int. Suggest int. links section or renaming the current section...

Thoughts: MonstaPro 00:34, 18 February 2007 (UTC)

No article about macro assembler

The article mentions in passing the S/370 macro assembler, and talks about macros and macro languages, but there is nothing about macro assembler (I don't know if macro assemblers have something to do with macros in assembly languages). The MASM article doesn't explain what a macro assembler is, so I think someone more knwoledgeable than me could give the definition of a macro assembler. Apokrif 15:56, 8 March 2007 (UTC)

A macro assembler is an assembler that includes a macro facility. Simple as that. I'll check that the recent changes make this clear, and if not I'll add some verbiage. Trevor Hanson 20:15, 18 April 2007 (UTC)

See revised overview, which now ends with a definition of macro assembler. Trevor Hanson 22:18, 18 April 2007 (UTC)

Language design rewrite, April 2007

I've just done a partial rewrite of the Language design section. I ended up dividing it into three subsections and changing the bulleted lists to paragraphs. Most of my changes were reorganizing existing text without much change, but I've also (1) added stuff about pseudo-operations and local symbols, and (2) expanded the coverage of macros.

(I'm biased about macros. I used to do a lot of PDP-11 assembler programming using the MACRO-11 assembler, which had an amazingly useful macro system.)

As always, corrections and improvements are welcome. Cheers, CWC 11:59, 10 April 2007 (UTC)

Overview editing, April 2007

I made some changes to the overview which I hope will be seen as positive. I didn't like the little footnote about compilers/interpreters – it didn't really seem like "the Wiki way" – so I have tried to put it back into the text. In the process, I've tried to clarify the relationship between assemblers and high-level languages, which seems at the heart of the matter. I also though a mention of second generation programming language was a good idea, and added a few other bits which I think clarified things. As always, do feel free to revert or change if you disagree. Trevor Hanson 22:23, 18 April 2007 (UTC)

That change isn't just positive, it's brilliant. For one thing, mentioning second generation programming languages adds important historical context. Thanks, Trevor! Cheers, CWC 05:36, 19 April 2007 (UTC)

<blush>...Thanks. It's always nice to know somebody else looks at the articles. Trevor Hanson 23:06, 19 April 2007 (UTC)

Cleanup 22 June

I'll tag this are requring a clean up, I've read through it it doesn't flow well and there is loads of repetition. The information could also be organised so it's more concise. Wolfmankurd 10:30, 23 June 2007 (UTC)

"Secure application"

From the "reasons you might choose assembly":

When a secure application is needed and no high-level compiler is trusted by the programmer.

What's up with that? It seems to me if the programmer doesn't "trust" a higher-level compiler, why should they "trust" the assembler? Why should they "trust" the operating system? Why should they "trust" the CPU it's running on? If that really was a legitimate reason for not using a higher-level compiler, you'd better be sure that absolutely every else in the system were controlled by you as well.DeanHarding 01:27, 3 July 2007 (UTC)

Agreed. This thinking is perhaps appropriate when using nonstandard compilers, which might have Trojan code generation, but is not relevant to normal use. An exception might be NSA circles – where absolutely nothing would be taken for granted, and where the object code (or the compiler/assembler source) would be scrutinized to ensure clean output. So this struck me, also, as being a bogus claim. Go ahead and reword it, by all means. Trevor Hanson 06:08, 3 July 2007 (UTC)

I've modified the point a bit and pointed to the section on "reflections on trusting trust" article which describes how a backdoor can be placed in a compiler that is almost undetectable. Mind you, there's nothing stopping someone putting such a backdoor in an assembler, but at least you can counter that by doing the assembly by hand.DeanHarding 06:46, 3 July 2007 (UTC)

This is also part of the point of typed assembly language - removing the compiler from the trusted computing base - which we ought to point out. Dcoetzee 22:42, 25 July 2007 (UTC)

No mention of micro controllers

Micro controllers used in electronics still use Assembly Language as their main programming language, yet there is no mention of it on this page. It seems as though this page is focused more on the PC user's computer than anything else. Salgat 03:09, 16 July 2007 (UTC)

"Smallest symbolic assembler?"

Code size was critical in the 50s-70s, when you'd reference instruction opcodes as constants to save a byte or two. I can't remember the size of assemblers running on IBM 70x, IBM 1130, CDC lower 3000, or PDP-8, but let's see some citations to back up this claim. Trevor Hanson 20:30, 25 July 2007 (UTC)

I'm not confident of that statement either - given modern RISC instruction sets, I'm sure someone could at least potentially hack together a smaller basic assembler. It's certainly small though. Seeing as there are many assemblers that were never publically released, and there's no Guinness Book for these things, we should avoid absolutes. Dcoetzee 22:41, 25 July 2007 (UTC)

"Opcode" versus mnemonic

A recent change asserts that the term "opcode" properly only refers to the binary instruction (presumably, instruction fragment) and not to the mnemonic used to refer to it. This seems vaguely plausible, but it isn't the way I've seen the terms used (working on a wide variety of instruction sets and processor architectures, on projects at various levels of distance from the bare electrons). To avoid this perhaps reflecting one editor's POV, let's please see a citation that makes the distinction in an authoritative way. Trevor Hanson 04:10, 4 September 2007 (UTC)

There is not necessarily a one-to-one relationship between mnemonics and machine codes. It is possible for a processor to use different machine codes for performing slightly different shades of an operation. For example, if there were a hardware based advantage in execution speed for an instruction that refers to a data register being different from the equivalent instruction for an index register, it makes sense to use the same mnemonic in order to simplify programming and use the assembler to generate the proper instruction based on the argument(s). Whether such a situation exists today is irrelevant; using "opcode" to refer to mnemonics limits extensibility.--Flagmichael (talk) 21:31, 23 May 2008 (UTC)

Merger proposal

By the terms of both articles, Second-generation programming language = Assembly language. The articles should probably be merged. But, I don't have the subject matter knowledge to do it.--Doug.^{(talk • contribs)} 04:56, 7 October 2007 (UTC)

It seems that Assembly language is the much more common term so the merger should probably go TO this page. Second-generation programming language is part of a series of articles on programming language generations, but there is no reason it can't simply redirect here.--Doug.^{(talk • contribs)} 05:12, 7 October 2007 (UTC)

I would have thought this could make sense, until I read Second-generation programming language. It makes the astonishing assertion that C can be considered a second-generation language. I am dubious, but if this topic is even discussed there, then the articles need to remain separate – since obviously C is not an assembler. I am skeptical, however, that this application of the term has any support in the literature. The whole idea of language generations developed along with hardware generations – and by the time C came on the scene, the second generation was far behind us.

However, thinking further about the merger proposal, the language generation articles probably should stay as they are, in a series; but we should put a {{main|Assembly language}} on Second-generation programming language, and transfer anything substantive from it to this article, only leaving in place discussion pertaining to the generational changes. Trevor Hanson 17:17, 7 October 2007 (UTC)

• • • • Note my recent edit to Talk:Second-generation programming language. Trevor Hanson 18:22, 7 October 2007 (UTC)

I agree with Trevor.RayGates 17:23, 7 October 2007 (UTC)

My lack of technical expertise puts me in no position to disagree. I would point out though that 2GL is a stub, and my limited understanding would suggest that any further expansion would require it to simply draw from here. Further the discussion of C seems to say that it's considered by some to be a hybrid or an intermediate between 2GL and 3GL. That doesn't seem to jive with what it says at C (programming language), but that's up to technical folks to figure out. But if it's not true it should just be deleted and not affect merger/non-merger discussion. Someone else's poor scholarship shouldn't affect a decision here. It seems to me to make perfect sense that I should click on 2GL and get this page rather than that one. The question shouldn't really be "should we have two pages", at least not in the first instance, but "are the terms synonymous or substantially so?" If they are they should be merged, even if it involves removal of all content at 2GL. If on the other hand, I have misunderstood and 2GL is not substantially the same thing as Assembly language then both articles need some clarification but merger would clearly not be appropriate.--Doug.^{(talk • contribs)} 23:59, 7 October 2007 (UTC)

• • • • Notwithstanding the further comments below, I think this is an interesting issue. As a technical (Wiki, not assembler) matter, I disagree with the premise that two synonymous terms should necessarily always be merged into one article. This is a case in point, highlighted by SilentC's comment. If it makes sense to have a series of articles on language generations (I think it does), then it makes sense to have an article on 2GL qua generationality. It might be (probably should be) one short paragraph that links to assembly language AND programming language generations as main articles, and that addresses specifically the historical transition of language generations. It should NOT duplicate any material from either main page. But it is useful (I assert) to have essentially a placeholder article that shows how this technology fits in the timeline. It would then be our responsibility to be sure that substantive additions to that article usually get shifted to the appropriate destination. This strikes me as the Wiki way to assemble an appropriate network of references. Trevor Hanson 07:38, 8 October 2007 (UTC)

I disagree with the proposed merger. 2GL is an abstract term and is usually discussed in the context of first, second, third etc.. generation languages. Assembler happens to be the main or only real example of a 2GL but you can say the same about machine code, which is the only example of a 1GL. There are many more 3GLs. It does not make sense in the context of the series to remove or merge 2GL - and if you did that it would be logical to also remove or merge 1GL. It is an abstract discussion concerning programming languages. Assembler, C, COBOL, Visual Basic are real examples of the abstract definitions. SilentC 01:34, 8 October 2007 (UTC)

I've now reviewed Trevor's comments at Talk:Second-generation programming language more thoroughly and have to say I agree generally. The generation pages need substantial work. I don't have the technical expertise to fix the problem though I can see what I can come up with for resources and I can do some copyediting, etc. I'll remove the merge tags, would anyone be interested in working on those pages from a technical perspective? Should this discussion be moved there? It seems to have more of an effect on that article (or series) than this one.--Doug.^{(talk • contribs)} 03:03, 8 October 2007 (UTC)

I think I agree that this discussion makes more sense in the context of language generations; though I tremble to move discussion text from one article to another. Fortunately we aren't in the middle of a revert war so I guess it's not a problem.

I also agree that this is a moderate project, beyond anything I personally could take on right now. The research will be somewhat challenging, because little of this history is available on-line (as I found out working on early CP/CMS history). So this will take library visits and book purchases. I will watch what emerges on these articles over the next few weeks, hoping for a champion to rise to the occasion. If not, perhaps I can free up some time next month. Trevor Hanson 07:38, 8 October 2007 (UTC)

Typical uses: video codecs

May be it is a good idea to add video codecs to the list of typical uses, in the first section, since most video codecs spend most of their processing time in assembly written loops. This makes them quicker or helps conserving power during video decoding, which is an important laptop/notebook-benchmark.

I think people who look up assembly language in a dictionary can relate to "video encoding and decoding" better than to "driver programming". Even now (2007) Intel adds new instruction to the IA32 architecture to enable better optimized assembler loops specifically for video encoding/decoding. —Preceding unsigned comment added by 80.171.29.82 (talk) 18:33, 11 November 2007 (UTC)

Intrinsics / builtins

Nowadays, Intrinsics or builtins can be used in many C/C compilers to insert assembly level instructions into compiler generated code. This style of programming is highly encouraged by processor vendors and gives a very sweet break-even between development costs and performance, rarely worse than hand written assembly yet much easier to write and maintain. This is not discussed in Wikipedia.

Inline assembly is only briefly discussed in Wikipedia.

I suggest a section of "assembly language" should describe the transition from machine code -> assembly language -> inline assembly -> intrinsics. —Preceding unsigned comment added by 80.171.29.82 (talk) 18:49, 11 November 2007 (UTC)