Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is Assembly Programming Still Relevant, Today?

Cliff posted more than 7 years ago | from the mov-eax,1 dept.

676

intelinsight asks: "Consider the following question given the current software development needs, and also the claims of the Assembly lovers for it being a language that gives one insights of the internal working of a computer. How relevant or useful is it to learn Assembly programming language in the current era? "

cancel ×

676 comments

Sorry! There are no comments related to the filter you selected.

All's quiet (1)

Longbow (28366) | more than 7 years ago | (#18451669)

....... (sounds of crickets) ........

Re:All's quiet (5, Funny)

Tackhead (54550) | more than 7 years ago | (#18451935)

> ....... (sounds of crickets) ........

Give me a moment. I've still gotta figure out the six nested timing loops I need to toggle the speaker cone in and out in such a way that it sounds like a cricket instead of a bird.

Re:All's quiet (5, Interesting)

Qwertie (797303) | more than 7 years ago | (#18452259)

Here are a few reasons you might need proficiency in assembly language:

  • You're writing software for a low-speed or low-memory chip for an embedded system (e.g. one of the PIC chips). Such chips are used either because they are cheap or because they need very little power. You can often program these chips in some variant of C, but if you need that last drop of performance, you use assembly.
  • You're writing a compiler. In this case you may not have to write assembly directly, but you'll have to understand it intimately in order to convert source code to machine language. (Replace "assembly" with "bytecode" or "IL", if making a Java or .NET compiler)
  • You are reverse-engineering closed-source software (another case where you must comprehend assembly)
  • You're designing or testing a computer chip, in which case you may have all sorts of tests cases written in assembly language.
  • You're maintaining an old "legacy" system that uses assembly.
  • You're writing an emulator for another computer, and you need high performance. In this case you may need to understand the assembly language of both the real and emulated machines, as I learned when I wrote a Super Nintendo emulator.
  • Those bastards make you study it in one of your college courses.

Re:All's quiet (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18452421)

  • Vertex Shader
  • Pixel Shader

6502 Programming (-1)

Anonymous Coward | more than 7 years ago | (#18452263)

A program written in assembly language on a Commodore 64 is faster than an algorithmically identical program written in BASIC on a MIPS4000-based SGI machine.

Yes. (3, Insightful)

bladx (816461) | more than 7 years ago | (#18451677)

It's good to know how things work underneath the hood.

Re:Yes. (2, Insightful)

fm6 (162816) | more than 7 years ago | (#18452069)

Looking at assembly code tells you very little about how modern software systems work. Any more than sheet metal fabrication tells you how an airplane works. Ever hear the expression "can't see the forest for the trees?" With assembly language, you're focusing on the individual leaves!

Re:Yes. (1)

bladx (816461) | more than 7 years ago | (#18452089)

Actually it helped me understand more about what was going on from a programming perspective. From a building block perspective, I think it's still relevant. It's not that you yourself are going to be programming in assembly when you can have a compiler break down a higher language program into assembly automatically. But the point is, for myself at least, it gives a deeper/basic look into what goes in between software and hardware.

Re:Yes. (5, Interesting)

A nonymous Coward (7548) | more than 7 years ago | (#18452407)

I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.

(For the ignorant, it takes two string pointers and copies the second one to the end of the first one; this requires zipping all the way from the start to the end of the first string to find where said end is. It then helpfully returns the pointer to the beginning of the first string, the very parameter you passed in. Never mind that the new end of the first string would be very handy for the next strcat to that same string.)

This programmer is generally good at what he does, but the idea that strcat is woefully inefficient is not obvious to him. Even after explaining it to him, yes he will avoid it, but he does not really understand why. He, and far too many other programmers, measure their program's "speed" in lines of code. Sure, they know that a subroutine call has to count those subroutine lines of codes as well, but they simply have no concept of the fact that some operations take longer than others, that there are better ways of doing simple things.

I think every beginning programmer should have to spend a semester on some funky old z80, for instance, all in assembler, debugging in machine language, before they can call themselves a good programmer. The idea is not to get them skilled in z80s, but to give them a basic idea of how computers work.

It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.

Re:Yes. (1)

SpaghettiCoder (1073236) | more than 7 years ago | (#18452671)

I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.

(For the ignorant, it takes two string pointers and copies the second one to the end of the first one; this requires zipping all the way from the start to the end of the first string to find where said end is. It then helpfully returns the pointer to the beginning of the first string, the very parameter you passed in. Never mind that the new end of the first string would be very handy for the next strcat to that same string.)

This programmer is generally good at what he does, but the idea that strcat is woefully inefficient is not obvious to him. Even after explaining it to him, yes he will avoid it, but he does not really understand why. He, and far too many other programmers, measure their program's "speed" in lines of code. Sure, they know that a subroutine call has to count those subroutine lines of codes as well, but they simply have no concept of the fact that some operations take longer than others, that there are better ways of doing simple things.

I think every beginning programmer should have to spend a semester on some funky old z80, for instance, all in assembler, debugging in machine language, before they can call themselves a good programmer. The idea is not to get them skilled in z80s, but to give them a basic idea of how computers work.

It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.
Do you believe programmers should know big-O notation?

Re:Yes. (4, Insightful)

Lehk228 (705449) | more than 7 years ago | (#18452683)

i agree that everyone should have decent understanding of what's going on behind the curtain, though rather than focus on the what, i would prefer to see more experience with limited environments.

as in your example, too many people code like the only platform is the multi-GHz PC.


even a year doing tools in Graphing calculator basic will teach appreciation for not wasting cycles doing everything the lazy way, 'cause sure, you usiung strcat doesn't slow the system in a noticable way, but when half the processes running are using it, and using it in "hotspots" suddenly you need a new machine because it's just not fast enough.

Isn't it the root of all programming languages?? (4, Insightful)

madhatter256 (443326) | more than 7 years ago | (#18451689)

Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?

Unless your compiler emits C (2, Interesting)

tepples (727027) | more than 7 years ago | (#18451875)

Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
In theory, you could just make your higher-level programming language's compiler emit C or C-- [cminusminus.org] and then let the maintainers of GCC and other mid-level language compilers do the dirty work for you.

Re:Unless your compiler emits C (2, Informative)

Surt (22457) | more than 7 years ago | (#18452205)

A lot of languages these days are emitting java .class (binary) and letting the VM do the work.

Re:Unless your compiler emits C (1)

jc42 (318812) | more than 7 years ago | (#18452623)

So who's to implement the VM for the next generation of CPUs? Or will we find that new CPUs can't be developed, because there's nobody left to write the lowest level VM interpreters?

Of course, if the AI people could just get their act together, we could handle the job over to the machines. But like 30 years ago, that's 5 to 10 years in the future.

Re:Isn't it the root of all programming languages? (5, Insightful)

KokorHekkus (986906) | more than 7 years ago | (#18451999)

Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
To create - yes. To use as a programmer - no. You can still be a good programmer if you know the cost (in terms of resources) for the operations you choose to make use of. A higher level language will most likely give you a wider range of ways to solve a problem within the given limitations. But only if you actually know the computational characteristics of the system (as a whole) that you are using. Simply put you need to realise which operations are expensive and which are cheap from a total perspective.

Re:Isn't it the root of all programming languages? (1)

Nasarius (593729) | more than 7 years ago | (#18452077)

Exactly. You don't need to be fluent in x86 assembly, but if you're completely ignorant of the inner workings of computer architecture, you're at a disadvantage to those who have been exposed to it and written, say, a bit of old MIPS assembly code.

Re:Isn't it the root of all programming languages? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18452557)

I thought Evil was the root of all programming languages? Wait, no, that's Microsoft. No, wait, Microsoft is the root of Evil.. Money... eh, forget about it.

Re:Isn't it the root of all programming languages? (0)

Anonymous Coward | more than 7 years ago | (#18452685)

I like to think about it as the root of a series of primes multiplied together, none of 'em can be removed easily!

You should not learn it.. (5, Insightful)

QuantumG (50515) | more than 7 years ago | (#18451701)

Please remain ignorant of all lowlevel details of your deployment and development platforms.
Please continue to treat both computers and the tools you use to program as magic black boxes.
That way old dogs like me will still have a job.

Re:You should not learn it.. (3, Insightful)

LionKimbro (200000) | more than 7 years ago | (#18452107)

Yes; Understand too, how the gates work, all the details of how the chips work, (the myriad chips your program may run on,) and have a good understanding of quantum mechanics, as well. Understand all the business supply chains, as well.

Anything else, is just-- pshaw... Black boxing it.

Re:You should not learn it.. (5, Insightful)

MenTaLguY (5483) | more than 7 years ago | (#18452411)

Um, I know you were being facetious, but that's not a bad idea at all, actually. A comprehensive knowledge of those fields isn't normally worth it for most things, but basic literacy in all the areas you mention is actually very helpful at times.

Re:You should not learn it.. (0)

Anonymous Coward | more than 7 years ago | (#18452475)

How is someone going to learn assembly? I can't imagine having to learn it without getting the use the equivalent of DEBUG which AFAIK doesn't exist for a 32 bit protected mode environment. GDB is nothing compared to DEBUG for assembly :/

I suppose someone can run vmware with drdos or something but why force someone to learn segments and rules that applied to registers that don't matter anymore?

Assembly _programming_? (1)

ResidntGeek (772730) | more than 7 years ago | (#18451707)

Learning assembly programming is not terribly useful. Learning assembly language, however, is very useful. Reverse-engineering and debugging both make use of disassembly, and especially in vulnerability analysis, exploit writing, compiler writing, and similar fields, knowledge of assembly language is often critical. Assembly programming is only useful for optimizing short bits of functions, and it's my understanding that it doesn't help much or often.

Re:Assembly _programming_? (4, Insightful)

dgatwood (11270) | more than 7 years ago | (#18452003)

That's a pretty fine line there. If you can understand asm well enough to debug such issues, I would argue that you also probably know enough to write it, or at least very nearly so.

I would say that you need to know how to program in assembly language, though it doesn't really matter much which ISA you use---MIPS, x86, PPC, ARM, whatever. What matters is the ability to understand what's really happening at a low level so that you don't do stupid things in high level code that cause your machine to have a seizure.

For example, once you understand that your CPU only has a limited number of registers, you'll understand why (on some CPU architectures) it is a good idea to limit the number of function arguments so that they can be passed via registers, and that you should put the arguments that you are most likely to use at the beginning of your prototype so that they have the best chance of already being in a register.

Re:Assembly _programming_? (1)

ResidntGeek (772730) | more than 7 years ago | (#18452281)

I've found that there tends to be quite a bit of difference between disassembled code and written assembly. Assemblers provide lots of features like labels and subroutine names that aren't found in disassembled code. Not only that, but you usually only have to be able to read disassembled code, which is generally easier than writing it.

I like that example at the end, by the way. Very neatly sums up the good things about understanding low-level function.

How to get started? (1)

WillDraven (760005) | more than 7 years ago | (#18452015)

Having read the replies so far, I've decided I'd like to get my hands dirty and start learning assembly. Can anybody reccomend any good books / websites / (cheap) courses to take / etc.?

Re:How to get started? (2, Interesting)

oaklybonn (600250) | more than 7 years ago | (#18452197)

The best way is gcc --save-temps; write your c code and then understand what gets generated and how it differs depending on what you write in a language you're already familiar with.

I spent 6 months recently working for a company that programmed mainly in C++ and visual basic (I'm a mac programmer, so I was a fish out of water there, which is ultimately why I left...) But the developers there didn't / couldn't / wouldn't understand assembler in any way shape or form. Without the high level debugger, they were lost. So when their app would crash, they'd be helpless to understand how.

I was appalled. I've spent 20 years debugging crashes and even though I don't speak x86 fluently, I can at least find my way around it. How do people that aren't able to read assembler ever able to ship quality products?

Of course, the best way to learn it is using an interactive assembler: go back in time to 1998 and use TMON Pro with MPW. With an 11 minute link time, you'll quickly learn that its easier to patch your bugs in assembler and continue execution, or write a little subroutine in "playmem" to do something, rather than terminate your app, make a small change, and relink.

God I miss TMON.

Re:How to get started? (5, Informative)

p7 (245321) | more than 7 years ago | (#18452301)

Try the "Art of Assembly Language Programming" available free at this website http://webster.cs.ucr.edu/AoA/index.html [ucr.edu] it should get you started.

Re:How to get started? (0)

Anonymous Coward | more than 7 years ago | (#18452489)

Art of Assembly Language by Randall Hyde, it's a very thorough introduction. http://webster.cs.ucr.edu/AoA/index.html [ucr.edu]

I read through the first 7 chapters of the 16-bit version just to get a feel for what sort of operations a CPU actually do when a program runs, it was very easy to read and understand. That was a while ago, I've not tried hard to advance to writing Win32 programs in assembly, because from what I could gather from brief scanning through Win32 ASM tutorials it is a right PITA to even get 'Hello World' to work in a window. There are example code to cut&paste in the tutes of course, but understanding *why* the code does what is quite involved, and without understanding there is no point doing anything in ASM.

easy as 1 2 3 (4, Funny)

zeromusmog (260817) | more than 7 years ago | (#18451709)

Nobody has to learn assembly language anymore to create piddly things like compilers or program ultra-small devices or anything like that. You can do all of those things with Ruby on Rails now.

Re:easy as 1 2 3 (1)

ResidntGeek (772730) | more than 7 years ago | (#18452009)

You laugh, but there are microcontrollers programmed in BASIC now. Sounds nice on the surface, lets kids get into programming and home users more easily create electronic devices, right? Unfortunately, the intro to electrical engineering course at Duke University trains kids in their use. The future of electrical engineering in America is people who program microcontrollers in BASIC. Isn't that a nice thought?

Re:easy as 1 2 3 (1)

TheDreadSlashdotterD (966361) | more than 7 years ago | (#18452667)

The future of electrical engineering in America is people who program microcontrollers in BASIC. Isn't that a nice thought?


I know what you want the reader to say, but could you just quit begging the question and say no?

Re:easy as 1 2 3 (0)

Anonymous Coward | more than 7 years ago | (#18452065)

uhh wrong. those of use doing kernel programming still need assembly. sure your web gui junk doesn't need it, but those of us who work on the OS running your junklet can't ignore it.

Depends on what you want or need to do ... (1)

taniwha (70410) | more than 7 years ago | (#18451713)

Making an accounting system why would you care?

On the other hand I find myself needing to break into assembly once or twice a month - but I do embedded systems of one type or another

For most programmers, no. (5, Insightful)

CosmeticLobotamy (155360) | more than 7 years ago | (#18451723)

For good programmers, yes.

Re:For most programmers, no. (1)

leerpm (570963) | more than 7 years ago | (#18452581)

And believe it or not, there are major banks out there that still run mission critical software written in assembly.

Re:For most programmers, no. (1)

konstant (63560) | more than 7 years ago | (#18452663)

Even for good programmers, it's not always clear cut. Sometimes you see slices of assembly in otherwise wholly C-based systems that are elegant and an order of magnitude more efficient than C, but drastically harder to maintain when the original author "moves on". Occasionally the local performance gain is swamped by the global performance profile, too.

Look at FFMpeg (1)

Dwedit (232252) | more than 7 years ago | (#18451741)

Yes. Even today, the popular libavcodec library (often seen in Codec-Packs) still has plenty of ASM code poured into it to make it faster.

ASM code is also especially important if you are programming for a more limited platform, such as a GBA or Nintendo DS. ASM code can often be four times the speed of C code.

Re:Look at FFMpeg (1)

corvair2k1 (658439) | more than 7 years ago | (#18452327)

What you mention is spot on, but there's a specific reason that it's faster to do this. With the various multimedia ISA extensions, which are typically instructions designed to work with small vectors of 3-4 elements, nice speedups can be obtained... However, this functionality is not exposed in high-level programming languages, and it's usually not going to be generated by a compiler, either.

Also, look at linear algebra libraries. They also use these short-vector instructions deep within the kernels. The percentage of assembly language is very small, but those kernels are executed a lot, so the speedup over ignoring these instructions is significant.

Why bother? Just ... (3, Funny)

Bin_jammin (684517) | more than 7 years ago | (#18451753)

Hire someone else to code in assembly.

Yes (0)

Anonymous Coward | more than 7 years ago | (#18451755)

Yes, it is.

security (0)

Anonymous Coward | more than 7 years ago | (#18451757)

Reverse engineering malware.

Yes (5, Informative)

Erich (151) | more than 7 years ago | (#18451779)

If you're good.

If you know DSP, are adept with fixed point arithmetic, know a bunch of fun tricks [hackersdelight.org] , can schedule well... there are many people who would like to hire you. Including the group I work in.

Simply, compilers cannot produce code of the same quality that great hand coders can produce code, especially for complex embedded devices like DSPs. But it's not enough to know how to write assembly, you need to know all the tricks the compiler knows, all the tricks you can play with the algorithm, and all the ways in which you can tinker with the code to fit it nicely into the architecture.

Those things are still highly valueable; people need to get really optimized code for their media players. If you can squeeze 20% out of your MP3 decoder, you can get 20% lower energy usage on your programmable logic.

Re:Yes (1)

jonatha (204526) | more than 7 years ago | (#18451987)

there are many people who would like to hire you. Including the group I work in.

So when do I start?

Absolutely (0)

Anonymous Coward | more than 7 years ago | (#18451793)

Sometimes you just need to look at what the fuck the compiler did to your poor code. Or debug libraries to which you don't have the sources. Or do embedded. Or something.

Honestly... (2, Insightful)

CyberBill (526285) | more than 7 years ago | (#18451801)

You really only need to know how to program assembly if you want to be a good programmer. If you want to be a crappy one, learn Java or C#, pretend pointers are magical, and be happy with your life. (I'm not saying those are bad languages, I'm just saying they're opposite from assembly)

Also, a lot of embedded work is still done in assembly because with a lot of low-level industrial work having very precise clock-counts on everything is very important.

Re:Honestly... (1)

ralphdaugherty (225648) | more than 7 years ago | (#18452603)

I spent the 80's as an 8086 programmer. To throw in an obervation, the same code can be written in other languages with pointers doing exactly the same thing. It's more that of people learning what can be done with bit manipulation and pointers, for example, rather than the actual assembly syntax.

      The other point is, it's not about "learning" assembler, it's about doing something substantive enough to use the equivalent. Then we're talking learning.

  rd

     

In soviet russia... (0)

Anonymous Coward | more than 7 years ago | (#18451805)

Assembly program you!

University Teaching High Level Languages (1)

orta (786013) | more than 7 years ago | (#18451809)

With the rise of C# and Java being the languages of choice, and having maybe a 2-3 lectures on what assembly language is, it's likely that the new generations of programmers just don't care. I often get called 'crazy' for daring to code in C.

Always have a place (0)

Anonymous Coward | more than 7 years ago | (#18451811)

As long as you can write something that is more efficient in assembly than in a higher language it will never go away. Obviously it's not the right choice for most things, but it will still have its use.

I say learn it. (0)

Anonymous Coward | more than 7 years ago | (#18451815)

You'll have a bit of a better understanding of what's under the hood. Even if you're programming for a lowly 8bit embedded processor. Or you could remain ignorant and say it's no longer relevant.

more important.... (1)

penguinbroker (1000903) | more than 7 years ago | (#18451821)

the last decade or so has also seen a minimal amount of change to the architectures that intel and amd (most common processors) support. BUT... as parallel computers become more omnipresent, the need for strong assembly language skills should increase as developers try to squeeze out all the power they can from these new wave of computers.

speed... YES!! (0)

Anonymous Coward | more than 7 years ago | (#18451827)

if you need the speed (ie in universities where all they are doing is sim's) then yes using assembler is extreamly relevant!
sometimes all you need is the CPU as a universal state machine as opossed to a platform that an OS resides in

would you rather your code run at main CPU-speed or based around the kernels tick? NOTE the linux kernel with a tick at 100Khz is next to useless in running anything but the kernel (apparent CPU speed to apps ~ 10% of actual CPU speed). why run w.r.t a tick when you can run at main clock speed

Re:speed... YES!! (0)

Anonymous Coward | more than 7 years ago | (#18452045)

I agree that sometimes you don't need an OS. But to say that the apparent CPU speed to apps under linux is 10% actual CPU speed? How did you determine that?

Very relavent (5, Insightful)

Forrest Kyle (955623) | more than 7 years ago | (#18451831)

Well, given that the world runs on embedded systems, and will probably become more reliant on even greater numbers of even more complex embedded systems, I'd say assembler will be around for quite a while. However, in terms of game programming or something, it's probably not amazingly useful any more. It is my understanding that most of the API calls to advanced graphics libraries are about as optimized as they are going to get. Clearly you don't need it to write a medical billing application.

I would not encourage universities to start pumping out CS graduates who have never seen assembly laguage, and don't expect it to phased out of the average Electrical Engineering curriculum any time soon.

Frankly, I don't think it's a very good question. It's sort of like saying, "Given that we now have calculators and computer algebra systems that will do the math for us, is it really worth it to waste students' time learning the nuts and bolts of mathematics?" It has been my (limited) experience in software engineering that knowing how something works on a deeper level will almost always be an asset, and at the worst have no effect at all.

nowadays? only for transistor hackers (0)

Anonymous Coward | more than 7 years ago | (#18451841)

For the most part, it's no longer necessary to know Assembly Language unless you work with actual transistors of the chip, or are dealing with code you know will not be optimized properly by your compiler (and need every speedup you can get). I'm taking a Microsoft stand for this unfortunately here...

Most people don't care how well the compiled binary ends up and expects the CPU to make up for software inefficiencies (sad sad world this has become). "correct by design" not "optimized by design" is more important. Many high level language compilers tend to generate code sequence that's better than what you can do by hand anyway. However, if you suspect or know not, and this tends only occur if you need every optimization you can get, then likely it's not necessary to optimize this way and assembly isn't necessary.

Glad I did (5, Interesting)

linuxwrangler (582055) | more than 7 years ago | (#18451843)

I'm glad I took assembly. I've never "used" it in the traditional sense of writing an application other than in school, but understanding how things work "under the covers" (whether at the CPU, hard-disk or network level) has provided valuable guidance in day-to-day design and troubleshooting.

I've worked with people with very focused high-level programming skills and found that while they could write mostly decent code, their code was also most likely to fail in production since they were completely mentally removed from concepts like disk-seek times or bandwidth constraints. Programmers with a deeper understanding of what actually happened when their code ran tended to make wiser programming choices.

Yes, in some ways (1)

Deathanatos (811514) | more than 7 years ago | (#18451853)

For creating regular applications, probably not.

But assembly still finds its uses in niche places. Things that need to run as fast as possible get optimized by conversion to assembly along with further tweaking (and then bragged about). OS specific code, bootloaders, or even drivers, might have to be written in assembly (or involve assembly).

My old TI-83+ can, AFAIK, only be programmed in assembly or TI-BASIC (which is slower than dirt). Assembly is blazingly fast by comparision, and is the only choice for more complex applications.

Embedded devices might find more use for assembly as well. I worked on a robot/robotics team for the past few weeks. The first thing that the robot executed was written in assembly. (It setup stack registers, did a few other things that I never quite figure out, and kicked control over to a C function.) OS startup, essentially.

Granted, assembly is being more and more rare, but it still has a place in today's programming.

important? (0)

Anonymous Coward | more than 7 years ago | (#18451887)

.begin
Message db "fp$";
mov dx,OFFSET Message
mov ax,SEG Message
mov ds,ax
mov ah,9
int 21h
mov ax,4c00h
int 21h

END start

Not quite dead... I'm getting better (5, Interesting)

softwaredoug (1075439) | more than 7 years ago | (#18451897)

One day won't there be little nanobots floating around with 512 bytes of memory and a 1 mhz processor that need to buzz around your body and eat up your precancerous cells? I imagine as things get smaller, the miniturization fronteir of computing nescesitates limitations in computing power and memory. This may necesitate a new generation of assembly programmers. Even today in the minituarization/embeddedness/realtimeyness world where many enjoy programming away in plain old C (like me) that knowing assembly is useful. First to look at the compiler's output and figure out what the hell its doing, second to just have a plain basic understanding (not necesarilly a detailed one) of what your C statements/operations/etc is probably turning into in assembly instructions.

Another question, would assembly be more popular if it wasn't such a nightmare to write for Intel's x86 architecture? If we all had nice Motorolla PCs, would assembly be really cool?

Let's make this an ad hoc poll!!!!! (1)

BKX (5066) | more than 7 years ago | (#18451901)

Vote by replying with the following choice subjects:

Yes, assembly rocks.
No, assembly is stupid, old and out-dated.
I married assembly, you insensitive clod.
WIPO: (for example, I like to wipe asses with assembly.)

Re:Let's make this an ad hoc poll!!!!! (0)

Anonymous Coward | more than 7 years ago | (#18452105)

Shut up, you retarded piece of shit.

Yes (4, Insightful)

Starji (578920) | more than 7 years ago | (#18451911)

Do you write drivers? Or do you need highly optimized algorithms? What about really low level firmware stuff?

In other words, yes, there are good reasons for knowing assembly. Whether or not you'll actually use it is another matter entirely. Just depends on what you're working on.

Actually I wouldn't be surprised if in about 10-15 years assembly programmers are in higher demand since none of the CS schools these days ever teach assembly anymore.

Re:Yes (1)

armer (533337) | more than 7 years ago | (#18452713)

10-15 years!!! But I need to eat now!!! Actually we are still using assembly in the really small PICs, cause we are too cheap to by the c compiler for it...

Definitely (2, Interesting)

SaidinUnleashed (797936) | more than 7 years ago | (#18451943)

I just got a SDK-86 to start learning it!

Embedded Development (1)

nzAnon (130423) | more than 7 years ago | (#18451945)

There is still a vast amount of Embedded development being done, and, for devices with extremely restricted resources, is best done with assembly code.

See Microchip's 8-bit PIC micro range for examples.

Of course it's relevant. (2, Insightful)

grub (11606) | more than 7 years ago | (#18451971)


How do compilers know what to compile to? Magic? Imagine if all the assembly programmers died: who'd maintain & update compilers, embedded devices, many realtime instruments, etc. ?

Yes, but only for general knowledge (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18452029)

Learning assembly language is good because it gives you a better sense of processor architectures and what the compiler has to do. Think of it as similar to learning how to add and multiply by hand, even though you will probably use a calculator for most arithmetic in the future.

Do not delude yourself into thinking assembly is the ultimate gateway to speed though. I would bet most of the people advocating assembly language programming to make your code go faster cannot write assembly better than today's optimizing compilers. Similarly, you probably won't be able to do better than the compiler either, with one major exception: Compilers do not generate effective SIMD code yet (gcc is slowly trying to add it, but it is pretty primitive). This is because popular programming languages do not express data-parallel algorithms in a way that makes it easy for compilers to spot them and generate the appropriate code. Many media libraries use assembly language primarily for this reason, and not because they are bad-ass programmers who can allocate registers better than gcc.

Why do you need to ask? (1)

exp(pi*sqrt(163)) (613870) | more than 7 years ago | (#18452073)

If you don't plan to program in assembly language, but you'd like to learn what it's all about, just find one of the many introductions on the web and read it. There are no profound concepts to learn and nothing complicated to understand (unless you want to get into the details of virtual memory or exactly how multiple simultaneous interrupts are handled). You'll have it figured out in an afternoon. You won't be an expert, but it sounds like you've no need to be one. This is a short enough time that it's really not worth agonising over whether it's useful to learn. In a single day, if you have a few dollars to spare, you could even go from ground zero to programming your own embedded hardware with a project like this [kuro5hin.org] . So really, stop asking, and just get on with it.

Now if you asked if it was worth learning Haskell, that would be a question worth thinking hard about because it'll demand a significant chunk of your time.

YES! (5, Informative)

Bluesman (104513) | more than 7 years ago | (#18452111)

If you never learn assembly language, it's a very strong possibility that:

- You can't write a compiler
- You can't debug C/C++ programs
- You don't really know why buffer overflows are bad
- You don't really understand memory management and what the heap and stack really are
- You don't really know why threads are different than processes
- You can't write a device driver
- You don't know any computer architecture at any depth that matters
- You won't ever understand garbage collection
- You don't know how your CPU works
- You won't think the movies with "hacking" in them are as funny as the rest of us do.

If not being able to do those things doesn't bother you, by all means, don't learn assembly.

The thing is, in order to be a really good programmer, you have to know how the machine works, all the way down. Once you do, you can pick up any language very easily, because you know what they're trying to do and how.

Just learn it. It's really one of the simplest languages to learn. Realize it's not a programming language, but simply the actual machine code represented by mnemonics. So you'll have to learn an architecture. Intel 386 is a great place to start, and it couldn't be easier than on Linux. You have a flat, protected memory model, GNU "as" is likely already installed, and you make system calls using interrupt 0x80 after setting up the arguments.

You should be printing stuff to the screen within minutes, and interfacing with C object files in hours. You can write the GTK "hello world" program in a combination of C and assembly fairly easily.

Get to work.

Do you want to be a *good* programmer? (1)

LoveMe2Times (416048) | more than 7 years ago | (#18452117)

Does a web developer need to know HTTP? Does a network programmer need to know the details of TCP/IP? Does a Window's application programmer need to know the ins and outs of the WIN32 API, event handling, processes, threads, handles, GDI, DirectX and others? Does a Flash programmer need to know anything about the SWF file format?

In general, does any programmer need to know low level details of the technologies they use given that they have high level libraries and abstractions to work with? The answer, IMHO: only if they want to be good at what they do. However, what you consider to be "low-level details" will vary depending on what you're doing. If you're doing J2EE, then low level details might include how different browsers handle cookies, the specifics of HTTP, how it interacts with proxies w.r.t. caching, various details of JavaScript, parameters to the VM that affect garbage collection, the internals of any frameworks you're using (like spring or hibernate), some of the details that the DBA worries about, etc. Assembly language might as well be silicon transistors. Even the details of TCP/IP are likely to be a little far afield for a web developer.

For an application developer, high level and low level are likely a different beast. Different again for a game developer. Game developer probably needs to know assembly. Network programmer or (embedded) systems programmer, yeah. Application developer, I would recommend it, especially if you're working in C/C++ world.

I want to point out a caveat here: I don't mean people should be experts in all this stuff. We have specialization for a reason. I'm talking about having a basic familiarity and comfort level working with them. It's a whole different beast debugging through some assembler vs writing 100,000 lines of it. Knowing how TCP/IP works and the general layout of the headers and packets is a different beast from writing your own TCP/IP stack. Etc.

Cheap hardware means less assembler. (1)

SirSid (91164) | more than 7 years ago | (#18452165)

1. Performance problems are solved with faster hardware.
2. Software bloat problems are solved with more RAM or disk.
3. Software developers are lazy and rely on points 1 and 2.

When hardware was expensive we needed good assembler programmers to make the most of the hardware. Now we throw more hardware at the software issues.

Re:Cheap hardware means less assembler. (4, Interesting)

FrankSchwab (675585) | more than 7 years ago | (#18452543)

We're in the process of doing a SOC ASIC, with a 32 bit CPU, analog sensing hardware, USB and other communications ports, sophisticated low power wakeup mechanisms, and RSA/AES/SHA-256 hardware. It only contains 32KB of ROM and 12KB of RAM. We expect the part to require less than 10ma of current in full-scale operation (generating 1 MB/sec of encrypted sensor data). We expect the parts to sell for less than $3, including several bits of external hardware, into a highly competitive marketplace. If our parts cost $0.10 more than our competitors or take 10 ma more current, we're out of business. We expect to sell millions of parts per month.

ROM and RAM comprise the largest space on the die. Die cost is about linearly proportional to area - doubling the size of the die doubles the cost. As a result, we don't have the luxury of embedding Linux, throwing a couple more MB of RAM at the problem, or increasing the clock speed. We certainly don't have the luxury of throwing this weeks latest, greatest academic language at the problem. 'C' and Assembly is the only way this product is going to survive.

I think you can be a fine Web programmer without knowing assembly or 'C'; I think you'd be a better one after one assignment to a project like mine, where every design decision is made and every line of code is written with a thought to "how fast is this going to run, how much code does this generate?", rather than "how do I get this done fastest and easiest?". There are many situations where the "throw more hardware at it" approach is valid; there are also many situations where it isn't.

I am typing in it right now (0)

Anonymous Coward | more than 7 years ago | (#18452169)

We're writing an assembler program right now for a microcontroller. gcc just wouldn't cut it speed wise and it also wasn't using the registers of the uC sanely. So we wrote it in assembly. As for learning it, once you know C you can just pick it up as you need it.

It depends on the economics of the situation (0)

Anonymous Coward | more than 7 years ago | (#18452211)

If you are making only a few of something then engineering time is probably the major expense. In that case, anything that gets the job done quicker produces the cheapest result. You can afford to spend more on parts; a more powerful processor, more memory etc. In that case, trying to do the job in assembly almost never makes sense.

On the other hand, if you're making a million of something, engineering is just about your smallest expense. It pays to optimize the design and reduce parts count and parts cost. An understanding of the hardware issues makes the difference between profit and loss. If you understand machine code and can program in assembly, you can do clever things that save big bucks.

Very Helpfull I think (1)

Stevecrox (962208) | more than 7 years ago | (#18452215)

I'm a computer engineering student in our second year (share the year with EE,E,COMMS,ROBOTICS) we had to program a 8031 (http://www.pjrc.com/tech/8051/board5/index.html) it taught me alot on how a Microprocessor and Microcontroller works, this year I've done a software programing module which was a breeze because I'd been forced to learn proper memory management had already delt with concurrency, interupts and other little tricks OS's do.

Also this year we've been learning VHDL those of us who worked hard learning assembly last year have found it a breeze getting to play around in semi C and know how it works.

Assembly makes you appreciate higher level languages, teaches you to learn about clock cycles (remember kids SJMP uses have the cycles of LJMP!) memory limitations (you learn alot with only 8 bytes of internal memory) and with things like the SDCC you can make a program in Assembly and test it, then learn C and test it on a board and once you know basic C the only hard thing about C++ is OO. Personnally I like assembly it can make tiny programs and can help you understand some of the seemingly abstract things about programming.

Of course assembly language is relevant (1)

mtaht (603670) | more than 7 years ago | (#18452219)

... but only after you have a good grip on algorithms and on processor architecture. There are many tricks one can do in assembly that simply can't be done in a higher level language.

Jumping directly into the center of a loop - Aggressively and effectively using registers - Developing compilers - Doing bit manipulation - using barely language supported features like "find first bit" or popcount - are all things that can often be best done in assembly. Big today is vector arithmetic.

Grokking assembly helps is knowing what can be fast in your language, and what can't be. For example, in looking at some gcc generated X86_64 assembly code recently I found that floor and ceil were still function calls on that processor. As was lrint (even though SSE has a rounding mode).

The two places where assembly is used a lot these days is in accelerating vectorized code, and in low level hardware bringup. If you are interested in developing code for a new processor or SOC, you aren't going to be writing in java at first, but painful, tedious assembly, poked directly into the processor via jtag.

Lastly - in the general case, if you don't know how your hardware really works, you don't know how to program effectively for it.

Sure, in today's day and age, you shouldn't set out to code an entire visicalc-alike in assembly - but profiling your code to find hot spots - and knowing when and to use assembly to fix them, IS important.

Examples:

Extensive oprofiling of ardour 2's [ardour.org] core routines showed several that would benefit from being rewritten in assembly, or something much closer to assembly. Result? Ardour now scales 2-3x better under high workloads than it did before (and those core routines STILL dominate the runtime)

Now, if the question is: "would being a competent assembly language programmer be a help in the job market?"

Beats me. Isn't helping me out [taht.net] at all.

IMHO everybody should learn some assembly for at least one processor at some point before exiting college, preferably in the first or second year.

It is relevant... (1)

gweihir (88907) | more than 7 years ago | (#18452323)

... for the additional insights. It is also relevant if you plan to work on a small embedded platform were the size and speed gains may be huge. THe insight especially will allow you to understand advanced stuff. Granted, with the quality of most code produced today, obviously most programmers do not have the additionsl insights you can gain from using assembly language. But then, most programmers seem to even fail at basic algorithmics.

It you take pride in your skills and want to refine them, lear one assembly diealect. I would advide MC68000, but that is not in wide use today. A close subsutitute is the input language the GNU assembler GAS uses. It basically maps the old MC68000 commandset to a 386 or higher CPU (as far as possible).

Assembly programming dead? Say it ain't so... (1)

leed_25 (156309) | more than 7 years ago | (#18452339)

I spent the first 10 years of my career programming in assembler for various kinds of minicomputers and also for the PDP-10 (not really a mini). It was heavy sledding and I would do most of that work in C today (or possibly C++). That being said, I would not give up that early work in assembler for anything.

It was fun and illuminating to be so close to the hardware --I have written numerous device drivers in assembler and even an RTOS of sorts-- but, all in all, I suppose that you are right, it is unlikely that I will ever do that again.

Yes! (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18452369)

I was asked this question by the new head of the Computer Engineering Department at my college, RIT. They were thinking of removing this requirement from the coursework. My point then (and now) is that (as others have pointed out), it's important to understand the Assembly Language of the processor you're working on, so as to aid in debugging, etc. As was pointed out, very little assembly "programming" is done today, only those items that are close to the hardware (drivers, Kernel stuff, etc.) In the past, I've actually found compiler bugs when looking at software in assembly, finding out how it screwed up a procedure prologue. Granted, today, compilers are MUCH more mature (thank you Compiler Gurus!). However, debuggers and other diagnostic tools still need to know/understand the underlying architecture and hence knowing the "raw" assembly code is a very handy thing. One area, as pointed out, is DSP's, these are still heavily programmed in Assembly, as that's the best way to squeeze every possible MIP out of the device. Most DSP's can juggle multiple things at once. I spent time in the early 90's working with TI C25 DSP's. Some very handy things you can do, but limited in other ways, in terms of RAM space, etc. (it was the wrong CPU for the job, but that's what the PHB's wanted to use, as it was cheap).
As an Embedded Systems Engineer with 25 years experience, Assembly language is important to what I do, even though I don't use it all the time. I still enjoy the ability to turn on the "disassembly" mode of the debugger and single step through the problem.

One thing... (2, Informative)

petrus4 (213815) | more than 7 years ago | (#18452419)

...that learning assembly will teach you is that a libc is really a convenience, rather than a necessity. If you know what you're doing you can accomplish pretty much anything either via system calls directly to the kernel, or by writing your own asm functions for various things (print, etc) and then simply calling *them* via includes. If you end up writing your own asm includes for things you'll still get some bloat, but I can guarantee you that it will be an order of magnitude less than using glibc. There are times when that can be valuable...like if you're needing a system which will fit on a floppy or usb stick, or for an older system with less ram etc.

I strongly recommend checking out asmutils [sourceforge.net] if you want examples of asm programs that actually do something useful. Some of these (such as ls and the basic httpd) are less than 1k in size.

You might also be interested in Menuet [menuetos.net] , which is an entire (small) OS including GUI written completely in either 32 or 64 bit asm.

Yes, but not for everybody... (1)

astifter (1079071) | more than 7 years ago | (#18452509)

Its good to know assembler because it teaches you how it works on a more basic level. Its good to be able to debug and optimise in assembler. (I do that on a weekly basis... but I don't actually write in assembler tough.)
Its necessary if you work on microcontrollers. (Again, debugging and optimising.)
(Optimization can also be done by looking at the assembler code a compiler generates, crying, then rewriting your C-code to generate better assebly code..)
So yes, its quite useful. (And knowledge never hurts....)
astifter

learn it well enough to read (2, Interesting)

moocat2 (445256) | more than 7 years ago | (#18452525)

While I have not written any assembly since college, I am really glad I know it. As an engineer who works in C/C++, sometimes it is really helpful in debugging to see what is happening at the assembly level.

So, I would definitely recommend at least being acquainted enough with assembly so that you can semi understand a listing.

Ownage (1)

HTH NE1 (675604) | more than 7 years ago | (#18452531)

I've said it before: the lowest code owns. Also true: he who codes the lowest owns.

See Reflections on Trusting Trust [acm.org] . It should be required reading of every programmer.

depends on your career choice. (1)

LOTHAR, of the Hill (14645) | more than 7 years ago | (#18452533)

For java/db/web apps, not so important. It's absolutely crucial for OS, drivers, or development on micros.

Relevant? (0)

Anonymous Coward | more than 7 years ago | (#18452535)

Heck - we should be teaching it (albeit a little simplified) to 6 year olds, along with Latin, philosophy and QED. Get them understanding the fundamentals right from the word go - it's the only way we're going to evolve...

Very important (2, Interesting)

SpaghettiCoder (1073236) | more than 7 years ago | (#18452599)

You need to have assembly language, to write routines to directly access the CPU (perhaps to make a fast routine to do a simple operation in your program that gets called many times), address specific memory and input/output of various hardware such as your screen, your ports, everything.

There are limitations to what high-level languages can do. When I started out on the Amstrad CPC, I remember the computer booted up into a very inefficient non-standardised BASIC, which had many added commands which were really functions to allow access to the unique hardware of the CPC (sound and graphics). These were ridiculously slow, with the Z80 processor and 32K memory available for programs. If you wanted to make a simple animation for example (say, a little 2D sprite walking across the screen), you needed to do it in Z80 assembly language IF you wanted the computer to do ANYTHING else at the same time (e.g. scan for keyboard interrupt, play sound chip in background, or even just a second sprite).

x86 assembly language isn't hard, but it's the only way you're going to be able to play control freak with your PC hardware. Many excellent Linux applications are done almost 100% in assembly language, including the excellent SNES emulator ZSNES (which makes much the same demands on Linux as the old 8-bit Amstrad, and keeps perfect time). If speed is really important then there's no other way. For some reason I think secret organizations like GCHQ would employ skilled assembly programmers so they can keep looking for ways to brute force public-key encrypted messages in the shortest possible time.

In my opinion, a lot of people are able to use a few libraries in VC++ or similar to be able to make useful programs, and also new things like Python, Perl, etc. but that doesn't necessarily make them a "coder" just because they're able to use some built-in functions. To be a "coder" means you PREFER to use plain C, and know assembly language (even though assembly language is different for every platform - an assembly language programmer knows exactly what info he needs to find out re opcodes and registers and memory addressing and interrupts, to program his program with the same techniques).

It's a pity about the Lisp Machines... (3, Interesting)

starseeker (141897) | more than 7 years ago | (#18452609)

I have always wondered what would have happened if the idea of using Lisp as the assembly language of a machine had actually taken off. If I understand the Lisp machines correctly, they were actually "lisp on the metal". Given the flexibility and power of the lisp language it would have been very interesting to see what the evolution of the Lisp Machines would have been, had they proved viable in the long term.

it's fundamental (1)

wmeyer (17620) | more than 7 years ago | (#18452611)

Of course it's important to learn assembly language. Compiler writers need the capability to tweak code below the level of the compiled language, for one thing. But so do many others. It's easy to overlook the importance of assembly language when you're running a 3GHz 64 bit machine, but for those of us who sometimes have to work with real-time (microseconds, not milliseconds) and for those who must deal with what happens on adapter cards, not just on the PC, and even more, for those who may have to code for 8-bit machines in real-time with very small memory budgets, assembly continues to be important.

C++ is not the universal solution.

Yes, in some lines of work (5, Informative)

Distan (122159) | more than 7 years ago | (#18452619)

First, I'll give the disclaimer that I am a hardware engineer, not a software engineer.

My experience has been that when bringing up new hardware, when you don't yet have a stable bootloader, let alone a compiler or operating system, then being able to write in assembly is very valuable.

More accurately I think I should say that being able to write in machine language is very valuable, as you might not even have a working assembler depending on what you are working on.

Being able to peek and poke a few registers, hand code a loop or two, and maybe write some sequential values across a bus can go a long way in helping you get the hardware going. Hook a logic analyzer to the bus and you're golden.

Even if you do have a whole infrastructure of compilers, device drivers, and operating systems available, none of that helps you when the first damn batch of prototypes (made of the first revision of the PCB, containing the first ever silicon of a new CPU, and the first ever silicon of the the new chipset) won't even boot, and you are trying to get to root-cause ASAP because you've got a whole army of testers ready to have at the hardware as soon as you get it running code.

In short, if you are the guy designing the raw iron that the software is going to talk to, you better be able to step up and take control of the raw iron when the software can't.

depends what you're writing (1)

Zork the Almighty (599344) | more than 7 years ago | (#18452645)

Whether or not you want to learn assembly depends on the kind of software that you want to write. If you are writing "interface" software, where a wide range of functionality from different sources is tied together to accomplish a goal, then assembly language is not really useful. Even if your software needs to be fast, you can probably use C. It is always much more important to optimize the data structures and algorithms used for a program, followed by the cache behavior.

Where assembly language is useful is when you really need to get down to specific instructions. Maybe your C compiler is producing bad code for a critical section, or it can't make use of some optimization because it doesn't know about restrictions on the data. Another situation is when you want to use instructions which have no analogue in your preferred higher level language. For example, say you want to implement a lock-free data structure using compare-and-swap. You will probably have to code some of it in assembly for each platform.

In all honestly, learning assembly should be no big deal. You don't have to be a guru, but it is always helpful to have basic knowledge and skills that you can build on later if you need to. CPU instruction sets aren't going away, and I found it added to my confidence to know that if need be, I could always go right down to the level of machine instructions to bash exactly what I want into the machine.

Understanding Compiler Bugs (0)

Anonymous Coward | more than 7 years ago | (#18452659)

Recently I have done some assembly level debugging to understand why some compiler or another is generating bad code. Of cource we were compiling at the highest possible optimization level which is always interesting. There two reasons for doing this, first is to generate a work around and second is so that we can report the bug.

Course it's relevant (0)

Anonymous Coward | more than 7 years ago | (#18452705)

I was just involved in the writing of a linux device driver for a device which was formerly supported only in Windows (XP, not even Vista) and one of the skills involved was decoding the firmware of the device to understand how the device talks to the computer. So yes, assembly skills remain relevant.

Internal combustion engine alalogy (2, Insightful)

davidwr (791652) | more than 7 years ago | (#18452707)

Knowing assembly language is like knowing how to an internal combustion engine works.

For most drivers, it's a curiosity.
For most auto mechanics, it's somewhat useful.
For anyone doing engine repair, it's very important.

If you are programming at a hight level like Java, .NET, or web-based programming, knowing assembly language won't help much.

It's only when you are using a language like C where knowing how the chip works can actually help you write your code does it really matter.

Anyone doing systems programming, real-time programming, or anyone who needs fine control over their program's execution should learn assembly.

For non-programmers and very high level programmers, it's about as useful as studying Shakespeare or business law. It'll make you a more well-rounded person but it won't help your code run faster.

I used assembly langauge just today (1)

EMB Numbers (934125) | more than 7 years ago | (#18452711)

I am benchmarking various signal processing function on a variety of CPUs including PPC970 (a.k.a Apple G5) and Intel Itanium 2. I have had to both examine and optimize assembly language for both processors and their SIMD units, Altivec and SSE2 respectively.

There are some domains including signal processing and embedded system generally that require assembly langauge occasionally. Having said that, I write 100 times more C/C++ than assembly language.

Assembly Language Absolutely Revelvant (1)

Ichthus777 (1037294) | more than 7 years ago | (#18452721)

Any good software engineer will learn assembler for at least one platform (one processor) to gain both a formal understanding of how a von Neumann processor functions as well as understanding the basics of low level programming. Most business (and other) application programmers will never have to actually program using assembler; however, assembler is often required for programming microprocessor chips in advanced embedded systems, and sometimes low level driver functions are best done in assembler. Assembler is still highly relevant; however, assembler is also not used by the masses of applications programmers.

Libpng has some (0)

Anonymous Coward | more than 7 years ago | (#18452731)

A few years ago someone from Intel contributed some assembler code to libpng, to handle some of the innermost hard decoding work using Intel's MMX instruction set. Later on one of the libpng maintainers converted the code to run on gcc compilers.

Although, when it works, this does make the decoder run a lot faster, the code has been a maintenance nightmare. Not all platforms, such as 64-bit machines, are able to assemble the code correctly. Some don't produce compiler errors but produce bad code. The libpng group finally had to resort to distributing several special makefiles (makefile.linux, makefile.gcmmx, and makefile.nommx) to build with or without the assembler code, and to resort to special tricks in the configure script to decide whether to use it or not.

no need for it, believe me. (0)

Anonymous Coward | more than 7 years ago | (#18452751)

There is absolutely no need for it. If you know what a car is for, why should you know then what these funny long sticks beneath your bel-bul-thingy-down-your-how-do-you-call-that are for? Just trust me.

cb
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>