I took an assembly programming course a while ago and the teacher began the lecture with: "No one really need to know this stuff, and you will never use it, but its required by this program so we've got to struggle through the next several weeks studying the material.

My opinion

To write great code requires one to write efficient code. Writing efficient code requires good algorithm choices and a good implementation of those algorithms. Learning/knowing assembly language, will help a programmer understand how the underlying hardware works thereby forcing em to think in assembly language (For example, data representation, memory organization, elements of computer architecture, how input/output operates, etc, ). This knowledge will make the programmer aware of the problems with certain inefficient sequences so they can avoid them in their high-level code.

Your Opinion

Do you think Learning Assembly Language is a waste of time?

Most problems which require the use of assembly language - such as operating systems and device drivers - have been solved already or are being solved by specialists in the companies that produce such products. Complex problems are best solved by languages that allow you to think on an absract level. If you write the program in a high level language and it's just not fast enough, then you can consider C++ or assembly language.

Computers have become so fast that most problems these days can be solved by super-high level programming languyages like PHP and Python. So why trouble yourself with C++ or Assembly language? It took me a while to accept this.

Nope, Assembly is definitely not dead. You don't even need to write an OS to use ASM.

Think about all the high-level languages. New ones are constantly being developed, right. What do the compilers generate? An executable that is actually a mass of hexcode or some intermediate bytecode that requires the knowledge of ASM to create. Even if your compiler is not written in low level Assembly, you need the knowledge to write an efficient, quick compiler.

Mission critical, real-time embedded systems, where human life is in danger e.g. vehicular braking systems, manned space flights. All make a lot of use of ASM.

ASM will remain relevant as long as the primary computing model is the micro-computer as we know it(i.e. binary model with low/high voltage indicating 0/1). Chip makers will only consider a change to binary model/ASM if totally necessary. Even if the computing model finally towards physics(quantum), what we will get will be a revision of ASM to handle the new types of processors.

Seun:

Computers have become so fast that most problems these days can be solved by super-high level programming languyages like PHP and Python. So why trouble yourself with C++ or Assembly language? It took me a while to accept this.

@ Seun et al

I understood your line of thought but the issue here is the knowledge of a target (alluding to what  sbucareer said about portability) system architecture towards the use of high level language. You will agree with me that word processor written 21 years ago aint 16,384 times faster as Moore's Law would suggest. Even if you never intend to write a singe line of assembly language code, learning assemble language, and learning to think in assemble language will force you to learn the costs associated with various high-level constructs which will invariably lead to efficient software.

Of course, it would be foolish to say that programmers should begin writing commercial applications in assembly language. However, to reverse the trend of software running slower and slower even though CPUs are running faster and faster is going to require programmers to begin considering the low-level implications of the code that they write.

Software remain slow simply because features are being added to take advantage of the extra speed. The more the capacity, the more a software developer wants to add more features to take advantage of it.

If you are considering the speed of processing time of an application, you have to consider the hardware/architecture of existing technology.

You said ASM could be used in (For example, data representation, memory organization, elements of computer architecture, how input/output operates, etc, ) And mochafella said Mission critical, real-time embedded systems, where human life is in danger e.g. vehicular braking systems, manned space flights. All make a lot use of ASM. 

Remember that the highest wave frequency for transmitting wireless data is currently at 54Mbps, LAN and WAN is currently at 1000Mbps and 155Mbps respectively.  The computer architecture is currently (Mother Board) at 133Mbps and the [url=http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=deskbar&q=define%3A+FSB]FSB[/url] is currently less than 1Gbps.

All these issues have to be considered as well. Like Moore said transistor found in CPU chip has doubled every two years. It is still useless if the data bus cannot shift the data as quickly as possibly to the CPU.

ASM, like in life has become old language and people tend not to bother to learn it. But I believe it use in today critical systems will still strive the force for its longer life.

Back in the days when I started programming, my first computer was a Sinclair ZX81 which you connect to a TV, download the programs from a casset player or type it in raw. It was very interesting and my main objective was to load in games from specialised magazines with time the games became too slow and I optimised and tweaked the codes written in Sinclair BASIC until I couldn't squeeze out any more juice from it, this was how I ventured into Z80 assemble language programming, since I didn't have an assemble to use I had to convert the nemonics to machine code, a very tedious process you don't want to get into today. The end result was a turbo fast program and the next challenge was how to slow down the program.

Assembly language is very powerful if you know how to use it but very time consuming, you are dealing at the lowest level of instruction with interrupts into the operating system and any mistake in code would hang up the system.

These days you don't really need to kill yourself programming in assembly as most high level programming languages can handle almost any task you can think of, but knowledge of it could come in handy if you do need to program devices with limited memory.

