That's how I feel whenever a new OS or API comes out these days (or years).

Back when your typical PC came with a whopping 128 K of RAM (and an optional 10 Meg hard drive), the programmer had all the information he needed. We had the BIOS interrupts and the DOS interrupts, all (well most) documented. It was not unusual for us to control the hardware directly (e.g., writing to video memory bypassing BIOS, and certainly bypassing DOS).

All the information an assembly language programmer needed was readily available, including numerous books on how to use assembly language.

When DESQview came out, its API was first documented in assembly language. The C API came out only later.

Alas, tempora mutantur! When Windows with its 95 version became a must have for a programmer, it was absolutely impossible to find any information on how to program for it in assembly language. It was as if assembly language did not exist. Or, perhaps, as if Microsoft did not want you to know. They stopped upgrading MASM at the same time.

All books about assembly language suddenly seemed to be out of print. Then Microsoft starting pushing C++ and Visual Basic. The whole system got so complex that even after years of Windows programming, I still have to consult my programming reference. It is just not possible to remember it all.

Worst thing was that I felt forced to program in C. Don't get me wrong. I think C is a great language. I use it a lot (especially under Unix). I just don't like for someone in Redmond to decide for me what language to use. But it appeared assembly language was unusable for Windows.

Now, of course, anything that can be done on a computer can be done in assembly language. But there was no information about how to link an ASM program for Windows. The best I could do was write a WinMain() in C, and the rest in ASM.

Then, one day, I downloaded a program from the web. A Windows program written in 100% pure unadulterated assembly language.

Wow!

