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

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