I have been lately relearning 8086 assembly, ( because i have books in it). My last touch with it was 1997..and the interesting code i was playing around was the brainVirus, which involved bootsector and FAT stuff. Then after that, I went to MFC windows programming, and GUIs..i thought, I wont return to asm...but here I am...So the stuff that made me back in asm is becuase I am learning this .NET IL which looks like assembly language...so it seems asm is always at the forefront when something new comes...With fast CPUS even in embedded RTOS, where do you guys think machine asm will find itself still useful and in-demand? For example, C language converts to asm rate...so that would mean,I should stop at the level of C...but then, again due to the IL, I find renewed interest to machine asm...hope to hear any comments out there...thanks.
Posted on 2007-08-25 01:49:10 by truthADjuster
That is a discussion that has caused serious amounts of flame wars :P

Is assembly language, as in machine language, still useful? Of course. Embedded systems, Driver development and Operating System development are prime examples. You can't escape the need for assembly language since there are things that more generic (high-level) languages cannot handle. There are also situations where you need hand-cranked code; An intense processing/graphics loop is a good example. C compilers generate pretty good code these days and it is hard to beat the shorter development cycle of high-level languages unless you live/eat/breathe/think assembly language... even then... you have such design differences in processors, even of the same family, that optimized ASM code for one processor is not-so-optimal for another.

Microsoft's intermediate assembly language is indeed an assembly language, but nothing new or spectacular. It is not a machine language, however, as it is actually an abstracted (i.e. hypothetical) virtual machine. Java has been doing the same thing for years as well. Computer speeds these days are usually good enough to get away with interpreted and/or JIT'ed code. That is what Microsoft's IL and Java Bytecode offer you. Unless the idea of directly writing IL entertains you, I would stay away from trying to actually develop apps in it... it is most efficient as a target of the C# language.

Perhaps one day someone will make a CPU compatible with Microsoft IL or Sun Bytecode and break the virtual machine barrier... but I doubt it.

You need to find an enjoyable and/or realistic development method that best fits you.
Posted on 2007-08-25 02:14:09 by SpooK

Perhaps one day someone will make a CPU compatible with Microsoft IL or Sun Bytecode and break the virtual machine barrier... but I doubt it.

ARM done something like that for Java
http://www.arm.com/products/CPUs/ARM1026EJS.html
Posted on 2007-08-25 02:54:13 by Dite

Perhaps one day someone will make a CPU compatible with Microsoft IL or Sun Bytecode and break the virtual machine barrier... but I doubt it.


CPU for MSIL?
I wouldn't even consider it - the binary opcode for floating-point add is exactly the same as some of the integer adds. The JIT engine uses the data type from the preceding load instructions.
Posted on 2007-08-27 00:45:00 by tenkey
SpooK: I'd actually say that driver development is one of the areas where assembly is pretty irrelevant; most stuff is done with IN/OUT, DMA, and memory-mapped I/O, which are all easily accessible without going to assembly level (even if you don't have intrinsics for IN/OUT and they end up calling functions, it's irrelevant since those instructions are so abysmally slow that call+ret overhead is unnoticable).

This topic is something that usually degenerates into flamewars, let's try and avoid that... in most of the professional programming world, assembly is irrelevant and not something you're going to be hired on; after all, the world at large loves scripting languages, web development, and quick RAD tools to do database frontends.

Unless you're lucky to find a niche job, you probably won't be doing OS kernel work at a professional level. And even in OS kernels, the amount of assembly code is pretty small these days (whether that's a good thing or not is a question that degenerates into flames way too fast, let's not go there). There are situations where it's absolutely necessary though, for instance I will be getting my hands dirty with HyperVisor development using Intel's VMX instruction set... no way to avoid assembly there :)

For graphics and sound work, there's a lot of good chances for assembly optimization. Most compilers these days have so-called "intrinsic support" for MMX/SSE instruction sets, meaning that you don't have to drop to inline or external assembly, but use functions that translate almost 1:1 to the machine instructions, with the benefit of register allocation. Last time I looked (3+ years ago?), however, the MMX register allocation and spilling in ms and intel compilers wasn't too good.

I prefer not using intrinsics or inline assembly anyway, since using an external assembler means you don't lock yourself to only one C/C++ compiler.

Lot of graphics processing is moving away from the CPU, though, and being done on your GPU, which is designed for massive parallelism and has an instruction set that's more appropriate for graphics stuff than an x86 CPU... and with the latest generation of graphics cards, it becomes very interesting.

As for MSIL, ho hum. I don't see much reason to program directly at that level, you will be going through a JITter anyway, and I doubt how much performance you could gain over using C# or whatever... but there's a few cases where doing MSIL code could be interesting, like what Charles Petzold does in beautiful code... his c# image filter was too slow, but instead of writing a native function in C or Assembly, he emits MSIL code on-the-fly.

People are saying that assembly is dying (well, actually they're saying it's dead) and that C/C++ is quickly dying as well, but I daresay they're wrong; there will be venues for native code for many years to come, because no matter how fast processors become, our desire for speed is insatiable.

In some areas, anyway - there's no good reasons to write things like word and excel entirely in assembly.
Posted on 2007-08-27 05:21:58 by f0dder
In fact, I can't imagine a os developer who do not know assembly.
And one more thing that I realize that acutually the programming is dying. Please tell me what is the most diffucult computing problem a web developer can encounter ? I'm 100 percent sure most of web developers can't even sort a buch of numbers without using "sort_my_numbers(....)" function :)

Maybe we shouldn't expect briliant programming trick from new offsprings...
Posted on 2007-08-27 07:08:53 by Dite