Slashdot Mirror
Is Assembly Programming Still Relevant, Today?
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? "
....... (sounds of crickets) ........
It's good to know how things work underneath the hood.
Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
Previewing comments are for sissies!
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.
How we know is more important than what we know.
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.
ResidntGeek
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.
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 good programmers, yes.
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.
Hire someone else to code in assembly.
Yes, it is.
Reverse engineering malware.
If you know DSP, are adept with fixed point arithmetic, know a bunch of fun tricks, 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.
-- Erich
Slashdot reader since 1997
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.
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.
-Bill
Assembly program you!
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.
my band is more brutal techno punk than yours
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.
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.
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.
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
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.
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.
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.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
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.
.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
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?
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.)
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.
I just got a SDK-86 to start learning it!
Shiny. Let's be bad guys.
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.
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. ?
Trolling is a art,
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.?
This is my sig. There are many like it but this one is mine.
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.
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.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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.
LOAD "SIG",8,1
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.
If moderation could change anything, it would be illegal.
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.
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.
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.
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.
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.
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 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 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.
... 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).
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
...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 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, which is an entire (small) OS including GUI written completely in either 32 or 64 bit asm.
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
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.
I've said it before: the lowest code owns. Also true: he who codes the lowest owns.
See Reflections on Trusting Trust. It should be required reading of every programmer.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
For java/db/web apps, not so important. It's absolutely crucial for OS, drivers, or development on micros.
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...
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).
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.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
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.
--- Bill
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.
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.
In Soviet America the banks rob you!
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.
I like to think about it as the root of a series of primes multiplied together, none of 'em can be removed easily!
Knowing assembly language is like knowing how to an internal combustion engine works.
.NET, or web-based programming, knowing assembly language won't help much.
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,
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
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.
Ichthus
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.
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
I've had it up to *HERE* (trust me im pointing really high up) with "IT EXPERTS" who don't have the foggiest fucking clue how a computer works.
It's worth it, just for understanding in a general sense. It's worth it to understand the function of a microprocessor works right down to the latches and nand gates. It's worth it to know how the various IO buses operate, what their limitations are, etc.
It's worth it just to know what a computer CAN do. It's worth it to know how much overhead there is every time that recursive subroutine calls itself.
It's like asking if it's important for a car mechanic to know how an internal combustion engine works. He could probably change oil at jiffy lube without it. And break my fucking PCV valve and tape it back on with electrical tape. It just goes in like a cork I mean what the fuck, like I wouldnt notice, or think Ford installed it that way? Then they get lippy when you demand they replace a 2 dollar plastic doongle because they think its a major overhaul.
What was the topic? Yeah, it's a good idea to have a fucking clue how what you work with functions.
I don't need no instructions to know how to rock!!!!
If you want to break DRM, you need assembler! Microsoft ain't gonna give you their source, yaknow!!!!
Compiler writers might find it useful. There understanding of ASM make sure your HLL executes
quickly.
Driver writers? I do not think they can use Java or Ruby.
OS Writers? ASM in key places can make a big difference.
Now on a User level PC program who cares. 64 bit integers, whatever. The smaller the system the more it maters. You would be suprised how many new 8 bit programers think they have an FPU or 16 and 32 bit instructions.
ASM is not going anywhere until the CPU learns to read HLLs.
try, Peter Norton's Assembly Language Book for the IBM PC,ISBN: 9780136621492
I read it at my local uni when i was in highskool. brings back memories.
B81300CD10B80100CD33B8004CCD21
you can "program" that by using copy CON: 1.com
and using alt-x to enter the ascii code equivalent to the hex
used to do that at school, just to piss off the teachers
w00t
ps: try it, or just disassemble it in your head and tell me what it does. rofl
pps: i used to show people and tell them that early windos really was close to dos cause after all the basic functions came from dos and the bios. heh
"Jumping directly into the center of a loop"
Not to mention jumping directly into the middle of an instruction. Oops. Did I say that out loud?
If you need to ask, then I would not hire you.
Even for applications programmers, it can be useful. On occasion you may run into compiler bugs. It's helpful to be able to compare the source code and the compiler output.
Mea navis aericumbens anguillis abundat
I don't want to derail the comments so feel free to mark this down as "Off Topic" but the discussion here reminds me of moving out of university into the world of "real" chemistry, and the basic principle may apply in all fields. When everything's working fine, you don't need to remember the fundimental stuff and can treat it like a black box. However when things begin to behave strangely, you have to know what's inside the box or you're never going to be able to solve the problem. The obvious analogy is when your car breaks down
If I'm interpreting a simulation of a compound, even if I'm only interested in the structure, I need to know the nuts and bolts of the numerical methods used to predict that structure, so that I can choose the right approach. Even if the correct approach is obvious, in-depth knowledge is needed to avoid mistaking simulation artefacts for actual information.
Any examples from other fields?
No kidding!!! What do you say at this point?
Unfortunately faster hardware still gets pushed to the limit and remember that a 1% improvement is nearly two hours time saving per week per node - not paticularly trivial when the job takes over a week to run on ten nodes (nearly twenty hours in which other stuff could be done if you could get that 1% improvement). With numerical data processing in a lot of fields you just do more with the data when you get better hardware.
I used to wish that there were more hardware resources available to get the job done in a reasonable time-frame. Now that I got my wish and hardware is so cheap and capable, my hard-won assembly language skills are mostly obsolete.
As this was said of the educated a century ago, the same might be said of assembly language for programmers today. There are benefits outside of direct application that prove worthy in other endeavors.
http://uncyclopedia.org/wiki/User:Steve_Ballmer
People who read my previous posts on similar topics probably have seen im one of the vocal advocates for shifting toward a more "practical" education system when it comes to anything computer related, or at least splitting the more science part from the engineering part (splitting CS in two, more or less). But EVEN with these belief, I have to say, learning assembly is totally relevent.
Even in modern languages like C#, when you start doing something complicated, you will need to use pointers, at least once in your life (yes, C# allows pointers. Look up the unsafe { } construct). Pointers are the abstraction of something as low level as it gets, and to fully comprehend how it works, you need to, at least once, have touched assembly. No need for an ENTIRE class about it. But at -least- one or two assignmed, a few lectures. People need to know what it is, how it works.
Otherwise, the first time Visual Studio (or whatever) pops up with an exception in a native bit of code, and pops the disasemblyer, people just go "wtf?!" and think its an hopeless situation...
I had fun handwriting a little machine code (lower level than assembly) -- actually just writing the bytes of the program -- in Bochs.
I think in 2 bytes I could do a terminal echo; in 13 bytes I could boot to real mode; and in 33 bytes I could boot to 32-bit protected mode. Coulda kept going.
Why can't we build completely special purpose machines? Like DOS, with no protection whatesoever -- if I get it wrong, please just let the whole computer die. You could just have a fixed byte range i/o monster for your database server.
If you want to play around with Microcontrollers [pic16 series for example] you MUST learn assembly. Ok, you can use a C compiler to do it [SDCC for example] but it can be a bit clunkier and you end up having to write some of the routines in assembly anyway. Microcontrollers are an easy and cheap way for anyone who wants to get their hands dirty with electronics.
noiche
Which leads to the question: why is someone programming an SGI MIPS machine in BASIC? And interpreted BASIC at that?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
...typing a long string of 1's and 0's into a C64?
Now, if you were to ask "isn't knowledge of assembly language for a given microprocessor required to create a compiler capable of directly generating native code?" then the answer would be yes, because all the other possibilities have been excluded. Alternatively, if you asked "isn't quality knowledge of assembly language for a given microprocessor required to create a compiler that can generate code that is compact, efficient on resources and fast?" then the answer would also be yes.
However, as most modern programs are anything but compact, efficient on resources or fast, that is a rather moot point. The best compiler in the world can't turn junk into quality, although a trashy compiler can certainly turn quality into junk.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Are you nuts? How could any reasonably educated person answer "no"? How could a slashdot editor allow this to be posted?
I do it every single day I go to work and it's not even my job. You cannot, now or ever, ignore that hardware exists beneath all those layers of abstraction, obfuscation and OS APIs or BSPs.
C is great, I love it. I'd never write something in asm that I did not have to write, but it's not hard to find situations where it is absolutely essential. You simply cannot do some things in C that you can in assembly, especially as we go multi-core, especially as we use different architectures (like PowerPCs and their DCRs). Every time you send some screwball-over-http packet, somewhere down there, someone wrote a device driver that at a minimum blocks up your packet and refills transmit fifo's in response to ISRs, a lot of which cannot be done without precise control over hardware. And that's just computing hardware, you cannot forget the incredible number of embedded devices out there on which you can't even get a java interpreter to fit. Yes, processors are now fast enough that writing complex routines in assembly is not necessary but for many things, you MUST do it.
Every game console, set top box, computer, car, guided missile...hell even some toasters has assembly in there somewhere. If anything the growth of embedded development has made assembly, and processor architecture more important than ever.
You forgot CoyboyNeal, you insensitive clod!
... which is why their code is bloated, botched, broken, and generally vulnerable. IMO.
Ichthus
That isn't the question. The problem is that via a few levels of encapsulation knowing a higher level programming language has nothing to do with the core code that runs on the processor.
The only thing I've ever used Assembly for is to write up a virtual machine for a genetic algorithm I was running. And even that is on a pretty profoundly different level and I didn't write the assembly code, the evolving little code-bots did.
It is no longer uncommon to be uncommon.
Reading most of these posts gives you a pretty clear idea of where most Slashdot readers have spent a good portion of their time (doing assembly or 1-2 levels up from it). The problem is that "programming" today is done at many different levels. At any level it's naturally helpful to know a bit about the couple of levels beneath you. Trained in EECS, I once enjoyed thinking that I understood "all levels" of computing systems, something that was possible when C was a "high level" language. I had written Windows apps in C, written Z80 assembler, designed a MIPS CPU at the RTL level, built a 4-bit CPU out of gates, and done transistor layout for logic cells. Those times are gone. There are many more higher layers ("programming" in Flash? Excel?) that it's not just not possible to for some people to have a good enough grasp of assembly to be worthwhile. Then there's the fact that for some people "assembly code" is pretty high level. Assuming you mean those complex macro instructions that break down into N actual hardware operations (including loops)? Even those who say "I'm glad I learned assembly" usually don't understand how instructions are broken down and scheduled differently on different CPU implementations... how bugs may cause instructions to be emulated, or how the alignment of memory accesses can affect timing, or how your instructions interact with virtual memory, caching, exception contexts, etc. It's a complex multi-layered world out there. -netchipguy
Eh? Have you tried turning the SGI machine on? Or was the BASIC implementation written by a moron? Hmm, maybe you overclocked your C64. Personally I think you're talking out of your arse.
Frankly I think a good programmer is somebody who writes well documented and designed code. I don't think somebody's knowledge of the low level assembly programming necessarily helps with that. I'd rather somebody wrote somewhat inefficient code that I could read and, as needed, optimize, then have some spaghetti pile that nobody could understand but was lightning fast.
This sig has been temporarily disconnected or is no longer in service
.. even more so tomorrow.
But first there needs to be a change in the way we understand the creation and use of abstractions that lead to higher level languages.
Take any computer language of a higher level of abstraction that assembly language and know that it can be reduced down to assembly language which is far more efficient in its use of clock cycles then higher level languages (which all have to eventually be reduced down to machine language or 1's and 0's)
Now in knowing this, it's obvious that it really comes down to doing the translation down the abstraction ladder BEFORE a compile or assembly into machine language (binary).
Todays methods are sloppy and generate more binary than is really needed to create most any program done in a higher level language. And the more binary also means the higher probability of human error.
This all shows where Computer Science has failed, as the genuine science shoudl have been focused on such prior to binary generation, translation down the abstraction ladder in a manner that holds better output.
However, as software takes the skill of abstraction creation and manipulation understanding to produce, it is also the one industry where the phrase "if you can't dazzel them with brilliance, baffel them with bullshit" really sums up what all the abstractions can be used for.
All to often the sales hype makes all sorts of claims that in actual use are not what they were said to be.
Its all about the use of abstractions.
Its just to bad that Computer Science itself became polluted and distracted from honest science so much that the real research of dealing with Abstraction Physics and the abstraction ladder reduction for code output has in practicality been forgotten.
But it took 300 years for the easier and much more empowering hundu-arabic decimal system overcame the highly inherently constrained roman numeral system of doing math.
And just as computer technology couldn't even been imagined thru such limitations as the roman numeral system presented, so is there advances and technology and markets yet to be imagined with the current failure of Computer Science.
Imagine the task of writing just the software for a holodeck? And since that is beyond the reach todays programming methods, certainly the physical interactive interface as depicted on star trek, is preceived as only ever being fictional.
I realize that assembly is very useful to know and can be useful in certain instances.
But writing in assembly has always given me the same feeling as eating rice with a single chopstick.
I stole this Sig
Seriously, assembly is important for all the reasons you noted, but also for some others. If you know assembly, the chances are:
All software engineering, computer science and programming courses should start by requiring people to program a non-trivial application on an ARM processor, or something with an equally limited instruction set, in pure assembly. Why? Because then you get people who think, who program with care and forethought, who think of bloat not in terms of adding more RAM, but in terms of opportunities for bugs, glitches and gremlins. Sure, you'll get more dropouts. The computing world doesn't need more code monkeys, so it's no loss if they did. Who needs a society of half-baked, semi-literate coders?
This is not elitism, because I'm not saying that anyone should be excluded from the profession. I don't think they should. What I do think is that society needs to make damn sure that the typical coder isn't the worst coder, which is what you get if people are trained to NOT think but to let the computer do the thinking for them. Windows may act like a HAL-9000 at times, but trust me, it isn't remotely capable of anything resembling thought. A bad design or a poor implementation will not be rectified by some magical intelligence in the machine, because there isn't any.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Isn't there some law about this? Law of weak abstractions or something? From what I understand, basically all program languages don't do a good job of simplifying the way to make a computer do what you want it to do. There is always some little detail/trick below the surface that the language cannot deal with or deals with in a peculiar way. So... learning how the lower level stuff works will only improve your mastery of the higher level stuff. Assembly language is as close to the hardware is your going to get. You have to read hardware manuals to actually do any REAL work in assembly, otherwise you are just writing non portable code.
Was it my my university professor, or Djikstra, or someone else who come up with this law?
I learned to do assembly programming a long time ago and it has been paying me back ever since. Knowing at least a little about what a program really does on the inside give you a huge advantage when it comes to debugging, trying to write tight code, and especially when working in the embedded world. Actually, in the embedded world, knowing electronics and how things like analog-to-digital converters work also pays off big time. Having insight into the guts of what is really going on can't be overstated as how valuable it is and the only way people will appreciate that is when they themselves see how valuable it is for them.
That you can see from all the people posting that say the same thing.
from http://www.grc.com/smgassembly.htm
Huh? . . . Windows in Assembler?
Am I sick? Perhaps. Am I a dinosaur destined for early extinction? Yeah, probably. But I truly love programming. It's what I do. It fulfills me and sustains me . . . and I'm never in a hurry to "just be done with it." I can't stand sloppiness in my work, so for me that means writing the smallest, tightest, fastest, most economical computer programs possible. And THAT means authoring Windows applications in Assembly Language.
Though the rest of the world may argue that they're more "productive" (when measured by hard disk space consumed per second), I stand by the principle that: "Small Is Beautiful".
Every programmer should know an assembly language. It's a good start, but it's not nearly enough.
Support SETI@home
Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
... Errr, I mean Nope!
NOP
Havoc Video
Depends on what your doing...does speed matter? Are you attempting to inject a little carefully crafted code into the stack? I say there is definitely a reason to learn Assembly, I mean even if you are an accomplished C, C++, Delpi programmer...you can't really know where your art is going until you know where it's been. Take the time...it will pay great dividends when you find yourself needing to call a little bit of high speed assembly from inside your C, C++, Delphi program. I've also found it fun just to code some otherwise common methods in assembly knowing that my co-workers are not familiar with it...just to watch them scratch their heads...shame on me. If nothing else...you can at least add it to your resume. "Not all things are as they appear...especially the invisible things." Rock on Joanna.
A good software engineer should understand assembly, how that gets translated into machine code, and how the processor uses the machine code. He should also understand the memory hierarchy, how basic cpu designs work (single cycle, multicycle, pipelined). He should also understand DMA, something about hard drives (layout of sectors, tracks, and cylinders). He should also understand something about compilers and how they can perform certain optimizations and how they get from high level code to machine code.
This isn't out of necessity in designing hardware, but for if/when you take a job that deals with the hardware, you won't be lost. These areas typically include operating systems, drivers, firmware, and compilers. Even then, some places want even more from a software engineer because often you're dealing with a custom-made piece of hardware that probably doesn't have your standard screen output device and keyboard input device. Instead you start working with an emulator and then you go load the software on the actual hardware and have to use the hardware test tools to do your testing.
Now if your goal is to be a "C++ Programmer" or a "Java Programmer" then maybe you don't need to know all of those things to be successful. But if your goal is to be a good software engineer then be prepared to never stop learning in both technical topics AND social topics (how you work with other people like programmers/customers to get the job done).
Assembly was the first language that I learned. We used it to program 68HC11 Micro controllers. To this day I am glad that I learned Assembly first even though I use C++, Java and Python more than anything now.
No, it's essential to know how things work underneath the hood.
Hmm. Assembly is still relevant and useful for certain tasks, of course.
/David
But two things come to mind:
1: Handcoders can code better than good compilers?
Yeah, in some cases after a lot of refining. But it is not as easy as it once was.
Compilers have gotten much better and processors have gotten a lot more complex. It's not just "how many clock cycles does this instruction use?", you also have to take various forms of micro-parallelism (pipelining, branch prediction, etc.) and cache hierachy issues into account.
2: It's good to know what goes on under the hood, sure.
But in many, many software developer tasks, early optimization is the root of all evil.
I would actually much rather recommend a top-down approach for most problems, abstracting away low-level details, rather than going bottom-up. The teaching approach of the great "Accelerated C++" comes to mind.
A lot of developers that know a little or a lot about low-level programming write less than excellent code in other regards (algorithmic complexity, design, re-use, etc.) and they can't seem to stop focusing on performance throughout the process.
For most problems, performance isn't critical, and even when it is, it might be better to look for algorithmic enhancements (lowering complexity) rather than do low-level fiddling.
Do you need to know it if you want to be a proficient average programmer? No. (and there's nothing wrong with that)
If we go back to the tried and tested car analogy whereby IT staff is Jiffy lube and programmers are the manufacturers, then the person writing assembler is the engineer in the lab optimizing how air combusts in the cylinder for optimal power. The factory doesn't know and doesn't care, it just needs the parts and an understanding of how they should go together.
There's nothing wrong with a career writing web-apps using VB.net, but if you want to work at the system level, going beyond what comes in the visual studio box, you need things like assembler.
People who think they know everything really piss off those of us that actually do.
As an old school assembly language programmer who now programs in c++, I don't understand how people debug the "hard" bugs without any assembly knowledge.
The more efficient replacement is simply to keep an int or long int containing the length of the string (assuming fixed-size ANSI chars) and pass that around in a struct or something with the actual pointer to the start of str1. This is the way all languages with real string data-types actually handle the problem, and code that returns a beginning pointer and an int for jumping to the end without searching for it will simply run faster (all else equal, of course).
For 99.9% of programming that happens, no, no it isn't.
Do you want to be a real programmer when you grow up?
Do you want to be able to see if your compiler has savaged you, in one of those rare cases where the compiler doesn't generate efficient code?
Do you want to understand why your C program is throwing segfaults in your sprintf?
Do you think you might like to do hard real-time stuff? Or firmware?
Do you want to know what the computer is really doing, or are you satisfied to know it's just black magic?
Do you want to understand why a SPARC or PPC might have advantages --- and disadvantages --- over an IBM 360 or an x86?
Then yeah, you should learn assembler. At least one.
I have a friend who was in the Air Force. He said there was a saying among officers that went, "If you ain't a pilot, you ain't $#|+." Now, in programming, replace "pilot" with "assembly programmer".
Communicating in Morse code. It's a pain in the ass to learn, but when you do, you find the rewards more than justify the effort spent.
:-)
Also, it's good to remember that Assembly language is just one more tool in a programmer's tool box. I wouldn't write throw-away scripts in Assembly language, just like I wouldn't use C. I'd probably use Perl, Python or shell script, as necessary. When you need to hand-tune that algorithm to get that last little boost in performance, being able to drop down to Assembly language can save the day. Too bad it is a dying art.
On another note, I agree with the other posters that said learning Assembly language allows you to learn the hardware better. 8086 Assembly language was my second language (after BASIC), and I used it for several years, until I started using Windows and found it was much easier to write a Windows program in C
No matter where you go... there you are.
Since understanding Latin gives one a better understanding of teh language they're actually using. Right?
He who hasn't hacked assembly langauge as a youth has no heart. He who does so as an adult has no brain.
- J. Moore
I think you're suggesting that for certain kinds of optimization it's as important to know about machine architecture and organization, I.e. things like cache associativity and size, relative speed of memory vs. registers vs. cache, etc., as it is to know or optimize the use of particular "assembler" (actually machine) language instructions. Good point. Still, if you want to know how many memory accesses either the presupplied strcat or your own alternative are going to issue, and which addresses they're going to hit, knowing machine language is a big help.
As long as we have OSes we will need at least a little bit of assembly. Some things are so architecture specific there is no portable way to do them in a higher level language. Like PowerPC style TLBs versus x86 page tables. Virtualization is very specific to each architecture, and Intel and AMD have different approaches to the problem. Also virtualization without special processor support as VMware does requires a major amount of architectural knowledge, and I have little down in my mind that the ladies and gentlemen at VMware spend a significant amount of time reading assembly.
People who write compilers might want to know some assembly language too. I think that's a fair assumption.
The fact that our dependence on compilers, more advanced operating systems, hypervisors and virtualization proves that assembly is not dead.
“Common sense is not so common.” — Voltaire
I learned it for the comp sci program, however I would have to say that it is one of the most fun languages I have learned.
There are so many things you can do with it, maybe not many truly useful things...
I did find a practical use though, I used it to write a prime number program for the Altair 8080.
arrrg, (like a pirate)
In an era when we could conceivably get all the daily nutrients we need to live in a delicious canned protein shake, do we still need teeth?
You can use it to hack DirecTV and Dish Network cards, just don't forget to close the memory hole when you are done :o)
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
:(){
Firmware.
anyone who codes for micro procs better know ASM very well. Granted more and more devices have C compilers available but to get the kind of performance you need it is often required to at least code some key functions in asm. Then there are entire families that do not have decent C compilers (anything below microchips PIC18 series for instance). perhaps this is more important to EE and CE(myself) majors than CS majors, but the CS guys at my school really only ever looked at asm in one class anyway, though it did not have a very strong CS program.
-xian
Of course, you could be writing for some embedded platform with a second rate (if not outright buggy) toolchain. If thats the case your observations apply and... well... I feel sorry for you.
Learn as much as you can about what you do, in as many different ways.
.NET or Java on the job, you don't need assembly. But if you only learn how to do things the .NET/Java way, you are missing a lot of opportunities to make your code simpler, faster, more efficient, or just plain aesthetically pleasing.
.dll (no source) which used an SDK for which the only documentation we had was another .dll. I disassembled the crap out of it, figured out how it communicated with the SDK, and managed to update the extended stored proc so that some idiot who knows only SQL could do his job.
If you use
Learn the C way, learn the assembly way, learn the VBScript way, the C#, and Java, and maybe even some of those utilitarian things like Perl and Ruby.
Also, if you know assembly, nearly all proprietary applications are open source. I did ASP coding, of course moved to ASP.NET. We had a request to change one application - no one wanted to take it on, but I did. Why didn't they want it?
The job was to rewrite an extended stored procedure for MS SQL, which connected to some other appliction via a third party library. That means it was a compiled
That's not within my normal scope, but I was able to do it and no one else could. We could have said, no way you just deal with it, but our team got out there as someone who just plain gets shit done. And, I have an understanding of how these systems work together.
I'm rambling now. Learn as much as you can about what you do. you will save yourself time, your server energy, your company money, and most of all maybe Al Gore will finally have nothing to talk about if we reduce the amount of energy used by computing resources. Yep more rambling.
Answer to "What's hard about pointers?"...
There are people who cannot grasp the difference between "a thing" and "a respresentation of a thing". In fact, there was an entire century where almost the entire school of French philosophers were unable to grasp that there was a difference.
For pointers, it comes down to realizing that a pointer to memory is not the memory, it's a representation, and the real memory lives somewhere else: at the dereference of the pointer. And at that location it takes up real space. And so does the representation (but it's comparatively tiny).
The ability to make this disctinction comes naturally when you've written assembly code of any complexity, since you've had to manage the memory yourself. But if you've never done that, or, worse, you've only ever programmed in languages which eschew pointers and try to pretend that their own internal implementations don't use them, even if they won't let you use them, well, then, you've got a conceptual problem. An that conceptual problem is going to be very hard for you to overcome.
It also makes it very, very hard for someone to understand row-major vs. column major languages, or how you would link a program in one against a library in another, and be able to usefully communicate your data between the two. Or it makes it hard to understand the difference between "call by value" and "call by reference.
If I'm interviewing someone, and it becomes clear that they need a "code interview" because some things don't add up between their banter and their resume, the first thing I whip out is a pointer problem.
-- Terry
Mod parent up!
lol at worrying about the efficient of strcat()
Quite an experience to live in fear, isn't it? That's what it is to be a slave.
ASM is useful in several applications. Most notably low level electronics and theres plenty of complex problems that do require it to be written at the machine level. Lets not even get into boot scripts or anything involving low level booting. You don't need to be an expert but you should have some basic understanding so as to be able to peruse ASM and understand what the hell is going on.
I think this falls under the typical "Which language is better?" argument. Its all based on the developer. Like it has been posted, if you are working on programming chips and kernel modules, then you its something very useful. I am a web and desktop developer. I mainly use Visual Basic for desktop because its ease and build times are very key to my application development. Me learning assmbly would be a waste of time, however my friend who writes kernel modules and programs flash chips for on board circuits is a BIG thing for him where knowing how to write a desktop program is minor.
Bryan
- You're writing some software which will run on modern, fast computers. The software does a bunch of stuff, frequently on very large volumes, and you want your software to go faster than your competitors. So you analyse the performance, and discover there's four places where three lines of code consume 75% of total execution time. By rewriting those 12 lines in assember, the rest of your half million lines goes twice as fast as it used to, and you sell more software than your competitor who wasn't prepared to go the extra mile.
The nice thing about this reason is that as hardware gets faster, the reason remains.What I would like to know is how hard it is to learn and comprehend Intel x86 Assembly language compared to C++ Data Structures? I have to take a couple Assembly language classes soon and I will be taking Calc and Calc2 at the same time! I am taking C++ Data Structures now and damn it is fairly difficult. thanks
http://www.fuckedupcountry.com
Interestingly we convered this topic in a lecture I was in about 2 weeks ago, for the Operating Systems course I sit as part of my degree in Software Engineering. The idea of "ubiquitous computing" is pretty much upon us, as more and more devices are containing embedded CPUs. You're gonna need people that know assembler for this as has been mentioned in numerous other posts above. I got taught a bit of assembler in 2nd year, and I hated it. Electronics students get taught a lot more assembly as part of their degree (especially Electronic and Software Engineering students).
"Everlasting peace will come to Earth when the last man kills the last but one." - Adolf Hitler
As low level as you need it, yet as high level as you make it.
And I have never used it since.
Even so, I'm glad I learned it. I value knowing what the computer is doing 'under the hood'.
Technoli
All you need to know is:
0:000>eb eip 90;g
and you are good to go.
I'm not saying you need to code entire applications in it, but knowledge of it will perhaps give you a bit of an edge.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
These days, most people don't write assembly after college, but reading assembly is still a critical skill. You need to understand how the computer works at a low level if you're going to do OS, compiler, performance, or security work; or expertly debug anything written in a compiled language. The assembly I wrote in school was an important experience to prepare me for the assembly I now read on a weekly basis.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
In my most humble opinion, I think, at least for the vast majority of programmers/students, learning Assembly programming is still an essential component of the whole learning experience. Maybe we may not actually use any of it anytime, but the paradigm of Assembly programming is such that I believe it makes us better programmers, especially regarding program size, quality and efficiency. This is a valid argument because there aren't any resources to waste in this domain unlike the severely unschooled and spoilt programmers that abound today who wouldn't think twice about writing a sloppy piece of code which just "works" but could eat up an indecent amount of memory and disk space, not to mention processor cycles. Like Eric S. Raymond mentions in one of his essays, a language is worth learning only if it teaches us to think in a different manner. Lisp is one such language. Assembly programming is one even better as an example. And I think the best way to make students learn and appreciate programming is to start them off with Assembly programming in a "practical" way immediately through hands-on projects and continuing with the theoretical aspects of it in due course of time and not the other way around! I still remember the dry sessions on the architecture, command formats - including every possible permutation of the subcomponents and wondering why this is all so fussy and wasn't it supposed to be fun? Only when I got my own x86 simulator on my PC and started writing programs did I realise that I was right and it was a hell load of fun! That is the way to learn. First unlearn whatever you have been taught in school and then re-educate yourself. Believe me, this is way more fun than anything you could ever imagine! - Timmy Jose.
The Will is in the Person
Because MS-DOS on Bochs on NetBSD on a MIPS box seemed like a cool idea at the time??
If we can get Mike Rowe to do an episode of Dirty Jobs on it, then it is "relevant", otherwise, no. I've done my share of keeping the pipelines full and worrying about getting to what's in cache before it's flushed, but not for a while. Frankly most programmers don't care, and they don't "need" to.
Alas, sentiments aside, pragmatically, perhaps it really is a specialty field. Especially when the number of programmers who need to know assembly is expressed as a percentage of programmers.
If I went to my GP and he happened to have knowledge of an obscure disease because of a hobby of his, it would be great, but if he said, "I dunno, here is the name of a specialist" you would take it in stride.
Knowledge builds on on prior learnings. Computer science is getting old enough so that useful work can be done without every artisan and engineer in the field needs to dissect their own cadavers to know how to do something useful.
This issue is a bit more complicated than you think.
I keep an array of all the possible values of the string, except the one that is the actual length of the string is missing. To find out how long the string is, you've got to determine the value missing from the array.
Can you make a program slower than that? What is the slowest provable program? Imagine a contest where for a specified algorithm the challenge is to come up with not the fastest, but the provably slowest implementation. It's harder than it looks.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I understand why compiler writers, driver writers, and folks working on non-PC architectures can use assembly. I also agree that it is healthy for PC programmers to learn assembly to get an idea of what goes on under the hood. But how feasible is it for most programmers to determine how their assembly will actually execute on today's superscalar, out-of-order execute, pipelined architectures, with all the hardware based optimizations? How often can you still "beat the compiler". I ask because I've often wanted to spend some time on learning assembly, but as I learn more about the current architectures this question keeps nagging me.
If you know how to do it well, assembly language programming is just plain fun and that's all there is to it. I do almost all of my programming in assembly (my company's main product is a 200K-line assembly program), officially for speed/size but honestly I'd still use it even if it were slower and fatter. I don't need compilers "protecting" me from architecture details that I never minded in the first place, and I really hate it when HLLs obscure the inner workings to the point that someone like me who's been programming for 28 years honestly can't figure out what's actually happening. With assembly I always know what the computer is doing, because it's exactly what I told the computer to do (never mind whether I was wrong). A lot of programmers really are micromanaging control freaks and assembly is nirvana for people like us.
Seriously, the way to get good results from a computer is to learn how to program the computer. These days people would prefer to learn to program some abstraction, and then stuff enough bloatware under the hood to make it appear that that's what the computer is. Great fun if you don't care about the results (Unix) and/or if you're just trying to congratulate yourself for your cleverness (Comp Sci majors), but to get real work done efficiently you have to be able to think like the machine. The really great programmers are the ones who already thought like the machine full-time anyway.
Portability -- good point, in 1980. Retarded now. Boo hoo, my IA32 code runs on only 90% of the world's computers, I sure painted myself into a corner on that one.
Anyway, what ever happened to plain old curiousity? I learned FORTH *because* it's weird and useless. I never expected to be doing everything in FORTH, I haven't used it at all in years. I've forgotten APL but it was fun having my mind bent at the time I learned it. I can't imagine how it would help my life but that's not the point. It's good for your noggin to look at programming from as many different points of view as possible.
As a marketable skill, assembly won't get you anywhere. There are a handful of places were knowing a specific assembly language is a prerequisite (boot loaders, deeply embedded applications, etc.) but these are just a fraction of the overall job-space for software engineers. Most software engineers never mess with assembly; they are, in fact, afraid of it and think that it's evil.
Given all of that, assembly language *is* the hardware/software boundary. It's where all of the fancy abstractions from CS dissertations meet reality. Understanding computer architecture is a huge asset as a software engineer, and to properly understand how software and hardware interact, you have to learn at least one assembly language. There is no alternative. For most people, it is an unpleasant experience, but the payoff is enormous. The learning process that you undergo while learning assembly will change the way that you see your software and will help you understand why your code is so slow and how to make it fast by design.
I have one last point. When you tell a potential employer about the low-level stuff that you know or work that you've done, your assembly skills are a proxy for understanding how hardware works (at least to interviewers with half a brain). If their software needs to run fast, they'll be happy that you understand the deep magic of hardware.
(Incidentally, I think that the fraction of software jobs that require an understanding of hardware and knowledge of assembly languages, linker internals, etc., are the only fun ones and the only ones worth having. So I learned MIPS, ARM, PowerPC, and TMS320C6 assembly, and they have all served me very well because I don't have to refactor C# for a living.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
Actually, it's pretty trivial to prove there is no slowest algorithm. Given any algorithm, you could run it on an emulator that would make it slower. (I wonder how may recursions of that it takes to get a 1 Hz CPU?)
There is one very good reason for knowing assembly or at least looking under the hood of whatever environment yo program in. The hardware/assembly language or whatever is the next level or more down makes restrictions on what the next layer up can do. Sometimes the restrictions can be wrong so you can have a mysterious error caused by an error at a lower level. Understanding the lower level(s) can help figure out the error.
..... ....
.... ....
;)
Fortran VI example:
main routine code:
i=3
call foobar(1,2)
j=2*i
print i, j
subroutiune foobar(l,m)
m=l
return
program outputs: 3 3
knowing what goes on in the compiler will tell you what happened
NOTE: this may not be true ofevery fortran compiler.
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.
Indeed. There's a Knuth quote I like: People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth
We live, as we dream -- alone....
high performance math libraries are often written for specific CPU's using a combination of Assembly and FORTRAN (intel MKL, AMD ACML).
The gnu implementation of the C++ string class update reference counts using atomic assembly instructions instead of mutexes (lock add).
As a guy who kept programming in assembler for many years after C was around, I would point out that BIOS code is often written in assembler becauses it is so low level and it gets used a lot, or at least it used to. Now days the operating systems take over most of the hardware after the system comes up, but in the original IBM PC, the BIOS provided the interace layer to all the hardware.
Assembly is STILL entirely relevant to programming today. Consider your programs that patch your fancy games; "Patchers" (At the very least) have their roots in assembly. Understanding how a machien works at a basic level, and understanding how to design code in such a way that it can be expanded upon and use a more efficient way of being run is still under the land of assembly.
You can do many things in C, but you can do EVERYTHING in assembly. Granted C is still (at a very simplistic level) a compilation of human readable macros that equate to assembly code.
Assembly applies if you're:
- Working with Hardware
- Looking for Efficiency
- "Learning" about how a machine functions at the very base level
- Attempting to debug an error caused by an anomalous string (Such as a null-byte.)
- Programming in general, at all
Languages like Java, while high in readability, are going to create such a problem that efficiency (one of the CORE principles when programming) will be thrown out the window. Granted Java is for cross-platformability, it is what is currently being taught in Computer Science courses. And, what truly bothers me is the fact that one can program without knowing how to do it efficiently, or without knowing how that piece of code truly interacts within the machine.
Oh, and if you're doing anything that requires massive calculations, also, assembly is for you.
Many high level languages do too much for the "programmer" hence creating monkeys that just speak a different language, not actual programmers.
I have found that assembly language gave me a unique insight into how cpus work...which has helped me with a low level understanding of how to improve my high level code, as well as giving me that extra edge for design and bug tracking.
Assembly is essential for many applications in stream processing, like image processing, audio, etc, espescially in critical loops (the data processing that takes the majority of the time in your code). I used to work at Matrox Imaging, where we had to have assembly versions of all our imaging operations to optimize for speed. We'd outpace the regular C/C++ code by FAR. Then you can also use efficient MMX/SSE operations to go through your data in a parallel fashion. It's really super interesting when you get your hands dirty with it.
P.S.: the human checks on Slashdot comments are getting really rough...
Assembly is the closest thing you can get to true machine code. If you do not understand how a computer "works", how can you truly understand how to write programs that utilize the true potential of the hardware? In these days, you use a "high level" language to write code, but it all compiles down to assembler/machine code. From what I have seen in my experience, as more and more "high level" compilers are utilized, the more bloated the code becomes, and the more inefficient it becomes. The answer is to throw more hardware at the problem, instead of actually breaking the problem down into it's most trivial parts, hence the reason I would have to mortage my home in order to afford the hardware that is required to even run M$ Vista. People these days write code in VB and .Net, because they can get a product to market in the blink of an eye, without reguard to how efficient the code actually is. I truly believe that assembler is, and should be a requirement for any degree or certification program that is in existance. I see too many people who take a training course in VB and get a certification, and then declare that they are programmers. True programmers understand what big O notation actually is, and if you do, then you also understand why assembly is still extremely relavent.
This is particularly true for programs that
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
My first language was Intel 8088 Assembler, before I learn higher level programming language It helped me a lot in understanding how computer works (Interrupt functions, Memory addresses,ports,etc). even after I knew high level languages, I was still using it to interface (It was called Inlined) with high level languages. I dunno about now, but once upon a time when you're taking computer science major, you need to read andrew tannenbaum book on how operating system works, and minix codes contain assembler.
Whoever asked this question, should also ask, why the enrollment for CS majors in universities is declining? They should also understand why they are having to outsource their employees to India, China or other countries to get the "talent" they need to write the programs they want.
Even if you're programming C# or Java the rest of your life, go learn it. The lessons you learn will apply everywhere, even if you never write assembly language again.
In college, there was a mandatory assembly language class. The assembly language that was being used was MIPS. There's probably no better assembly language to learn first, because MIPS doesn't do anything for you. You have to learn how to manage memory and registers yourself because there's nothing helping you.
However, it was taught by a professor that wasn't particularly good at it, and the class suffered as a result. I got a low grade on a test because I did this to calculate the absolute value of register "a0":
bgtz a0, label
label:
subu a0, zero, a0
"bgtz" is "branch if greater than zero" and "subu x, y, z" means "x = y - z". Register "zero" is simply a register whose value is hardwired to 0, so that "subu" means "a0 = -a0".
The reason that this works is because in MIPS, the instruction immediately after a branch executes before the branch takes effect, but after the branch condition is checked. If the branch happens (a0 > 0), a0 is negated twice; if not, a0 is negated once. The reason for this effect in MIPS is due to pipelined CPUs not being able to "stop on a dime". Learning this effect and why MIPS has this design quirk is an interesting discussion of modern processor design and very important for understanding computers.
The professor teaching the class hadn't seen this before. This is probably because "gas" actually abstracts this out: unless you use ".set noreorder", gas will actually reorder the opcodes such that your code executes as if on a traditional CPU. Professors shouldn't be teaching things they're not experts in. Also, not teaching the real MIPS hides an important computer science lesson.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
The whole point of the .NET architechture, and the Trusted Computing Initiative, is that the average joe cannot be trusted to write assembly language. Instead they should write in higher level languages that compile into intermediate code that may get JIT compiled into real code, if the module happens to be signed with a certificate provided by the certification authorities.
In a few more years, we will be lucky if there are enough people around whoo still remember how to low level code.
Mu.
Yes, for example when C++ is compiled it is converted into assembly language and assembled and linked into an executable.
So for the most part the majority of programmers don't need to know assembly language. But, it is definitively not something that should be abandoned because without it making more efficient / optimizing compilers and the like would end.
There is a big difference between a programmer and computer scientists. I think that it is very important for a computer scientist to have a good understanding of how assembly language, and in turn machine language works for future develop of the science of computers. Though, if your goals are to be a Java or C++ programmer then I think you could do without every learning about assembly language.
Nick Powers
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
Which is why you get power stations using twenty-to-thirty-year-old systems for controlling equipment. I don't believe there are any that still use TRS-80s, but Windows NT 3.x is widely used for mission-critical systems. Why? Because it works, it's a known quantity, and it's much more solid than any later Microsoft product. I've seen hospitals use MS-DOS for medical imaging. Why? It has many defects, but fragility isn't one of them.
What about corporate desktops? Every time a machine blue-screens, it costs the company money. Time is money - and lots of it. Ten minutes of downtime may not sound much, but that's ten minutes of productivity lost. A sales rep or an engineer using nothing more than a pad of paper can earn small fortunes in ten minutes, but the same person in front of a blue screen can do nothing. They become dependent on the technology, so the loss of it means the total loss of activity. Depending on the size of the company, ten minutes could be worth anything from one thousand to a hundred thousand.
Chances are, you'll have more than one application crashing hard on one desktop per year. For most corporate applications, if they can get away with a net loss of one day's loss for every hundred days worked, they're doing well. After a single year, that's 3.65 days (about 525 minutes) that are probably going to be wasted from downtime. At the conservative estimate I gave, that's over half a million per year. For a major corporation, it's probably closer to thirty million. That's every year.
Do you know how many semi-trained programmers you could turn into seasoned, high-grade professionals for thirty million dollars? And you only have to do that once. They don't need retraining the next year. One company's losses for one year, if spent on raising the bar instead of drinking at the bar, could slash corporate losses from downtime across the entire industrialized world. The money saved from improved reliability would more than cover the cost of the work.
On the whole, code monkeys produce products that help earn $1 for every $2 spent. That is not a good return. Businesses may want the software fast, but it hurts them, it hurts the economy, it hurts the shareholders, it hurts the consumers. If you'd earn more money with an abacus and a stack of post-it notes than with the latest copy of Vista and a quad-CPU, quad-core PC, then don't throw good money after bad. If you'd see better profits from a slide-rule and a stencil set than with the latest AutoCAD, then don't upgrade.
I'm in favour of technology and am certainly no Luddite, but the phrase 'no pain, no gain' does NOT mean that if you suffer horribly, you will get something wonderful. If you suffer horribly, the odds are very high that suffering horribly is ALL you will get.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
using a computer is an exercise in thinking in a particular way.
if you learn to program in a high-level language, you find day-to-day use of the computer much easier. your mum and gamer friends start to call you because you seem to be able to 'just work it out' even on an unfamiliar system / OS (alright, except windows. but windows was written by marketing droids, not programmers. that thing is the work of the devil). learning to program taught you something about how other programmers think, so working out what might be going wrong on your mum's computer gets easier because you have some sense of what the possibilities / constraints are.
if you learn to program in assembly, you find programming in high level languages gets much easier. your mum calls you to help work out what's wrong with her latest php code, even though it's not a language you're super familiar with (your gamer friends are still useless morons though). learning assembly taught you something about the building blocks of high level languages, and you have some sense of the underlying structure and constraints associated with any high-level language.
assembly is an exercise in thinking in a particular way. it's a way of thinking that facilitates anything 'higher level' with computers, be it programming or simply using one as a tool.
and it's fun.
Pprogramming PCs can be done quite quickly and easily with drag and drop Visual programming, which makes Assembly Programming a bit too slow for most people ... but what about programming robots or large mainframes instead of PCs ???
... it would not interface ... since Chinese Mandarin is my 5th of 6 languages, they hired me to rewrite the controlling software ... and they actually wanted it done in Assenbler! ... but yeah, MS Visual Studio gets called for with almost all my other programming ...
As a programmer with a Ph.D. in math, I like Assembly Programming, but seldom actually get the chance to use it (other than one or two drops to it within Visual C for some special subroutine). The last time was for a medium sized company here in Montreal, when they bought a robotic spindler from China. I was supposed to take a spool of wire and wrap it to make any one of a large choice of electomagnets or electric motors
A warrior's greatest weapon is wisdom, therefore, keep your mind even sharper than you keep your sword.
There are two simple reasons.
"Consider the following question given the current hardware development needs, and also the claims of the transistor lovers for it being a device that gives one insights of the internal working of a computer. How relevant or useful is it to learn BJT transistors in the current era? "
You don't have to know everything, but you should probably know something.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Theres a fortune message that captures what I feel about the C vs AL programming debate: "The C Programming Language -- A language which combines the flexibility of assembly language with the power of assembly language".
In my experience, one cannot truly understand C without knowing AL programming. C is like a thin macro layer of sorts over the AL underneath. C is a systems/low-level language because it abstracts what most contemporary processors can do in non-privileged mode - access memory, evaluate expressions, change the flow of execution, make sub-routine calls. C does not provide I/O features or knowledge of any device semantics other than the CPU. Therefore to understand C one must know what it assumes the canonical processor can do - one must know atleast one AL well. I know atleast 4 ALs well and I feel I understand C better for it.
Further, to understand or define UNIX on an ISA - even at the application level - one needs to not only know C, but also the ABI - the implementation of linking calling and register use conventions - for that ISA. Try making sense of a core-dump - especially a core-dump from a production site where debug symbols would have been stripped - without knowledge of C and the underlying AL conventions used.
To me C & AL together define UNIX on an ISA. So without AL, I'd feel pretty ignorant.
veliath
You do not even need know it to create one - I have written a small high level language that "compiled" to python. There was no need at all to learn assembly, only to know python and language design. It isn't terribly uncommon for obscure or in house languages to compile to ANSI C, both because that is quite portable and the compilers do an extremely great job of optimizing code. For a language creation Formal Language is MUCH more useful and you pretty much never touch assembly in that and you may not even touch it in compiler theory. I know there are compilers out there that compile to an intermediate internal language that is then sent to the "real" compile part. It is only useful if you are compiling direct to assembly and then good knowledge of it is only useful if you want to optimize the binary.
Though, I do agree that Assembly is useful to know and I do not care about what microprocessor you use. In fact, it is also good do have some idea of micro-code. When I was in college (not that long ago) we used a processor simulator and wrote our own assembly language in micro-code. We then wrote a small assembly program that ran on top of that processor. For the students who didn't know any of this stuff you could see a few light bulbs go off - "Ahhh, so *that's* why I have to do it this way".
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it
of course there is a need for it. There is more to programming the desktop applications you know.
The Kruger Dunning explains most post on
If you don't know assembly, you don't know how to program.
...or hire 3 foreigners to write something kinda like assembly.
"It has to compile too?? so many requirements you Americans want..."
That has got to be the most useless set of tags e v e r!! 'Yes, very, no, maybe'. C'mon guys, you can do better than that.
None of this separate tags bit. When I want to find 'controversial' topics, gimmie a tag to use (not 'controversial'!)... use 'yesnomaybe'!
I haven't used assembler in a long time, though it has it's rewards (it was /fun/ when I did it) the fact is, there really isn't an actual use for
actually
it in modern desktop machines.
However, I don't regret learning from assembler. I remember once writing two
routines to do case conversion, one involved calculation the other involved a
no-brainer lookup table.
Logically, the no-brainer should have run faster, but it was slower.
Understanding the value of branch prediction, conditional jumps and processor
cache is a lot easier having written those two simple routines. A useless
program, but it makes other things make sense.
Put it another way, is addition relevant now that we have calculators?
The particular instance I had in mind was a subroutine which built up a 500 byte string from several dozen strcats.
You might want to pause a moment before writing next time. You might want to absorb the gist of what you have read rather than pick one small part and assume the writer is clueless. You might instead think of the writer actually having said something useful and consider that maybe you need to adjust your perceptions a bit rather than throw out gratuitous fatuous comments.
Infuriate left and right
Dumbass. You have no idea what you're talking about.
Om mainframes assembly is still used. More than on *nix. Assembly on mainframes is backwards compatible. There are programmers out there that are still more knowledgeable about assembly on the mainframe than say C. Writing intermediate to good C together with the optimisation capabilities of the compiler should do the trick but still sometimes assembly is still preferred.
For instance, I have seen code written in assembly for base64 encoding/decoding. Reason for doing so is to allow encoding/decoding to take place in a CICS transaction (which must be completed as quickly as possible.)
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Well, yes. I still program in assembler now and then. Despite all the boasting about how good compilers have got, they still lag well behind humans when it comes to getting that last 300% out of some critical routine. (Yes, a 3 fold improvement over a good C compiler is typical).
The big advantage of learning assembler programming is that you'll learn to think logically, and how to minimize your solution effort. You do actually have to think about what you are doing, the compiler or JRE won't save you here.
I dunno -- I still would like my onocologist to understand on a fundamental level how RNA transcriptase works and the biophysical interactions that take place during radiation therapy. I want my psychiatrist to understand why inhibiting serotonin reuptake is sometimes desirable. In fact, I want them to have a deeper level of knowledge and understanding of all these concepts than my own.
Same thing for programmers. The best professionals in any field will have a very deep understanding of their knowledge domain. A programmer doesn't have to go down to the level of electrons on bare wires (the electrical engineers can do that) but at least should have a feel for what they're doing down at the level of registers and operating system.
it's a blue bright blue Saturday hey hey
If you're trying to do anything in the microcontroller/DSP world and aren't willing to at least look at you device's assembly dialect, your colleagues will consider you a C-idiot.
Assembly is very useful for things that need to be fast (as in: X needs to happen within Y processor cycles of event Z), fast (as in: this calculation may only take X% of the CPU cycles), small (as in: the whole program needs to fit in 2 kB and use less than 128 bytes of RAM), to check if your compiler is buggy (yes, that really happens), or if your compiler simply doesn't know 50% of the processors instructions (yes, that really happens. And yes, the compiler was made by the company that also makes the chip in question).
Of course, much of the uC/DSP code can and is written in C. But the programmer needs to keep the assembly in mind when writing C (it's hilarious to see people try to program an 8051 who have only learned "C on the PC"), and know when assembly will do a better job.
Assembler is brain-food. It is a challenge where you're on your own with very little of the modern comforts that people take for granted nowadays. This trains you not to be sloppy, to think before typing, and keep baggage down to the minimum you can carry. Out in the wilderness you can reach places the air conditioned coach tours don't go; but the real value of giving everyone an opportunity to write in assembler is what you learn about self discipline, good working habits and how much you can cram in your brain if the conditions are right.
First:
I spent a good few years writing ISRs (Interrupt service routines), TSRs (Terminate and Stay Resident apps for DOS), simple device drivers for serial and parallel ports on the DOS based PCS.
Pretty much all of what I worked on is now obviated by having an operating system that works. (mostly works)
There are a LIMITED number of roles for assembly writers in embedded systems, but pretty much all device drivers now are written mostly in C or even C++; Many embeded systems use C cross compilers.
Second:
By redesigning a function that some had written, I took the execution time down from 32 seconds to 100ms (I stopped timing after that). Poor design trumps poor coding in terms of performance EVERY TIME.
Third:
Doing ANYTHING in assembly take N times longer, where N is just HUGE. Really, HUGE. If you can do it in a high level language, then writing it in assembly is either a hobby, a college project, or a waste of time.
Having said that...
I believe that writing that all that assembly gave me a very good grounding in what goes on inside the box.
But writing assembly teaches you Nothing about Ojbect oriented Design.
Should we teach maths students to differentiate, or just tell them to used the computer ?
Teach assembly, but don't use it any more than you would calculate Fischer Exact Test for association by hand.
Don't. Not unless you _REALLY_ have to.
http://davesboat.blogspot.com/
Here is an (very old) joke from an (very old) assembly programmer I met once: "Mr Push and Mr Pop are in a boat. Mr Pop falls in the water. Who pushed him ?". Ah, ah, funny, isn't it ?? Assembly is so funny.
-- Rastignac was here.
Good luck. Actually tried once (for an x86-64 assembly task), and had problems to find someone. Finally found a coder who did decent work, but there seems to be a significant shortage of assembly coders to hire.
Prove it.
FORTH is assembly's version of meta-programming. You can pretty much define your own opcodes. May lose a bit in speed, but I've heard it works great for low memory systems.
I love articles like this where all the (low numbered) old dogs come out to play with the pups.
-- I have a private email server in my basement.
I program in assembly all the time.
Why? I create small embedded systems and often C is not an option. Like it or not. Not everyone programs PCs.
PS. I am paid 50% more than what the guy in my office that can't program assembly does, even though he has been programming longer.
Well, it is an option, but the more expensive one. If you do embedded systems, you're selling hardware and software at the same time. The software is developed once, but the hardware needs to be manufactured for each single unit you sell. If you can shave $.50 off the hardware costs by using assembly (since you can cram the program into the 16 kB version instead of using the 64 kB one), and you're planning on selling a million units, you have a $500k incentive for using assembly. $500k does buy a lot of engineering hours.
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.
Don't forget the cost of all pairs of instructions, and pairing/interleaving of instructions, and memory-reference-density of instructions, and memory reference order, and branch prediction miss penalties, and...
You can program without understanding how the hardware actually executes your code. But a "good" programmer? No. A hack (and not in the complimentary sense) at best.
The one who posed the relevance question is actually asking 2 questions. One about relevancy in understanding and capability of programmers in general, and one about usage in the real world. I guess both are, to some extend, relevant.
Basically - and this coming from one of the bastards that "make you study it in one of your college courses" - you need to have at least some understanding of how a CPU works when you call yourself a proficient programmer. If you never 'got it', it means you don't understand what's going on. You may think you understand frameworks like
If you however know what is going on on the lowest level, you will know where to look, what to expect, and how to solve and issue. You will have more confidence, make planning a more accurate game, and basically be a better asset to your project.
It makes a huge difference. The people that don't get it right, will probably never want to. It's not hard, it's just a different way of thinking about constructing programs, and it requires a little more work.
Usage relevancy is already mentioned in parent post, so +1.
With great power comes great electricity bills.
That doesn't make strcat() bad, that just means the architect and/or developer of that algorithm is a dumbass.
Writing assembly in Windows NT/2K/XP/2003/VISTA does not have to do with any 16-bit code, or any DOS-like interface. You use the Win32 API as in C. In the worst case, you might use the NT HAL, which is an API like win32 as well.
Even writing Windows kernel drivers is very straightforward and has nothing to do with DOS.
Ask yourself these questions: Would you employ a carpenter that cannot hit a nail into a piece of wood. Important, even though they may use a automatic nail/hammer driver nowadays. Would you let a surgeon operate on you who did not know the human bodies internal organs. Would you let a plumber fix your plumbing if he could no put two pipes together. Even though nowdays we have plastic push & fit pipes. Good code generators must be used nowadays to improve productivity, however, when performance goes downhill, must be able to understand assembler and computer architecture to fix it. Otherwise just buy a faster CPU. Buying faster high Ghz CPU's are just bad for the environment (heat, cooling etc) so the bad coders keep the hardware suppliers in business.
Usually assembly is just one of many things you need to be useful at to be a software developer. Not many jobs out there just for assembly programmers.
And yes, it's still important. Knowing how processors/computers work is step 1 in figuring out efficient algorithms.
To stoke the fire, C is still important.
Tom
Someday, I'll have a real sig.
... the same thing I said around 10 years ago, Assembly is the absolutely best language to know, and the absolutely worst to write something in.
But I would like to sum it up as
"There are good programmers and excellent programmers that really understand what they are doing. Those understand assembly."
There is simply no other way to know what makes PIC, Power, MIPS, SPARC and x86 different from each other. There is simply no other way you can understand the trade-offs of many different architectures.
I started programming with the 6502. Did some x86 too and never touched it again, but it gave me and my generation the current "widget pusher" programmers can't match.
And don't get me started on how productive your java object-persistence engine can make you. If you don't see your computer as something moving and adding words (64 bit wide these days) back and forth, you really don't get what you are doing.
http://www.dieblinkenlights.com
...at least if you ptogram in C/C++. It's so easy to mess up the stack. Being able to understand what's going on is a necessity.
I'm building my own computer (no, not getting some random PCI cards and plugging them into a motherboard), but designing a simple Z80 system for fun.
0 -Project-Pages/Image19.html
If you want to mess around with this sort of thing, you cannot avoid writing things in asm. I've got this far:
http://www.alioth.net/Projects/Z80/Z80-Project/Z8
- having laid out a double sided PCB, and got everything shoehorned onto a 160x100mm 'Eurocard' sized motherboard.
However, I've also retargeted the z88dk (Z88 Development Kit, originally designed for the Cambridge Z88 portable computer) to my Z80 board because while it'll be best to have all the low level stuff done in assembly language, writing things that use floating point will just be ten times faster to write in C.
But even if you never intend to hack hardware, it's still important to at least be familiar with assembly language - if only to know why unchecked buffers are bad. If you've ever written a program in asm and accidentally overwritten the stack and tromped all over your return address, you fundamentally understand why this is a bad thing. We've got into a whole world of hurt because many programmers didn't understand this.
Oolite: Elite-like game. For Mac, Linux and Windows
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?
Now I'm picturing something like Alfred Hitchcock's The Birds, only with ZX81s.
I have a TI-86 graphing calculator that can be programed in assembly, would this be a good starting point for learning assembly?
The calculator has a 6 MHz ZiLOG Z80 processor, 96KB ram. and a 128x64 pixel screen.
OK, First of all I'll blow my own trumpet. Over the last 20 years or so I've programmed 6502, Z80, x86 (16/32/MMX/SSE/SSE2), ARM and various proprietory SIMD & RISC machines and pseudo-MIMD machines. TBH the payoff for these skills simply isn't worth it.
;-)
As an asm coder I _may_ find a full time job but asm will take as little as 10% of my time. Contract asm work is out of the question and I haven't seen any in years (since I wrote a serial port driver for Win3.1). I actually like programming in assembler but for the sake of my pay packet and career I have reskilled in PHP, MySQL, CSS, XHTML, JavaScript etc simply because I can find contract work that pays well. Something that appears unachievable with asm. Maybe this is why we are a dying breed.
Lastly, you're right. This discussion crops up so frequently on BBS's, Usenet etc. It seems that the answer must be that asm coders are still needed and asm is still relevant! If they weren't why would we be discussing its relevance!
Incidentally, if anyone would like to hire an asm coder who like asm mail asm@burnttoys.net
Time flies like an arrow. Fruit flies like a banana.
Actually, with gcc you _can_ access DCR on a PowerPC from C.
:-)
It's something like:
#define mtdcr(r,v) asm("mtdcr %0,%1" : "r", "v")
(I can't remember the exact syntax, but I'm doing this at work. It's funny putting things like isync in your C code
Assembly is useful in High Performance Computing. On a multi million $ machine, a few percent of peak performance means real money.
Good assembler can occasionally give speed ups of 5x to 10x over C/C++ code (code dependent statement of course)
That is significant on machines like BlueGene / Cray or even just your local cluster.
Compilers don't write and compile themselves.
Most people don't even think inside the box.
No. And that is the difference between machine code and any other language:
There is nothing to interpret.
The majority of the CPUs has zero degrees of freedom when executing machine code. Every code sequence will cause the CPU to perform exactly the memory accesses and register manipulations that are specified by that code sequence. A "MOV #0, A" will do one thing while an "XOR A, A" will do another thing, even if their end result may be the same.
If you have CPUs that take several clock cycles per instruction (like a good old '51 12-clocker), then you will even have to know what exactly happens at each of the cycles if you want the CPU to play well with the rest of the hardware.
And by far the easiest way of knowing the costs of the operations is to know what will be produced when the application is complied.
Knowledge of assembly language is probably the easiest way to know this.
thank God the internet isn't a human right.
If you do any embedded work, knowledge of assembler will come in handy.
Some low cost debugging tools do not support source debugging and you
have to look at your breakpoints in machine (assembler) code.
Also the day will come when a bit of code looks like it should work but
doesn't because the compiler screwed up and optimized your logic out of
existance. THEN you need to be able to compare the generated machine (assembler)
code against your source code to find the problem. This has happened to me
several times (AVR-GCC).
I've just spent a working day pouring over the disassebly to find out why a particular method was unexpectedly slow, realising that MSVC++ is doing an absolutely awful job with STL iterators, changing it to use plain arrays, and ka-ching!, 25% speedup. :) So yes, I think it's relevant.
I am a kickass programmer, that is why I am spending my time writing comments on Slashdot. When I was only 2 years old I had created my first hello world program on a computer I had created using nothing but pinball relays and twine. Did I mention that I invented the first Apple computer? I gave credit to Steve Wozniak because I am a charitable person and I have no qualms about the size of my programming penis.
So, about this assembly language thing. If you want to be a good programmer (like me), you will learn how to do assembly language for every single processor -- including ones that were outdated 30 years ago. Let me put it this way: you are a moron if you don't know assembly, and you are an even bigger moron if you don't write your own webserver, compiler, and quantum computer on a daily basis in assembly -- like I do.
You young whippersnappers don't understand that real programmers carry data between registers in leaky buckets uphill both ways.
Listen, my programming expertise might appear like it is drawn exclusively from reading wikipedia, but I assure you that it is much much greater than that!
Did I mention that I wrote my own webserver in Brain****, it is more secure than OpenBSD and runs in 8k of ram?
Oh, and yes, I am not insecure about my job position, my achievements in life, my salary, or the intelligence of people younger than me. I am most certainly too busy being successful to write this comment on Slashdot to impress other successful people who write thousands of lines of x86 assembly that run missile silos and medical equipment.
Someone once said that on the internet, everyone has a 12-inch constantly hard penis. All of the other suckers have to lie about it -- with me, it's the truth!
By the way, I rock. I am cool. Really, I'm not a loser.
There is a plainly understood reason for why this is so. Assembly language while being archecture dependent offers too much ***power*** to the programmer. Think "Atheros HAL" and FCC regs. Someone knowing assmebler could (already has been done) hack the code to let the wifi cards do things that are federal no-no's. This is where public policy quietly and with little notice piggybacks onto market forces. To the tyrant, everyone is a criminal and everything is a weapon. Therefore: A well-regulated militia being necessary for the security of a free State the right of the people to keep and bear arms (assembly language skills INCLUDED) shall not be infringed.
Learning and using assembly language is a political act. Enjoy it.
Submission as evidence constitutes plaintiff and/or prosecutorial misconduct.
For use in Operating systems you will be better off using C for the most part and assembler where it is needed. Most mortals aren't so good that they can beat a C compiler at optimizing, so they are better off using C, as a bonus the code will be more readable and you will be more productive.
For library routines, for instance graphic routines assembler rocks, but here also assembler is mostly useful for the inner loops only. The biggest optimizing gains can be achieved at medium or high-level code, if your software algorithms suck than assembler sure won't help.
And yes I do have a talent for stating the obvious... i know. ^.^
..and I took a basic assembler course in my last year. Though I can safely say I will never program in assembler, the insight into how data is stored in memory (little endian, for example) is important. Also, programming in such small steps allows you to appreciate system resources. It has made me a more efficient C-language programmer. I do not regret my choice, and as long as computers still operate on the same foundations they always have, assembler will always have it's place.
Blerg.
You accuse some people of not really understanding whats going on but you yourself don't appear to understand the reason some things are done as they are:
"Never mind that the new end of the first string would be very handy for the next strcat to that same string.)"
Yes , but only if you wanted to use another strcat() immediately afterwards. Aside from in that case the pointer would be fairly useless. strcat() like a lot of routines returns its argument so you can pipe stuff together without having to use intermediate variables. eg:
void func(char *teststr)
{
char str[100] = "hello";
if (!strcmp(teststr,strcat(str," world")))
{
do something
}
}
Obviously thats a contrived example but you get the idea - no intermetidate variable required , the 2nd parameter passed to strcmp() comes (hopefully) straight off the stack, not via an intermediate.
One of the best reasons to learn to do assembly programming is because it's fun.
;-)
Though I can't say that's why I did it. In my case (back in the early fourteenth century), we all wrote assembly code because that's how serious programming was done. Sure, we had COBOL to update ledgers and write reports, and FORTRAN to take the hard work out of maths computation, but for anything that really needed any kind of optimisation on those old core-memory machines, assembly was the only way to go.
There were other reasons too; I worked in a computer bureau with several Burroughs B3700 machines, and we had one or two clients for whose packages the source code had been long since mislaid.
So rather than re-writing the thing from scratch whenever mods needed to be made, a couple of us used to hack directly on the binary. It's not all that easy, but it's job security.
If you are writing software tools that place hooks into the target application (or the target runtime) so that you can monitor performance, code coverage, memory allocations, thread switching, perform flow tracing, perform debugging, then yes, assembly is necessary. I work for a software tool company that produces the above software tools targetting languages from C++ to JavaScript, Ruby, Python and Lua. To hook these languages requires assembly experience as all of these languages (even the ones that provide a helpful profiling API) fail to provide access to all the data that is needed. Thus you need to modify some functions and insert your own hooks. For Ruby and Python this is the only way to write a decent Memory Analysis profiler.
:-)
The company I work for is Software Verification, but my comments apply pretty much to most of the other companies that provide such tools. Java is the only language in mainstream use that doesn't seem to require assembly use to hook into any part of the system.
So far my favourite languages are C++, assembly and Ruby.
One of the biggest weaknesses we see in the current crop of software engineers is that anyone that hasn't worked in assembly, as a general rule, has no idea or concept of the size of datatypes and why it is important to know the size and what the implications are of not knowing the size of fundamental datatypes for a given architecture.
How big is a void *? Is it 2 bytes? 4 bytes? 8 bytes? Something else? Well that depends in the architecture. Amazing how many people can't answer this simple question, even when told the architecture they use. Then you find out they only have experience writing web applications and have never needed to know.
Nothing wrong with web apps - but you do need to have knowledge outside that arena.
So which architectures might has a 2 byte void *?
Ask Chuck Peddle
Stephen
Don't know about you, but my computer does not HAVE a hood....
I am very small, utmostly microscopic.
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.
/., not many would want to admit to being a Group 2er but I have no problem with it. For example, Group 2ers would also know when a Group 1er's code sucked, from a performance standpoint. Coders with a trailblazer mindset are rarely good optimizers.
I'm not a great programmer, but I've always had a good "sense" (for lack of a better word) about technical things. I worked a bit at a company doing mid to high level (V)FoxPro programming. They put me on the least desired machine and I set to work. Within minutes I realized the machine was not running right, CPU at 100% or close to it most of the time. Turns out it was virus-infected (despite NAV, of course). I found the name of the EXE, renamed it in autoexec.bat before it loaded, then deleted same. Problem solved and the oldest 'clunker' became a quite acceptable computer.
I think this story illustrates the two broad classes of programmers. (1) those able to get a task done, no matter how nerdy or obscure (but who are pathologically incapable of documenting their work, or teaching others) [e.g. my co-worker who had used that computer for months or years without noticing the virus] and (2) those who are good at interface, optimization, and documentation but lack the penetrating power to solve the more difficult problems [e.g. myself -- I had to leave that job because I couldn't 'crack' the OO stuff].
Speaking to this thread's main question: both classes of programmer would need to understand some assembly, but for different reasons. Group 1ers would likely end up using it (or having to debug/change it) from time to time -- and it would be no big deal to them to learn it, use it, whatever. Group 2ers would likely want to know _when_ to use it, and probably get someone else to do that coding.
In the geek cred hungry world of
BTW, in considering where Woz, Ciarcia, Kahn and Hertzfeld fit into this, I think they are Group 1ers who simply took an interest in Group 2 stuff. If you can learn both mindsets, you are one powerful programming dude, IMO. [Pity that 2ers like myself can't easily (ever?) become 1ers.] Most 1ers just want to get the job done and move on, yet so much can be learned after you think you have finished your program. [MS deserves props for realizing this and assigning a second unit to work on optimizing the code already working -- Win95 crap became slightly less crappy Win98 through this process (pdf)]
I come here for the love
If you're looking for a reason why assembly would be a good thing to learn, check out the below article from Joel on Software.
a ctions.html
http://www.joelonsoftware.com/articles/LeakyAbstr
Many new embedded applications (like set top boxes or TV sets) are done (or will be done) with 32bits processors and have a extermly high complexity. These systems you can not program anymore in assembly. You will need an higher level language for this!
Besides that, some (embeded) processors are too complicated to program in assembly. I did work on a VLW processor with 5 instructions per word. Although you could program in in assembly, the C-compiler would almost always do a much better job at it.
The original post asks if Assembly is still relevant today. I'll ask some rhetorical questions (the only kind in a blog) and see how they apply:
a nalysis/architecture/whatever). The difference is training vs. education.
n dex.html.
* Would you want an astronaut to understand physics and math?
* Would you want a doctor to understand chemistry and biology?
* Should somebody studying to be a Literature teacher take their full set of liberal arts courses, including history?
* Should somebody earning a business degree take music appreciation?
Most of us probably said, "Yes" to most or all of those above. Even if the study seems irrelevant or too "low-level" or too "high-level" at the time, there are areas of coursework that help us understand things better.
I see a lot of dead wood in the IT industry. There are enormous numbers of people who either have no passion or who do not have a deep-enough or broad-enough knowledge of computer science to do their daily data processing job well. They are dependent on others around them for everything, even though they may be very skilled in one area.
By having both a broader and a deeper knowledge, people are necessarily better at troubleshooting and at understanding the areas outside their particular specialty. It makes them be better at all of IT and helps them do their specific role.
You should learn IT two ways -- deeply and broadly. You should deeply learn specific skills (Java/C#/Linux/Windows/scripting in Ruby/whatever) and you should learn broad skills (computing theory/relational databases/networking/troubleshooting/programming/
There is an enormous difference between training and education. Training is learning specific skills for specific tasks (narrow/specific), while education is broader and teaches you how to think, understand, and apply (broad/general).
While taking Assembly may not seem relevant at the time and you may never directly use it again, for every programming task, having a strong background in all of computing theory (including how the CPU handles its low-level instructions) educates you and gives you a deeper understanding. (Don't just be trained, be educated!)
My recommendation is the book My Job Went to India (And All I Got was this Lousy Book). If you can't afford it, read the sample chapters, especially the "Being a Generalist" and "Being a specialist" chapters at http://www.pragmaticprogrammer.com/titles/mjwti/i
Personally, unless you need the specific class/training, I'd say that FORTRAN or COBOL ought to be abolished as required material in all colleges and shouldn't be in the degree program. Those should be electives only. Assembly, on the other hand, should remain required, for a deeper and broader education. (Don't settle for a dumbed-down program).
The difference, again, is training (specific/skill-oriented/task-oriented) vs. education (general/broad/understanding-oriented). Education and being a generalist will reap large rewards, long term. So stick with it and take that class. Assembly is a very important foundation class that educates you, long-term....
Another rhetorical question I have is this: "Are you passionate for IT or is it just a high-paying (presumably) job?" If it isn't a passion of yours, find you passion and do it well. If it is, take Assembly and like it -- it'll help you appreciate IT, your computer, your high-level language, and give you a more educated view of the "soul" of your computer.
(They don't make you take Assembly at many/most schools for their health. It would be a crying shame to remove it from the required courses).
No no no. Start programming in C on a PC, and then learn assembly on a platform that's completely un-like a PC ('51, anyone ? Six different memory types is fun).
Similarly, I consider myself lucky to have English as a first language -- anything but Russian seems almost boring by comparison.
Bah. English is simple enough as far as rules go, you just need to learn all the exceptions, the pronunciation of every single word, and the huge vocabulary. Try German if you want a challenge. There's rules for everything.
And stay away from languages that are direct derivatives of Latin (i.e. French, Spanish, Portugese, Italian, etc). They're easy. Slashdotter parents? Hello???
*raises hand* Yup. My DS (I'll let you puzzle over that one. It's a common acronym on many boards, only the slashdot crowd might be utterly unfamiliar with it) is going to grow up bilingual. And I'll have to get him started with a nice 8-bit home computer once he turns 3. Hehe.
I don't know what the grandparent is having in mind, but he probably discovered in his horror that deep down ntdll.dll, it still uses interrupt to make system call to the kernel, just as Int 0x21 for DOS.
It is a standard system practice really, and it's one of the few ways that unprivileged code (user mode) can run privileged code (kernel mode). I think interrupt is preferred because it has a clear namespace in IDT compared to overloaded GDT and LDT namespace, which contain descriptions for code segment, data segment, stack, and call and task gates.
Even Linux on x86 uses a software interrupt for system call.
There is still segmentation in 32-bit x86, by the way. You just normally don't use it because your CS, DS, ES and SS are all pointing to the same flat 32-bit address space mapped and managed by page table. However, I think in Win32, FS and GS are used for thread local storage---global variable for threads.
I once had a signature.
Took Assembly in college for my Computer Science degree which i finished with in 2003... I can't recall ever seeing any jobs that required Assembly in all my job searching since then. Along with Cobol, it seems like another legacy language that is only required in very specific cases if at all.
Hey, I have a much more important question...
With the advanced steel alloys we have these days is iron mining still important? How relevant is mining, smelting, and refining ore anyway?
I work for a communications/semiconductor company.
-- Erich
Slashdot reader since 1997
The famous Steve Gibson, author of Spinrite, writes all his software (Windows mostly) in pure ASM and the speed and efficiency of his apps speak for themselves.
...because in London alone there will be, maybe, 150 to 200 JS/PHP/SQL jobs paying well whilst for embedded C/asm work there will be 5 or 6.
Thus it is far easy to find webdev work from the very outset despite the increased numbers of candidates for each position.
Also, those 5->6 embedded jobs in London will be for 1, maybe 2 companies. Basically if it say "ARM" or "Embedded" it will be Symbian. Either that or it'll be 3DLabs in Egham. Hmmm... worked for both of them already!
Time flies like an arrow. Fruit flies like a banana.
Some people say Assembly or the ghz war is over. But in some sectors they're still very important. While it might be true, unless you're a gamer, a 1-2ghz machine is more than enough to do typical stuff like web/email/aim/etc. For people who do massive parallel processings tuning a specific function with inline assembly can potentially save you time. Say you run a program on a 10 node cluster and it takes you 1 week to render a video or analyze some dataset. If there was a way to take your bottleneck functions and inline asm some of it to give you even 10% more efficiency, then you're looking at saving not only time but potentially a lot of money in electrical costs/cooling/etc. Beside that there's always the embedded world. I wouldnt want to write a VB.net on a PIC chip ;)
Also, you'll find a bunch of it in the Linux kernel code. Most of the kernel is in C, but parts just cannot be done that way... and, there, you'd better know your stuff!
Why? In an assembler, also called ASM or MASM, class the student gains many valuable lessons about programming practices. You may learn the hardware of a particular CPU or controller, but you are also learning how to design and implement a program using a low-level language, possibly with no libraries, monitor program, or OS to "handle the details" in making it work. POP and PUSH are from the stack-based CPUs, (and a few interpreters/languages) which are based on Embedded Controllers like the X86, 68000, 6502,... Not all CPUs are stack-based. B and C were designed for stack-based CPUs. C on a mainframe, or or other CPUs without stacks, don't have stack overflows. If you are using ASM on a stack-based CPU, YOU must do your own checks before running out of stack space. Developing in ASM forces the programmer-to-be to actually think about what they are trying to do, where and in what order their data is declared, and what parameters are being used in calling/called programs or subroutines/functions. Calls from external programs, or even internal calls, must be validated for length, and a sanity check performed on all values or pointers. (Language features which are standard in COBOL, Fortran, etc :-)
An experienced ASM programmer would be shocked (I was) at the library routines used by C. No wonder there are so many stack and buffer overflows. No checks are made for valid lengths or bounds of the arguments passed. New libs are now available, IF someone pays attention and actually uses them. SANS weekly vulnerabilty reports are running about 80+% in "failing to sanitize or validate user supplied data, or parameters".
People get so caught up in the bells and whistles of their favorite language-of-the-week, they forget to apply rules that would be learned using ASM, or WHY a language like COBOL defines what happens during a move/copy if the receiving field is smaller or larger than the sending. (truncate or space fill). C for example allows the programmer to create a fast, tightly-coded program, with STYLE, but which could crash when it encounters data it was not expecting-just like ASM!
Former geek, now I can rest...
If you take a look to Jonh Titor's sayings you can easily tell it is a vintage programmer in disguise. The apocalyptic situation he describes is a world full of vb programmers that need to travel back in time so they can borrow an old computer that is able to do some binary executable code translation...
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
while debugging has been mentioned here previously by people as a reason for which assembly is helpful, the majority I think are a bit out of the right scope it should be in.
:)
while for programs written in c/c++ source level debuggers are a very handy piece of work, what happens when the bug in question actually originates in the compiler or assembler putting your program together.
my logic with debugging is a layered approach, if something screws up, go to the layer beneath it to see why. long story short, when it comes down to the lowest level, your dealing with machine code, to debug that it helps to understand it
You can program some of the larger and more powerful micro-controllers with languages other than assembler. But even then there will be parts of the main routines, or O.S. if you want to call it that, that you may want to write in assembler just to get the speed and efficiency of assembler for. In particular things like interrupt routines and the low level routines for lighting a LED grid would be written in assembler.
If you get into the smaller, cheaper micro-controllers, like Microchip's PIC controllers, you will probably always be using assembler. But the job of a smaller micro-controller is simpler, it is more of a customized piece of circuitry for your circuit, rather than a full-fledged computer. A motor controller for reading the pulse-width generated signals from an RC controller to operate a large DC motor for a battle robot is a good example of a small micro-controller that does a simple but important job. Assembler runs fast and does the simple job of reading the input signal and generating the output signal better than any higher level language could handle it.
-- ssoorrrryy,, dduupplleexx sswwiittcchh oonn.. -Quote found on actual fortune cookie.
Previous replies have covered the conceptual justifications. They make sense and can be summarized by the dictum: effective tool use is proportional to the depth of their user's knowledge of how and why they work.
In the land of high performance computing (HPC aka supercomputers) time quite literally is money. The longer it takes your application to solve a problem, the more it will cost in real dollars and in missed opportunities. 99.9% of your application code will be written in a higher level language, but if you want to find out why the compiled code is not getting peak performance you have to read the assembly code.
The more complicated a chip is, the more difficult it is to write a generally effective compiler for it. Itanium (and now the new multicore chips) are well publicized examples where maximum performance cannot be achieved without deep knowledge of the hardware and how the compiler interacts with it. This knowledge cannot be achieved by ignorance of assembly code.
Awards and accolades in the HPC community go to the people who can make all the hardware, right down to the bare metal, sing to their tune.
Chances are that you'll never actually have to use assembler in your professional life. However, learning one of the simpler assembly languages (eg. the 68k processor family) provides insight into the inner working of the processor. And that in turn can help in understanding programming language features, OS/driver code, etc. For instance, I never really understood C pointers until I learned assembler.
If you only ever plan to play in the highly abstracted realms of Java/Perl/Basic, then you could probably get by without it. But if you think you might ever deal with C (or even C++), any amount of embedded programming, or situations where processor efficiency is crucial, then you really should familiarize yourself with assembler.
"How relevant or useful is it to learn Assembly programming language in the current era?"
Pretty amazingly relevant actually.
Since the point of Assembly is to have a pretty much one to one relationship with the machine code of the target processor and all languages have to produce (or in the case of an interpreted language string together at run time) machine executable code at some point all programmers are essentially writing in assembly already. Compilers, interpreters etc are an intermediate stage designed to save the programmer work.
There are two points to remember when discussing these intermediate coding stages: firstly you don't get portability, high level coding, object orientation or other benefits at no *cost*. There is always a trade-off between program size, program speed and ease of code generation. The second point to remember is that a lot of us assume that the compiler will do a pretty much perfect job in the conversion to assembly without first having a look at the actual output of our favourite one.
As a final note, remember that that which looks beautiful, elegant and simple in a high level language can look like a dog when it comes to the assembly output or in execution (think recursive functions).
To understand these points and make the most appropriate language choice for a given project there is simply no substitute for an understanding of Assembly Language. It's like trying to say you can learn to program without bothing to 'look under the hood' at all that ''Boolean logic'' stuff!
Btw. 'Learning Assembly' means writing some real projects with it - not just reading about it in the bathroom for a couple of dumps.
You need to understand assembleur to write a compiler. And you need a compiler for this new language and operating system that is going to beat Microsoft, Sun, Apple, and IBM. But you also need verilog and VHDL to design the new CPU that is going to beat Intel, IBM, Motorola, Arm, and others. And a degree in materials to design a better silicium cristal. And a degree in business and finance to sell the thing. Otherwise, agriculture still needs arms. And lots of work too in water adduction and treatment. House building, too. Good luck.
I've never done much in assembly, and what I did was a loooong time ago. But I *do* know some, and it is important. Here's one example of why: a number of years ago, at one job, some younger consultants came to me (as the senior tech resource) to tell me this one program kept crashing, and it was doing so in a linked-to commercial library (Tuxedo, if you must know), and they had no idea why.
I proceded to run the program under the debugger, got to the library call, and then did something they had no idea you could do: stepi, and stepped *into* the library, with the debugger doing the disassembly. I worked my way through and found the function it was cratering in. Now, I had no idea of the purpose of the function, and there were no comments, of course. But had the authority and the knowledge to call BEA support, tell them I needed info from their developers, and could tell them both the name of the function, and though I wasn't familiar with assembly on a SPARC, I could still offer them some variable names, and about where it was happening.
Within a day, I had the answer, and that's with waiting for a callback from tech support. Try *that*, if all you know is OOEmeraldSerpent++#....
mark
Where would all our cracked games be without ASM?
To drive a stick, you don't need to know how an engine works.
You do need to know to be gentle with the clutch without riding it, and you need to know that if your car sounds a certain way or feels a certain way it's time to change gears.
Engine louder than "normal"? Up-shift.
Not accelerating fast enough? Down-shift.
Is the car vibrating? Down-shift
If you have a tachometer, is the needle above X? up-shift. Below Y? down-shift. Don't worry your sweet little head what the tachometer actually means.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
You can fire up an emulator and start with something simple like Machine Language for Beginners...
Or download the PDF of The Art of Assembly Language from the book's fugly website.
Now don't think I'm suggesting that we should all of us write lots of code in assembler. What I am saying is that we should know how to write assembler code, and (more important) how to read assembler code. Until a programmer understands at least something of what is going on unter the hood s/he cannot appreciate the basic costs of high-level language statements.
Ian D. K. Kelly
idkk Consultancy Ltd.
"Quality through Thought"
You must have had really poor C programming and operating systems classes if you didn't get most of that without knowledge of asm. The only thing that you can't really do well without knowledge of assembly language is write a compiler.
A basic C class should expose you to debugging and the three memory related issues you brought up. A good OS class will teach your about threads vs. processes. A good class on archetectures will teach you the general differences between historical hardware and how basic things like virtual memory and context switching works. Any low-rent school that fails to cover all this material effectively outside of an assembly class isn't going to do a good job explaining it there either.
There are really only a couple of things I got out of assembler that I didn't get out of other classes -- how function calls work (and how much overhead is involved) and how memory alignment and data packing differs from architecture to architecture. (In other words, why you can't just dump memory structures into a file and expect the data to be easily readable cross-platform even if you pay attention to LSB vs. MSB).
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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.
Ozgur Uksal
http://www.adobe.com/
I would say that in probably 90% or more of all applications, Assembly is unnecessary. In the last fifteen years I don't think I've had to use Assembly to solve a problem at work even once. Then again, typical business applications don't (now) need Assembly language. Over twenty years ago I worked for a bulk-mail company in Long Beach, California that did mainframe applications almost exclusively in IBM 360 mainframe assembler, we probably could have used COBOL but BAL was the shop's language.
Now, if your shop's language isn't Assembly then you aren't going to use it in normal circumstances. Typically you do not want to use Assembly unless unavoidable, simply because you don't want to have to support multiple languages in the code base. Also, because the level of abstractions is lower in Assembly, it takes more time and effort to do things in Assembly than it does in higher level langauages, unless you use it consistently and use all the tricks available (such as structured macros and such), in which case you'd probably get most of the performance in C with fewer hassles.
Now, there are two places where Assembly is important, if not critical. First is when you have a bottleneck in which performance is inadequate, and after the code has been optimized, you still can't get adequate performance, then you need to move to Assembly language. It's often said that when you have a performance problem and speed is an issue, you'll get 80% of the improvement from changes in only 20% of the code, thus you might need to simply rewrite a small piece of the code (in the high-level language) to get an improvement - maybe significant improvement - in performance.
I say that because you might get the code to provide satisfactory performance - without needing Assembly - after refactoring or changing it to alter how it performs. Then you don't have to support two source language bases and you get the performance boost you needed without resorting to Assembly. This option may not be available in the case of, say, programming a video card, you may have to use assembler (or data in the application which is passed to the card as a program in its native machine code, which is essentially the same thing) to be able to get the necessary performance or special features.
Also, you need to know what needs to be optimized depending on what the application does. For example, if you have a data entry program, optimizing the startup to take one minute instead of two will get less benefit than dropping the time needed to enter a transaction by one second, because (1) over the course of the day on entry of, say, 600 transactions, the time saved will be ten minutes, which would allow the operators to enter additional transactions and (2) the operators will find the application more "snappy" and have more job satisfaction. On the other hand, if the application is being used once in a while for a single use at a time, cutting the amount of time for it to startup over allowing the transaction to take longer might be a better choice, since reducing the extra minute waiting for it to start up might be more critical than reducing the time for the transaction to finish.
Second is when a particular feature or functionality is unavailable except in Assembly. If you need to implement a type of internal functionality such as a task switch, specialized error trapping, or to read or write certain machine registers, or where you need access to do I/O to a specialized device, you may have no choice but to use Assembly. This is indirectly related to the last sentence of the previous paragraph, in which the extra performance is unavailable except in Assembly. Az much as I dislike C, it has eliminated a lot of need for the use of Assembly because so many of the constructs in C are either direct representations of machine language or almost exactly implemented as the most efficient machine instructions available to perform the task.
Compilers have gotten considerably better over the years, to the poin
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
Therefore: A well-regulated militia being necessary for the security of a free State the right of the people to keep and bear arms (assembly language skills,soldering equipment and oscilloscopes INCLUDED), shall not be infringed.
There, fixed!
You can program without understanding how the hardware actually executes your code. But a "good" programmer? No. A hack (and not in the complimentary sense) at best.
That is a very elitist statement. I used to think like that when I was younger. People writing code in Visual Basic were not real programmers, only people like me using C/C++ and assembler code when necessary were real programmers.
But then I got into the real world, where results are whats important and not the way you obtain those results. I used to access the mouse using dos interrupts and wrote directly to video card's buffer for graphics. Sure it was great for improving the refresh rates of some little game I was programming, but the effort necessary was tremendous.
When I started actually being paid to write code, no one cared how I wrote their machine design simulation program. They just cared that it was done in a month. I had learned Visual Basic along side Visual C++ back in the 5.0 days (im not that old), so I knew that was the best way to solve the problem. They still use that program today to help design machines that are sold for upwards to a million dollars each. Man I should have been paid more.
Now I use MouseDown and Paint events to write my code. I use C++ every now and then to write *.Dlls and other libraries, but C# has become my language of choice. I write my own software and sell it retail now. I dont write video games, so ultimate performance is not a very high priority. I write software that helps companies run their business.
A good programmer is someone who can produce results on a schedule. A "hack" is someone who spends time worrying about memory reference densities and branch prediction miss penalties when all their customer needs is a User Interface to input invoices. In the real world people want a product, not a programmer telling them it should hopefully be done in another month.
--
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Reverse engineering and debugging of tough problems.
Programming is the battle between a stupid machine and someone trying to coerce it to perform particular tasks. Programming languages are the weapons and asm is the equivalent of hand to hand combat and it is also the language of the machine.
To survive the battle with the machine, suitable weapons must be engaged to effectively fight it. Also, to defeat one's enemy, they must know the enemy and how it 'thinks'.
Contrary to popular opinion, asm can be modular and structured and even object oriented. It's up to the author to do so as they are not constrained in their efforts by the language. Details (presumed to be irrelevent to programers) are often not hidden (to the point of near impossibility when attempting to find the needed information).
Asm like all languages has advantages and disadvantages. There are several disadvantages which make it pretty much last on the list of weapons to use. First and foremost, the code is tied to a particular processor. Second, learning an asm language for each possible processor gets to be a major burden. Third, it usually takes a much greater number of instructions to accomplish a task. Fourth, there is no handholding for the programmer or protection from their screwups.
Asm has advantages over others. It's capable of the ultimate tight fast code. It can be totally open for analysis and bug chasing and doesn't suffer from compiler errors injected by other programmers at other companies. It's a very short list of very positive advantages which are outweighed most of the time by the longer list of disadvantages.
For any of you who back in the dark ages of window's 3.1 attempted to use the borland 4.0 or 4.5 c compiler with optimization on, my condolences. I discovered one of my production programs to fail dramatically when engaging a rare command line parameter - whose only application turned out to simply be initializing an array of 10 elements with different than default values for crt display coloring. Considering that the program bombed out totally almost immediately, it was a 10 minute job to trace thru execution in asm to determine that the compiler's code generation was attempting to set in local storage, the final loop value for a register variable that had no local storage. Net result, the base pointer register value stored on entry to the subroutine was stomped thus screwing up all local variables in all higher level routines, resulting in massive program failure. Borland went through at least one major release after being notified of the bug without fixing it. I migrated over to mickiesoft's visual c after their failure to fix that problem.
There are two morals to that story. First off, knowing asm can get you through problems caused by others - like compiler vendors. Second, asm can be used to generate projects that don't have serious bugs whereas even perfect coding in a project can have serious bugs injected by suppliers of other software.
Despite the added cost of doing much asm (rather than limiting it to very small portions of a project), the costs of not doing these tend to remain with us in massively bloated and slow code requiring much higher performance equipment and in the form of never ending bugs.
Unfortunately, there's probably not even enough people capable of doing excellent asm to ever permit it to be a substantial component of any current or future projects. However, it's value in improving the capabilities of programmers in general is undoubtedly worth far more than a PE course (phys ed) or extra history class requirement in the span of a 4 year degree.
A large number of embedded systems can't do without assembly language, even if most are using C or C++. This since there are sometimes time-critical implementations that can't depend on the accuracy of a C compiler to produce consistent code. There are also cases where a C compiler may produce code that in general works fine, but can't produce code for some very specific instructions that a certain processor has. It's not too uncommon that embedded systems base their instruction set on a well-known processor, but extend it with their custom instructions for some features.
And in some cases the use of a high-level language like C is resulting in an overhead that isn't really what's necessary or even possible on the selected hardware. This may be the case for applications were low power consumption is at a premium and every clock cycle counts. It can make a large difference in lifetime of a battery-powered device.
And don't forget, even if most students aren't going to use assembly in the future you can't tell which students that will need that knowledge.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Which is as idiotic as all his articles. He thinks that K&R chose null-terminated strings because that's what the PDP-7 supported? What crap. It's a semi-low-level design that fit in nicely with their semi-low-level language. Now, you can criticize the design of C all you want (and there's certainly a lot to criticize) but to suggest that its features are driven by the architecture of an ancient, obsolete system (the PDP-7 didn't even have byte-addressable memory!) is insulting to two great computer scientists.
On the other hand, that's exactly what Joel would do. The fact that he even cares about the best way to implement strings at this late date identifies him as a clueless bit twiddler. Nowadays, a serious programmer uses a standard string library, and doesn't worry about its precise implementation. If the library is any good, it will have been carefully planned and implemented by computer scientists who have thought through every possible efficiency and reliability issue. Then it will have been remorselessly attacked by nitpicking QA people. When you go off and implement your own strings, you lose all that.
Nothing is faster or more effecient than assembly code. I design robots as a hobby. All my interface code for the sonar, digital compass, quade encoders, servos, it's all written in assembler. My "Glue" code and logic.. well that's all in C.
I never, ever had problems understanding pointers. I mean, they're called pointers. They point somewhere. You can change where they point. There's some information the compiler keeps around to tell it what exactly it's pointing at. There's a way to get at what is being pointed at.
I mean...their very name is pointers...it just makes sense. I never understood how anyone could struggle with it.
:(){
I am not a fan of Assembly but it is still one of the most widely used programming languages for hardware and low resource applications: Camera's Automobiles PCB Calculators MP3 Players Portable Gaming Devices Small Electronic Devices 90% of those use Assembly so even though they have also a non-existent purpose in any environment where C/++ is the most logical choice they still have hundreds of thousands of applications.
If you're designing bridges for a living, should you still be taking the time to learn about mechanical engineering, and the properties of metals? After all, there are "higher" concepts to consider like traffic flow, and wheelchair accessibility, and the social effects of the bridge's aesthetics, no? So why bother learning about the nuts-and-bolts details? The "best" bridge builder isn't the one who makes the sturdiest bridge in the shortest time using the least material, he's the one who picks the prettiest color paint, right?
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
Saying that a skilled programmer needs to understand the underlying hardware is hardly the same thing as saying that programming in Visual Basic is not "real" programming. The question is, do people who understand the hardware write, for example, better Visual Basic? In my admittedly limited experience, they do.
Conversely, a good programmer can certainly do "real" programming in Visual Basic or C# or even VBScript.
Producing results on a schedule is not necessarily the mark of a good programmer. A good programmer presumably is one who produces good results on schedule. In programming, moreover, a good result is reliable, effective, and maintainable, not just one that compiles and executes for a while before crashing.
Understanding the hardware is not all--or even most--of what you have to do to be a good programmer, of course. But I think one is hard pressed to be a good programmer without it.
...if you're doing it from Python
-Chris
I am one of the few programmers who still work in assembly language. I work in a specialized group at Apple that produces numerical libraries. One is the standard math library that provides functions like sin and log. Others are high-performance libraries for signal and image processing.
The high-performance numerical work requires more than just assembly programming. You also need some mathematics, understanding of processor internals and system architecture, and how to use assembly programming to get high performance. Getting the most out of a modern processor can be quite complicated. Although compilers get better, processors get more complicated, and there are gaps. Sometimes these gaps are large, so good assembly programmers can get huge performance gains over compilers. And that makes it worth paying them.
A modern processor does not just execute one instruction after another. It may start a floating-point multiplication in one of its execution units and an integer add in another. In the next processor cycle, the add may be done, but the multiplication has two more cycles to go. Meanwhile, the processor is fetching data for a load that was requested five cycles ago. It is not in cache, so you have to wait longer for it. There is a store waiting to execute, but it cannot start because it needs the multiply to finish. Dozens of instructions are in various stages of execution at one time.
Good compilers "know" some of this, and they can do some instruction scheduling to reduce some of the wait times. But they are not great, and programmers can do a lot more. They can rearrange data structures or patterns of use so that data is in cache when it is needed. They can overlap different parts of their code so that while that store is waiting for that multiply, a different multiply for another set of data can execute. Some compilers might spot a few of those opportunities, but a programmer can rearrange code in ways a compiler is not allowed to. A programmer might know that a load is reading from a different address than a store is writing to, so it is okay to move the load instruction ahead of the store instruction. A compiler is not allowed to make that assumption.
Compilers are also not good at using Single Instruction Multiple Data (SIMD) instructions (as in AltiVec or SSE). SIMD exists because the control logic of a processor is very complicated -- a lot of logic is needed to keep track of which instructions have started executing, what data they need, what other instructions depend on their outputs, and so on. Some processors have speculative branching; they "guess" which way a conditional branch will go and start work early on instructions along that branch. If the guess turns out to be wrong, they have to throw away the speculative work and restore to an earlier state -- processor contents, flags, everything has to appear as if the branch had never been taken. That takes a lot of silicon. So one way to get more work done without creating more instructions to be kept track of is SIMD instructions -- one instruction does the same operation on multiple pieces of data. Processors with SIMD instructions have registers that may be 128 bits wide, enough to hold four single-precision floating-point values or eight 16-bit integers, or other combinations. Executing one SIMD instruction may multiply each of the four numbers in one register by each of the four numbers in another register.
That is great, you can get a lot of work done, but how much of your code is written to multiply four numbers by four other numbers? Most programmers just think about one set of data at a time, and that is what they write, so that is what the compiler sees. When you compile regular code, you get regular instructions, not SIMD instructions. Wouldn't you rather your code go four times as fast? If you have a nice clean loop that processes all the contents of several arrays, some compilers, called vectorizing compilers, can generate SIMD instructions for your loop. If you really want to take advantage
I've got to make this pretty quick. :)
.LIB files that define most of the WIN32API, example programs, and so on. And be sure to check out the forum.
:)
I've been programming since 1969. Started with Fortran, moved to Cobol soon after, then Assembly around 1971, all on a System/360 mainframe. Today I still do a fair amount of Asm on the big iron System/390. I've been doing x86 Asm since the original IBM 8088. I also spent several years doing 6502 Asm.
I haven't read this entire thread yet, but one thing I did notice was someone saying that Assembly is more than just machine instructions. Boy, is he right! For example the MACRO facalities on the mainframe are very powerful. The programmer can access the type, length, number of "sub operands", and assorted other information for each macro operand. He can also do "sub string" processing on the operand (or each sub-operand). This means a single macro can generate different code, sometimes radically different code, depending on the operands. The mainframe assembler also has "global variable symbols". These are used to pass all sorts of information between macros, which can again result in the macro generating different code, etc.
Another point, just bacause I write in Asm doesn't mean that my code can't be reused. I've accumulated quite a library of source code after all these years. A good part of that "library" has been tweaked, optimized, well debuged, and other wise fine tuned over time. There are certain applications where I can dance circles around even the best "hi level" programmer, as far as development time goes.
One last thing, for now. Like I ssaid I haven't read the thread, but if you're interested in playing with 32-bit Windows programming in Assembly, check out this site:
http://www.masm32.com/
Here you can download a package that contains a free version of Microsoft MASM, LINK, RC etc, as well as copy books and
I can program in more languages than I can remember. But Assembly, on any platform, is still my favorite by far. For many, many reasons...
Fell through a crack in the space time continuum in 1982?
Just a guess, but its the most plausible one I could come up with.
What a great analogy, eh ? Please upgrade my karma ! While driving a car, your view through the windshield is somewhat like a software requirements document. Your High-Level-Programming-Language is analogous to the steering wheel. The steering-stuff is like a compiler, and ultimately assembly language is somewhere near the "rubber-meets-the-road" level. ESPECIALLY because you don't directly see what's going on, it's vital to have some mental image of what's going on down there. If you know what I'm talkin' bout, you didn't need to read this ! PG
What a great analogy, eh ? Please upgrade my karma ! While driving a car, thw windshield-view is like a requirements document. Your High-Level-Programming-Language is analogous to the steering wheel. ESPECIALLY because you don't directly see what's going on in the drivetrain or where the rubber-meets-the-road, it's vital to have a mental model of what's going on "down there". PG
90% of coders need not apply
The greater majority of the remaining 10% are probably reading this article, the rest are hacking right now.
Ironic, those who don't know, don't know they don't know.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
I just don't like delay slots... I mean, I can squeeze more out of them, but I lose points on projects for using 'set' commands in the delay. I don't much see the harm. Oh well. I guess I should learn X86 as well, since the world is married to the architecture, whether I like it or not.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
I think every programmer should know Assembly and understand hardware. Many employers don't share this viewpoint, but I don't think you should limit your knowledge to what employers are asking for.
We're going to hit the quantum wall and the end of Moore's "Law" soon. The signs are all around us: CPU manufacturers throwing more processors ("cores") into chips and systems, CPU clock rate increases slowing down year over year. You won't be able to just "throw hardware at the problem" any more, in the very near future.
...
So, what does this mean for programmers?
Two things:
1. Parallel programming. You're going to have to figure out how to pull as much parallelism out of your problem (and spread that across all the CPUs you have to use) as you possibly can. However, there will always be an irreducible, non-parallel part of your program. That's the message of Amdahl's Law. Which leaves us with
2. Instruction-efficient programming for those non-parallel codes. We won't be able to make the individual CPUs go faster once we hit the quantum wall; all we can do is use what we can get out of the hardware as efficiently as possible.
Study your algorithms well, and learn assembly language, if you want your programs to run fast. Compilers still aren't that good (though I have no doubt that there will be a renewed interest in making them better so that all the programmers who can't grok assembly can still be useful; it's called "leverage").
Oh, and keep an eye on FPGAs - reconfigurable computers morphed for the problem to be computed might just be the next big thing.
my friend's dad works at EA as senior programmer. When we were talking he said that the game industry is so desperate for people who know how assembly that they can make $120,000 straight out of school instead of the usual $50000 to $70000. The main reason EA wanted assemble programmers was because C was too slow for the graphics engine part of their games, so this might not be relevent to all fields, but if you know assembly you can charge more for your services if the customer cares about efficiency because assembly is still about 200 times faster than C
Do VMMs really trap to the host OS? The reason I ask is that I recently discovered Red Pill which raised the following question: Since programs inside VMM indicate that the IDT is located at the address 0xFF......, doesn't that mean that it is VMM's own IDT, completely separate from host OS's IDT? (This implies that VMM has a driver that runs at Ring-0 privilege, among other things.) If my assumption is correct, then virtual machines are actually faster than suspected, and only the switch from VMM back to host OS is somewhat slow, requiring a change of IDT, GDT, and LDT.
What's wrong with AT&T syntax?
From what I know, there are only four differences between the two:
* Registers are decorated with %, and numbers with $
* The addressing is in form offset(base) and not [base+offset]
* Ambiguous commands are resolved using a suffix (movl instead of mov dword)
* The order of operands is swapped
Granted, AT&T syntax is used very infrequently (I've used both), but is there really a benefit to not learning it?