It would definitely be to your advantage to have at least a fundamental knowledge of assembly if for no other reason than to know how programs are run at the machine level. Assembly language is not nearly as relevent in today's 32-bit environments which gobs of ram and fast hard drives. You can still do in-line assembly pretty easily if you think you can out-optimize your compiler. If you are looking for portability between operating systems, such as *nix and MS-Windows, then you should stay clear of assembly -- it ain't portable.

I just run across this today:
http://discuss.joelonsoftware.com/de...joel.3.7054.16
which basically asks the same question. Pondering this, I came up with this analogy:

All the die-hard Amatuer (Ham) Radio people will continue to preach about all the reasons to learn Morse Code even though it is easy today to get an advanced license without ever hearing a 'dot and dash' sequence. There are only 26 letters in the alphabet, and if you learn one per day then you will have it mastered within a month... so why not do it? Voice transmissions take up a large bandwidth. When your entire neighborhood is talking and you can't find a clear channel to use, what are you going to do? If you know Morse, you can squeeze yourself into the airwaves.

Here is an example of someone putting their knowledge of assembly language to good use. http://invisiblethings.org/about.html Through all her talks, writings, and interviews, it is clear she *really* understands computers, operating systems, and the software that runs on them. It is also clear that she has developed a greate deal of competency in the understanding of assembly language. Yet, the programs she releases are not written in assembly. One does not have to produce assembly applications in order for that 'machine-learning' knowledge to be valuable.

Hate to be pedantic, but actually, it *is* portable! As long as you stay on the same Arch anyway.

A couple more links on this subject:

http://webster.cs.ucr.edu/Articles/G...ate/index.html

http://members.save-net.com/jko@save...sm/opinion.htm

Thank-you for all the replies:

This is really encouraging and I cannot wait to begin to study this. I really felt, although I know nothing at this point about Assembly directly, that it would most likely be an important, valid, and a fundamental subject (often overlooked into today's programming industry).

I like to learn for the sake of learning, be it computers\ languages\networking, Philosophy, Human languages (I am semi-fluent in German and am slowly learning Spanish), History (especially WWII and Roman), and the sciences. Everything we learn while alive weaves together into the finest of tapestries, or at least it should\ can with effort and sweat.

Assembly does not seem to be only a fundamental aspect of Computer Science, just another "language" say-- it seems to be one of the bedrocks of Computer Science, therefore, if this is the case, it would seem imperative that one in this deeply techical field surveys the important areas and mines from the correct quarries.

The people on <DANIWEB> are great; I learn so much (I hope I am able to help others in areas too, although, at this point I learn more than I am able to teach).

Thank-you both for the encouragement. I will begin researching and studying Assembly soon and come directly to this forum when I have questions.

Regards,
Matty D.

Since it requires a 100% rewrite of assembly language programs to port from one platform (e.g. 80x88) to another (e.g. AIX Unix), assembly language, by definition, is unportable.

You can always run the code in an emulator like BOCHS, Hercules, QEMU, etc...

A modern x86 CPU can probably emulate a 15 year old mainframe faster than that mainframe ran originally.

That being said, ASM is still important today for anyone who wants code to actually perform well. When you've exhaused all HLL algorithmic optimizations, a bit of hand tuned ASM in the right place can still make a program dramatically faster. Comilers are good, but even the best of them can be beaten by a pro. This is particularly true on the quirky non-orthogonal x86 CPU's, and even more particularly true if the goal is to squeeze size rather than speed so something fits in an EPROM or ROM.

ex. What's the smallest way to clear 10 bytes of memory to zero on somthing 486DX or newer?

fldz
fbstp tenbytes

I've never seen a compiler clever enough to figure that one out ;->

Quoting myself here: "Hate to be pedantic, but actually, it *is* portable! As long as you stay on the same Arch anyway." -you can see that I was talking about portability on the same hardware.

What are the characteristics that allow a language to be portable? Packaging has a lot to do with it. If you write a Java program, it is cross-platform *only* to the extent that a Java run-time environment (VM, JIT-engine, etc.) is available on the target platform.

If we confine our discussion to x86 hardware, we have a few OSs to contend with (Windows, Linux, BSD, OS X, DOS, etc.), but we can see that we _do not_ need to alter any of our core application code when transitioning from one OS to the other. This is because it is the CPU which executes the Machine Language instructions -- not the Operating System. All that is needed is a library of wrapper functions (just like C and C++ have their libs which do the same thing) to isolate the calls to operating system services.

For example: One can write a program (as long as you restrict yourself to command-line "filter-type" programs and don't do GUI) in HLA [ http://www.artofasm.com ] using its standard library and the program will execute (without any change to the source code) on both Linux and Windows (other platforms in the future) {even on DOS with the right setup}.

>>If we confine our discussion to x86 hardware
claiming a program is portable makes no such restriction, and neither do I.


You are of course correct that 80x88 assembly is portable between os that reside on the 80x88 architechure. But that is not what I implied when I said that assembly is not portable. To be completely portable it would have to run on any archatechure with little more effort than recompiling or reassembling it. That is impossible with assembly. C language, for example, is portable as long as (1) the programmer sticks to ansii C standard functions and (2) there is a c compiler targeted for the platform.