How did you do that? I emailed the author. He kindly sent me some source code that showed me how to program for Windows in assembly language. I immediately started a geocities page on Windows assembly language programming (it's still there if you're curious: http://www.geocities.com/whizkidplus/). I posted some code, and then some more.

Soon, similar sites started popping up all over the web. I'm glad to see the renewed interest in assembly language programming, especially among young programmers.

Windows software tends to be bloated: It is slow and requires tons of memory. That is completely unnecessary. Rewriting it in assembly language speeds it up at least hundrefolds. And lowers the memory requirements considerably (for an example of some small but powerful and fast ASM software see http://www.redprince.net/atelier/).

So, yes, folks. Give me assembly language, or give me death!


Lethal: You're missing the point. I am not saying everyone should only program in assembly language. I am saying the information on how to do it should be released by companies like Microsoft. It's about choice. As for making life easier: I find it equally as easy to program in assembly language as in C. But the user of my software has his life easier if my software does not require tons of memory and runs fast. Incidentally, I use OOP in assembly language. I always pass the this pointer in ECX, so I can start each procedure with a jecxz to avoid null pointers.

Makes me wonder if assembly programmers have refrigerators or if they still have the ice man deliver a block of ice for their icebox. Do you have a CD player or still insist on 72 RPM vinyls? Did you ever get one of those new fangled transistor radios, or does yours still run on tubes?

The point I am trying to make is that these purist assembly language programmers sound like a bunch of old fogeys. They all have the same stupid story: "When I was your age, we didn't have any new fangled, fancy smancy OOP programming languages. We all had 8086s with 128K memory, and we coded our programs in assembly language, and I didn't hear anyone complaining! You had a hard drive if you were lucky!" It's like heaven forbid that programming should be made easier, life made more convenient.

It's true that assembly language can be useful. It can make certain operations faster, through the use of optimization techniques. It can make your code smaller and faster, but the disadvantages of using assembly often outweigh the merits.

Assembly is good for two things. The first is for when you need to access hardware. Writing routines to interact with the hardware can be easier and cleaner than the equivalent operation in C. It is not difficult to export the assembly routines to make them callable from C or some other language, so you can get the advantage of having precise control over the hardware without having to write your entire program in assembly.

The other thing assembly is good for is optimizing certain parts of a program. If you have an extremely time critical routine that is called a lot, then it makes sense to go through it with a fine toothed comb and choke every possible cycle out of it. You have to look at the speed gain and compare it to the time you spent optimizing the code. If you spent three hours optimizing a routine, and you only get a 2 microsecond speed gain, then you have to call that routine billions of times to make it worthwhile. In most cases, its simply not worth the effort. Embedded applications and DSP are areas where hand optimization might make a significant difference, but unless you doing some extreme number crunching on a PC, its probably not worth it.

Assembly is hard. You can't glance at the code and know what its doing. It's not at all self documenting, its not portable, and its difficult to maintain. Its also easier to make mistakes in assembly, and harder to fix them. I'm willing to bet that the time spent writing a routine in assembly will be much greater than the time spent writing the equivalent in C.

I was going to argue about the ugliness of the x86 memory models, but Whizkid points out that code for Windows 95 can run in protected mode, so the memory model is flat and writing assembly becomes not much worse than writing for a RISC machine. The instruction set is just more complicated.

Whizkid seems to suggest writing entire programs in assembly, and complains about the bloated slowness of Windows libraries. It's true that any Visual Basic program has a load of runtime stuff following it around, including the OLE libraries. A C++ program will usually use MFC, which is difficult to use and has its own bloated runtime libraries pulling things to a crawl. A C program will use the Win32 API directly, but so will any assembly program that doesn't want to draw it's own interface. So either way you go, you only gain from using assembly in hard core number crunching routines that get used a lot. Even in assembly, you have to rely on the API to provide an interface, unless you want to write you own interface library in assembly. If the only thing your doing is calling the API, you don't get the advantages of using assembly, but you get all of the disadvantages. When you write something in assembly that just calls a lot of API functions, you get to waste your time setting up the stack. So instead of one line of C code, you write 10 lines of assembly, just to call a function. That's just silly.

Bloat doesn't have to come from libraries either. You can just as easily write big, slow, inelegant code in assembly as you can in C or any other language. Part of writing good code is knowing how to use your tools and libraries correctly, and in the application of good, solid design. Sitting down and coding with a vague goal in mind but no solid design will give you slow and ugly code, no matter what language you're using.

It comes down to having the right tool for the job. If you can hand optimize a routine better than a modern C or C++ compiler can, then use assembly and build a library that can be called from another program. If you want to write a device driver, use assembly if you want, but C is about as good and easier to maintain. If you're writing GUI that relies on a library like GTK+ or the Windows API, then your better off in C or C++ or whatever your favorite language is. It just doesn't make sense to do everything in assembly. If I write a binary tree library in assembly on an x86, but then I go and buy a Sun or something, I have to waste enormous amounts of time converting it. I could write it in C or C++ and just recompile.

Whizkid says he just wants to see information about how to do it from companies like Microsoft. Well, if you have the C prototypes for a library, you can figure out what you need to put on the stack to call it from assembly. It doesn't make sense for Microsoft to put any effort into releasing assembly specific information. They have development customers who are usually companies who don't have time to use assembly. They want fast development time, not fast code, so that's what Microsoft tries to give them. Corporations using Microsoft tools like Visual Basic are usually writing business applications for in house use that basically consist of storing things in a database and then generating reports on them. So that's the customer that Microsoft caters to, resulting in things like ADO. Hard core computer science where assembly might be used comes into play in other problems, and the people solving those problems look to academia for information, not to Microsoft.

I think part of Whizkid's argument for assembly rests on the "coolness" factor. Doing something just to see if it can be done. That sort of thing. Sure, I do things like that too, but it won't fly in industry.

Back in the day, a programmer knew everything he needed to know. Now, there's so much information that you have to keep refering to your reference manuals just to get through a simple project. Maybe so, but the libaries and OS's of today give the programmer so much more. You can accomplish a lot more by making a few libary or system calls now than you could then. You don't have to write your own routines to handle input and output any more. Instead of wasting time with that, you can solve the problem you want to solve. Time spent looking up a library call is nothing compared to writing the function yourself.

Give me assembly or give me death? No, give me the right tool to get the job done.

As one of old fogeys Lethal refers to, I can tell a little about the environment you had approximately 25 years ago.
Mainframe computers had something like four megs of memory - everything else had memory measured in kilobytes. They were still doing time-sharing, batch processing and sometimes even real time processing at the same time. There were also things you would now call embedded systems - Nuclear Dynamics offered data sampling devices driven by a DEC PDP-11. Due to the lack of resources and the time constraints, those were often programmed in assembler for (mostly) sheer lack of space.
Still - anything bigger was mostly programmed in the high-level languages of that time. FORTRAN and COBOL were very much in use, so was PL/I.
When would you use Assembler ? (Mind you - well-documented at that time...)
Answer: When you had to. When you did something that could not be done i.e. in FORTRAN. Operating system calls are one example, device access another one. Maybe - but rarely - the most time-consuming computing loop inside a program, but it needed a skillful assembler programmer to really be faster than a good compiler.
The difference to today was that almost everybody capable of programming would know a couple of assemblers, but would use assembler as a last resort only.

What - you may ask - did they use to write operating systems ?

Three kinds of languages were used. Assembler for the kernel (same with Linux). High-level stuff in high-level languages (the IBM FORTRAN IV compiler was written in FORTRAN IV with some Assembler subroutines). Plus - the layers next to the kernel were written in something called a medium-level language. Such beasts existed for almost every platform - there was PL/M for 8080 and Z-80 systems, NPL was the language of choice if you worked on Norsk Data machines. IBM had their medium level language (the name escapes me) and Siemens would use SPL.
Those languages would hide assembler in something a little more complex than just macros - you would have varible declarations, control structures and other stuff to make life more comfortable and your code more readable. Still - the output would be Assembler. Those beasts made the use of "pure" Assembler more or less useless, which means that you would have one routine in Assembler versus about 20 in NPL - if they weren't put in inline code.

IBM wrote their OS for a machine with 8 kilobytes of memory at first. Using Assembler, as there was nothing else. This OS turned into a nightmare to maintain. Program changes (patches) were sent to customers as lists of binary address/new value lists. Imagine getting a patch for your fave operating system containing of 20 pages of "In file foo, change location 2837FE23 from 2E to 7A". (Okay - this stuff was common well into the 80s...)

Every serious programmer should still know Assembler, but be wise enough to know when and when not to use it.

Log in or register to write something here or to contact authors.