Your opinion of Assembly:

[mattyd]

Hello:

I am a programmer. I work professionally primarily in C, C++. Most personal programming projects I do is in either C++ or Python. I am studying Java and Ruby currently.

My quetion is: How valid do you find Assembly language in a modern sense, professionally or otherwise?

I ask this for a specific reason. I have never studied Assembly; when I went to school for Software Engineering it was not required (as surprising as that may seem). My insticts tell me that I should at least on my own learn the basics of Assembly, code some build projects in it to get a feel for it, etc.

Would it be a wise idea to pursue this, studying and familiarizing myself with Assembly, or would it be a waste of time at this point considering that, at least in my line of work as a programmer, OOP and compilers do all of the lower-level work for me.

Very interested in your honest opinions and I will base my decision on this.

Thank-you in advance,
sharky_machine

[Ancient Dragon]

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.

[Evenbit]

I just run across this today:
http://discuss.joelonsoftware.com/default.asp?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.

[Evenbit]

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

[Evenbit]

A couple more links on this subject:

http://webster.cs.ucr.edu/Articles/GreatDebate/index.html

http://members.save-net.com/[e-mail]/asm/opinion.htm

[mattyd]

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.

[Ancient Dragon]

A Definition <of portability>

An application is portable across a class of environments to the degree that the effort required to transport and adapt it to a new environment in the class is less than the effort of redevelopment.

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.

[Purple Avenger]

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 ;->

[Evenbit]

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.

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}.

[Ancient Dragon]

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

Software developers often claim that the software they write is portable, meaning that little effort is needed to port it to a new environment. The amount of effort actually needed will depend on the extent to which the original environment (the source platform) differs from the new environment (the target platform),

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.

[Purple Avenger]

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.

C has issues a programmer needs to keep in mind if they want truly portable code that go well beyong the RTL.

The standard is full of the weasle words "implementation defined" and "behavior is undefined".

One of the biggest issues is non-crisp semantics for data types. That was something ADA took on directly and actually resolved in its spec. ADA semantics are dictated 100%. C punts quite often - you don't even know if a 'char' is going to be signed or unsigned by default in any given C implementation.

People who write genuinely portable code for a living get around most this with lots of synthetic types, extensive use of limits.h, sizeof() and a keen eye to where some snip of bit banging code might not be word endian neutral or word size neutral. The vast majority of C programmers in the world don't exhibit that kind of dicipline though.

[Infarction]

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

I believe Evenbit's argument arose from this phrase, which implies a focus on OS rather than hardware:

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.

[Ancient Dragon]

*nix often does not run on the same hardware as MS-Windows. For example we have a lot of linux systems that run on Sun workstations with RISK processors (I think they are RISK)

[howlingmadhowie]

*nix often does not run on the same hardware as MS-Windows. For example we have a lot of linux systems that run on Sun workstations with RISK processors (I think they are RISK)

the sparc architecture is a RISC architecture with pipelining. the pipelining leads to real problems trying to write assembler for it if you're used to the x86 type (which i am used to)

one of the problems is that the pipelining means that assembly for sparc systems knows what's going to happen before it happens. basically, the address of the next command is fetched before the current command is executed. so a jump like this:
a=3;
b=2
goto some_label;

would be in sparc assembly:
mov 3, register_for_a
jmp some_label
mov 2, register_for_b

because the address for the last instruction would already be in memory before the second instruction is executed.

wierd, huh? :)

[Infarction]

the sparc architecture is a RISC architecture with pipelining. the pipelining leads to real problems trying to write assembler for it if you're used to the x86 type (which i am used to)

You do realize that a Pentium 4 has something like 40 pipeline stages, don't you? Pipelining is one of the most basic ways to increase throughput on a processor, though it does add a good deal of complexity to the design.

[Infarction]

*nix often does not run on the same hardware as MS-Windows. For example we have a lot of linux systems that run on Sun workstations with RISK processors (I think they are RISK)

I think a more correct phrasing would be that Windows does not run on the same hardware as *nix... ;)

