Talk:Assembly language

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] Need simple program with explanations

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


[edit] 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.

[edit] 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

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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) .

[edit] 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)

[edit] 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)

[edit] '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:
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)

[edit] 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)

[edit] 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)

[edit] 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

[edit] 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   %ebp
0x08048759 <_Z7squareBd+1>:       mov    %esp,%ebp
0x0804875b <_Z7squareBd+3>:       fldl   0x8(%ebp)
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)

[edit] 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)

[edit] 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)

Retrieved from "http://en.wikipedia.org../../../a/s/s/Talk%7EAssembly_language_3ddb.html"