programming in assembly is only necessary if your app requires speed. the industries i know, that use ASM are the Graphics and OS industries.
like sbucareer said most HL languages (badly written code) can produce bad ASM code. u only need to look at the assembly code they produce with a dissassembler. hence ASM tweaking and inline ASM is neccessary for these kind of apps.

That is not the only use of assembly.

All OSes must incorporate some assembly. No matter how high level you write code, in order to interact with hardware, you will need to write routines specific for a processor or some interface module. If you want these routines to run as fast as possible, you will use assembly.

If a high level language compiler doesn't exist for a microcontroller, then you would have NO choice but to use assembly. If you are writing code for an embedded system and you need to streamline costs, boost speed and performance, you will use assembly.

I don't know about people here, but assembly is still alive and well in my field of work.

i'm an electrical engineering major in the usa focusing on robotics.

yeah of course, u can't do hardware without ASM.

this thread just seemed to be focusing on the use of ASM with regards to software dev.

you mean developing softare for desktop systems.

SW development still must go on for embedded systems as well.

Allonym almost said it all, however compilers have come such a long way that you can get away with C 99% of the time. ASM is mostly inevitable when it comes to embedded programming but even this argument is starting to lose its validity (you can program both PICs and atmel chips in C), alot of people use C or erlang for signal processing and then OOP (C++ or java or something else) for software.

ASM is not that daunting either (so you might as well just learn it), you need to learn about 33 instructions to be able to get anything done and understand the microprocessor architecture). ASM also improves your logical thinking (so what have you got to lose but one more language on that CV!). And like SBU said it gives an understanding of what happens "behind the scenes" when programming. Also really good for debugging C output! But these days I tend to use C only, cheaper maintenance (believe me I know, I spent the whole of summer converting some firmware from ASM to C).

Conclusion is, this argument has been made time and time again infact so much so that I just tell people to google it these days, but both have their Pros and Cons like most things in life. C and ASM happen to almost balance out, such that it becomes a matter of the programmers preference (for a hobbyist) or your clients preferences.

One reason I will still advocate teaching assembly, especially to electrical engineers who may not delve too much in other programming languages is for a thorough understanding of pointers.

In assembly, you will learn to implement all the possible addressing modes of your processor. If there is some addressing mode that doesn't exist, you can emulate it with multiple instructions. Once you get around to accessing data in assembly, using lookup tables, or modifying data passed to a subroutine, you will quickly learn about indirect addressing modes and a smart teacher can quickly make the connection between that and all pointer stuff. For example, address register indirect addressing with post increment. . corresponds in c to:

*p_dest++;

So, if anything, its a great tool for learning everything about pointers. . which ultimately is the building block for just about anything interesting in C or C++.

I don't think its dead, especially with lower level programming and exploit development. ASM is one of the most efficent languages out there. Anyone who codes in ASM is worthy of notice and attention.

assembly is not quite a language . . as is C. .

For example, for a class, we each had to design a 4-bit microprocessor. To limit the amount of "help" you could get from other classmates and to make it a more individual project, we were each assigned slightly different architectures and limited to certain units. , for example, some people could use a hardwired control unit, others a microprogrammed one. Also, the types of buses, tri-state buffers vs muxes, etc were specified.

The control unit is essentially where you generate all the control signals that make the math and logic units of the processor function correctly and store their results in the right places. It essentially implements the possible instructions of your processor. This means all of us had to create the binary signals that would make each function get the correct operands, perform the correct operations, and store the result in the correct places.

So, the bit pattern that forms those signals are grouped in a manner up to the designer. So, for example, the bits which control stuff could be arranged like this:

[Logic funtion select] | [math function select] | [ input register] | [output register]

Of course, even for my 4-bit processor, it was more complex than that. But, my point is that for each "function" your processor can do, there is one and only one combination of those bits that will do it.

So, A + B -> A yields one combination and A + A -> A yields another. These combinations are typically called OPCODES or machine code.

Assembly language is a means to write text that another program translates to the opcodes of your specific processor.