While the statement is true, you should also consider that Windows comes as a binary installer for x86, whereas Linux sources (which I'm most familiar with in the *nix family) have separate source codes for different architectures. For instance, here's the contents of the $(SOURCE)/include directory (where ./asm/ is a symbolic link to the local architecture):

include $ ls
acpi       asm-frv      asm-m68k       asm-s390     asm-v850    media   sound
asm        asm-generic  asm-m68knommu  asm-sh       asm-x86_64  mtd     video
asm-alpha  asm-h8300    asm-mips       asm-sh64     asm-xtensa  net
asm-arm    asm-i386     asm-parisc     asm-sparc    config      pcmcia
asm-arm26  asm-ia64     asm-ppc        asm-sparc64  linux       rxrpc
asm-cris   asm-m32r     asm-ppc64      asm-um       math-emu    scsi

You'll notice if you download an image of a linux installation (e.g. for a live CD) that you do have to choose the approriate image for your architecture.

[howlingmadhowie]

yep, i knew that theoretically, but practically, i've never taken it into account while coding. maybe that explains why my assembler programms are so slow. :)

[akyprian]

Hi,

After having developed software using HLL's for years, now I use Assembly Language for ALL my programming needs: small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop [IMG]http://www.codeproject.com/script/images/smiley_wink.gif[/IMG] and above all, I can do anything I want without facing any HLL limitations. You can give a look at this article: http://www.codeproject.com/useritems/assembleriseasy.asp

Regards,

Antonis Kyprianou

[Infarction]

I would bring into question your programming needs. Most HLLs will tradeoff optimal efficiency for greatly reduced development time or increased code readability. Furthermore, assembly will limit your program to a specific architecture and OS, whereas with Java for example, you can take your code (or your .class file) and run it anywhere with a JVM.

[akyprian]

My programs are intended to be used under Windows 32-bit or 16-bit DOS. Others target linux or other OS's, but yes, I don't develop cross platform applications. Other than that, I am able to develop small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop [IMG]http://www.codeproject.com/script/images/smiley_wink.gif[/IMG] and above all, I can do anything I want without facing any HLL limitations.

Code readability is another myth against Assembly. Microsoft Macro Assembler (MASM), for example, looks VERY similar to C code and is no harder to learn. I would say that it is easier.

Final point. Among others, I used VB (one of the easiest to learn and quickest to develop with languages) a lot before switching to Assembly and found no real problems to do so.

Regards,

Antonis

[Purple Avenger]

take your code (or your .class file) and run it anywhere with a JVM.

take your code (or your .class file) and run it SLOWLY anywhere with a JVM ;->

[world_weapon]

Alot of code that called the BIOS still works, so to that level you got some basic platform compatibility, but then you end up thowing in code to use anything at the full hardware capacity. Then you could always include an assembler coded compiler and have most of the code in whatever compiler input you need. There really is no need to make entire programs in assembly. I did once, it was really small, and all it did was use the BIOS to print HEX from AX BX CX DX DS and ES. But a friend edited it to work with C++. I dont really know C that well myself so I am prolly gonna check out that area more.

[akyprian]

There really is no need to make entire programs in assembly.

Speak for yourself! For me, there is no need to program in any other language.

Antonis

[world_weapon]

Speak for yourself! For me, there is no need to program in any other language.

Antonis

I guess you make a very good point indeed. I am actually pretty sure that if I had some good tools to take out the tedious stuff, and a library of procedures to simplify calls to whatever platform I target.

[jbennet]

im learning it at college and i hate it (although i do value its importance) - IMHO its great for speed/size critical things but for most applications it is not worth taking the time as Assembly is hard to maintain and could require many hundreds of lines to accomplish what 5 lines of a modern language could do.

[akyprian]

I guess you make a very good point indeed. I am actually pretty sure that if I had some good tools to take out the tedious stuff, and a library of procedures to simplify calls to whatever platform I target.

There are plenty of tools and libraries (most of which, if not all, are free) available.

...Assembly is hard to maintain and could require many hundreds of lines to accomplish what 5 lines of a modern language could do.

No hard at all. 32-bit windows MASM code, for example, looks almost like C (function declarations, modular design, if, else etc). Number of lines can still be equal to the lines of equivalent C code but this is not the point; How many characters on a line?

Antonis

[bootstrap]

What is my opinion of assembly language? Can you handle the truth?

I must say, assembly language is my favorite high-level language. Okay, arguably assembly language is actually a mid-level language, since it has close correspondence with much of the CPU hardware.

Assembly language is often the most satisfying way to program, and executes [much] faster - if you have even modest talent for ASM.

Why do I call assembly-language a mid-level language? Well, I designed several CPUs (and CPU-like controllers/devices), and can say from experience assembly-language is ~ the 3rd level language, above microcode which is above what I think of as "hardcode" or "directcode" (sorta spatial-programming vs temporal-programming).

An assembly language program is at just the perfect level to connect the "fixed" architecture and capabilities of the CPU hardware to the essential goals and requirements of my applications --- efficiently.

I need to multiply two 4-element f64 vectors by one 4x4 f64 matrix to transform the 3D coordinate of a point and its normal-vector into a new coordinate system in less than 40 nanoseconds - otherwise my simulation will not run at frame-rate. What do I do? Easy! I write inline SIMD/SSE2+ assembly language (with intelligent pre-fetches) and "job done", "works great", "piece of cake". Alternative? 120ns by the fastest, smartest SIMD-aware compiler I could find == 3x slower!

I write vision-system code to read every pixel from four 8-megapixel CCD chips at 10FPS (!!!at minimum!!!), save the images, inspect the images with software to find ~100 points on all four images that are "corresponding" (example: tip of index finger on right hand), and hand this information to robotics systems that react upon this "feedback". You want to program this in a high-level language? In 2026 maybe!!! Well I need to achieve this for a product that retails for $300~$600. To clarify what the above reduces to, each of the four CCDs outputs a 12-bit or 16-bit value every 10ns (at 10FPS = slowest feasible rate). And every pixel must be read, processed, stored - then all those image-processing processes must be performed on key parts of the image (which must be found/identified/isolated/correlated). Go do this with VisualBasic or Java or C# --- and your favorite "packages"!

These are 2 examples from my *recent* real-life work experience. But they are representative of many projects over many years. However, I cannot leave the impression that assembly language is good only when maximum speed is necessary. Perish the thought!

When I want collaborators on software projects - even ones without any serious need for blinding speed - who do I want to work with? Correct! I want programmers who love assembly-language! Why? Because ***vastly*** less often are they fools, suckers, talkers and self-promoting BS-artists than typical programmers/engineers/scientists. And I bet you know why - right? Because they prefer not to adopt the endless spew of popular fads that pollute all of modern life - most certainly including the monumental catastrophe the "modern" computer/software industry has become! Because assembly-language programmers usually care to understand "how things work" and feel *profoundly* uncomfortable "compounding the (unknown/invisible/hidden) errors/mistakes/disasters of others". These folks are not suckers for the totally-commonplace modern "ignorance = bliss" fantasy --- namely, "if you build your code on top of this [fancy/brilliant/superlative/state-of-the-art/super-dooper] language/library/controls/yadayadayada, you can slip into that warm fuzzy comfortable illusion that you can poke a few keys and click a few buttons and generate earth-shattering wonder-apps --- almost without effort. And most importantly, you need not do any difficult thinking or coding, and *especially* not understand how (or whether) the bulk of your program functions.

The fact is, though my programs usually contain more C code than assembly language, it is the assembly language that usually makes them great - and often makes them possible! As a [former] writer of compilers, code-generators and optimizers, you might think I should blush to admit that even the best super-duper-optimized wonder compiler runs 2x to 20x slower than the assembly language code my brain concocts.* Yes, this is usually because extensive thinking about how to write the crucial sections in assembly language leads me to concoct unconventional ways to configure, structure or orchestrate those parts of the program/problem that no compiler would or could ever "dream of". But hey, I am also happy to admit that if the crucial parts and inner-loops of an application is utterly, thoroughly and inherently matched to the structure of normal compiler output, then the compiler code will only take 1.3x ~ 2.0x as long to execute. The only problem is - I can't think of one case where this happened! Maybe I am just so horribly unlucky that I get only difficult problems (as in "interesting", "fascinating", "cool"). Who knows, that might be it? Willing to risk your career (or life) on it?

Frankly, the best part of assembly language is what I implied at first. Maybe programming and thinking-in assembly language will save a few minds from the mire, muck and lameness-sameness of the endless stream of fads, dreams, special-effects and mental sleeping pills. This assures assembly language will be more-and-more ignored by the US "education" system. Unfortunately, it is too obvious that few high-level language programmers ever emerge from the fad-and-PR-induced daze (and brain-damage?) to ask themselves this nasty question, "if all these super-languages and super-tools are the 'ultimate answers' they claim and achieve such 'infinite speed/quality/reliability/wonders', then why am I told I need never-ending-sets-of-super-whoopies every year (or month)?".

The dirty secret is (which is only a secret because those who know get tired of being laughed-at and spit-upon by crafty-or-mindless hordes of fad promoters-and-mindless-apologists), that I can write every last bit of my entire application without one single bit of supposed "help" from OPC (other peoples code). Even the OS is one big pain in the butt in many applications/devices and is better ejected than incorporated. Faced with large, impressive [often one-person] [nearly] self-contained projects/products written largely-to-100% in assembly-language, the hordes of mindless programmers (and talkers) simply ignore it, move on, and remain quiet (for once!). Which leaves the best gold mines in the hands of honest, straightforward, simpleminded "know-it-alls" --- who are usually happy to keep their traps shut and avoid ridicule.

Which reminds me (finally coming to my senses), which button must I click to delete this message? Definitely better that I not post it.

* I do not blush because I am a 100% pure unapologetic "honest simpleton" who always prefers to see/understand/convey the simple direct honest truth no matter what other consequences that implies.

** Fortunately, a few (mostly assembly-language or low-level C) code libraries do exist that are basically sensible and fairly reliable - and available in source code if you are smart enough to develop in Linux!
Just in case we need to see/learn/trace how various sections work.