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? "
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
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.
A lot of languages these days are emitting java .class (binary) and letting the VM do the work.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Try the "Art of Assembly Language Programming" available free at this website http://webster.cs.ucr.edu/AoA/index.html it should get you started.
...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.
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.
what the fuck is it with pointers that is so difficult?
i'm a novice coder and people constantly bitch about how hard pointers are, so when i read what they actually are(this was quite a few years ago) I went back a few times thinking i must have missed something "....surely there is more to it than that...." i thought to myself.
Snowden and Manning are heroes.
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".
I'd have to agree with you there, and electrical engineers have to know everything from the ground up; microelectronics, digital logic, computer architecture, assembly, and finally programming languages. All of them have their uses, and when building even basic control circuits you have to use pieces of them.
For example, if I were to build some kind of light controller, I could use... microelectronics knowledge to use a BJT that drives a LED via a microcontroller. The microcontroller uses its analog to digital converter to test some voltage that in turn controls the output to the BJT. I can use some logic circuits to have serial input from a computer to control/program the microcontroller. The computer is programmed in C++, the microcontroller in assembly (or C if you have the neat-o compilers).
Even if pure software people may not have to use it, and therefore think it's irrelevant, assembly is still a big part of the picture when it comes to the nitty gritty parts of electronics design. I've used the C compilers for the PIC microcontroller and they are nice and all, but don't do anything efficient at all, don't support any power saving states, and generally needlessly use up memory. They are great to use to do preliminary design, then you can go in and do some bit hacking if you want your controller to run as fast and as cheaply as possible.
Har?
It sets the video mode to 0x13 (320x200, 8-bit color), shows the mouse pointer, and exits.
RIT, they have a fab on campus =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.
Just have your friend write a strcat() himself using C, and he'll learn where/why its inefficient. (Or he won't and he's just dense.) Either way knowledge of assembler or lack thereof isn't the issue.
It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.
You don't need to understand the dangers of lugging or redlining in terms of the mechanics of what is happening its enough to know that either leads to 'big engine problems' and to avoid them. That the mechanics involve engine strain, overheating, misfiring, etc is superfluous.
Its easy to feel lugging with just a bit of experience and even a complete neophyte knows what redlining looks & sounds like. From there on, its enough to know to avoid both.
An example: A few days ago I had to explain to a very competent desktop programmer, who was doing the unfamiliar job of writing test C code to be ported to an MSP430 embedded processor, that taking an integer modulo 1440 was a bad idea. The MSP430 has no divide instruction, so the modulo had to compile to a division subroutine made of subtractions, tests, and shifts. In this case there was a way to code the overall task that evaded the need for the modulo. When doing embedded C on a processor of that size (still a lot bigger than a PIC) I ALWAYS look at the compiler output when I am writing anything where I care about either size or speed of execution.
There's no 'PIC C Compiler' for the PIC10F200.
It's basically a little grain of rice if you buy it in the surface mount package.
A fairly powerful little grain of rice at that.
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.
]1 BIT $C030
]2 DEY
That'll give you one cricket-like chirp. Throw some more loops around it to make it repeat with the right cadence. :-)
(Remove the dots...they're there only to get the columns to line up.)
20 January 2017: the End of an Error.
I hate to think of pointers as a "representation" of something. (Disclaimer : I'm a C and ARM ASM coder) When I learnt Pascal I thought that to call it a "representation" was utterly confusing. Just call it an address, because that's what a pointer is, it's as simple as that, it's an address, it's so simple.
You just got troll'd!