So, while A + B -> A has similar opcode to A + A -> A or A + 1 -> A, it will be painfull to have to memorize all of them. (of course. . i had to actually create all of these for my processor. . . but I only had 16 "instructions" and two registers to select from. . . so it wasn't that bad. ) So, you assembler essentially does that memorization and translation for you.

I say all this to say that assembly is only as efficient as the designer allows it to be.

If I created my processor so that to add two numbers, you had to go through 20 steps to load them into each register and another 10 to actually perform the add. . . the assembly . . .and the processor would be terribly inefficient.

That is garbled nonsense, ASM is a human-readable notation for the machine language that a specific computer architecture uses. Machine language, a pattern of bits encoding machine operations, is made readable by replacing the raw values with symbols called mnemonics. Ergo, its simply a _lower_ level language, evidently you're trying to class ASM along with scripting languages like javascript and HTML, don't be fooled, learn what you don't know fully, k thx.

@allonym & f0d
I'm not certain you guys are listening to each other.

"f0d" said ASM is efficient, that is true, he's assuming the designer of the chip will not have redundant/ineffcient opcodes.

"allonym" said ASM is only as efficient as the designer of the chip wants it to be, that is also true. ASM can only be as efficient as the binary notation it translates too.

Of course we are assuming that the assembler is efficient but thats another story. My point is there is really no basis for your disagreement, you are both saying the same thing. ASM is only as efficient as the chip maker wants it to be and it varies per architecture. Chikena. Finito.

1) You cannot assume that an assembler is efficient.
2) I'm not going to attempt to guess exactly what people are thinking. I'm going to respond to what is posted. I saw nothing in his post hinting that he's assuming that assembly is only as efficient as the designer makes it. . . in fact, if he did say that, then there would be no point in making a further statement about the efficiency of assembly. Therefore, it would seem that he could NOT have been making that assumption.

In fact. . . there is nothing efficient or inefficient about an assembler.

In case you have forgotten, all an assembler does is translate short pnuemonics into the even harder to memorize machine code. It does not do ANY code reorganization at all. The only place assemblers optimize code is when instructions are "emulated". Emulating an instruction means that your processor has one or two instructions that it supports which when used together achieve the same result as some other instruction not natively supported by the processor. Since, depending on the processor, there are multiple ways you could "emulate" a particular instruction, that would be the only case where an assembler could be talked about with terms approaching the word "efficient".

So, my point still stands, assembly is only as "effcient" as the designer makes it. Technically, all assemblers are equally efficient because technically, assemblers are not efficient at all. . . they just expand pnuemonics from something easily memorized by humans to something not.

Just for the record assembly is NOT slow or inefficient it just has its place and where it's best suited, I can tell you mission critical and real time systems, Assembly ( or things like VHDL ) are still the number one solution, that includes rockets, missiles and the likes. Can I also suggest that for any mission critical system written in say embeded C or C++ or ASM or whatever and based on thesame design where the instructions have been flashed on the chip will perform at approximately thesame speed ( the choice of language is usually dependent on how well it interacts with the target hardware )


DoS
MCAD.Net
MCSD.Net

ok, all u ASM peeps.

i want to learn ASM in a day! any pointers or links to simple fast easy to understand tutorials? i could google it but i think the experienced ones know whats up? my priority is to be able to read ASM code not program it. i'm only interested in the intel chips for now.

thanx

Assembly Language book

There is always Randall Hyde's classic The Art Of Assembly

thanx y'all

in a day?

Well, what kind of assembly?

Intel? motorola? ti? pic? Atmel?

There are lots of assembly types. Id say to get a general grasp on one, its best to pick one and read up on that, rather than trying lots of different things. I'd also suggest looking up 6800 assembly. This is a small instruction set and pretty simple to understand. (Another thing involved in assembly types is the processor memory architectures - harvard or von-nuemann). Anyway, focus on 6800 assembly.

For something more basic, lookup Register Transfer Logic or Register Transfer Language. This is essentially a description of how data is transferred in a processor and serves as a further explanation of how certain common instructions work.

allonym:

in a day?

Well, what kind of assembly?

Intel? motorola? ti? pic? Atmel?

There are lots of assembly types. Id say to get a general grasp on one, its best to pick one and read up on that, rather than trying lots of different things. I'd also suggest looking up 6800 assembly. This is a small instruction set and pretty simple to understand. (Another thing involved in assembly types is the processor memory architectures - harvard or von-nuemann). Anyway, focus on 6800 assembly.

For something more basic, lookup Register Transfer Logic or Register Transfer Language. This is essentially a description of how data is transferred in a processor and serves as a further explanation of how certain common instructions work.

c0dec:

i'm only interested in the intel chips for now.

i just want to learn how to read ASM code for debugging and optimizing my C++ programs.

oh, assembly for desktop/laptop processors.

You should be able to find plenty of resources for that. . . I don't know any offhand since I focus more on smaller or embedded ones. . i know the microsoft C/C++ documentation, the MSDN library provides some info on that.

c0dec:

i just want to learn how to read ASM code for debugging and optimizing my C++ programs.

Take a look here if the programs are for intel x86 boxes. It's free stuff too.

http://developer.intel.com/design/Pentium4/documentation.htm#manuals