Assembly... BUH BUM BAAHH

[bitwiseshiftleft]

What? I can name several reasons to learn ASM right off the top of my head:

I'll tack on lock-free programming and vector programming, where you can write it in C, but that C will basically be assembly anyway.

[b0b]

JVMs, for one, compile Java bytecode to machine code for speed.

Oh. I thought that the JVM was written in C for portability, and that the bytecode invoked pre-compiled C functions. Shows how little I know about the magic that goes on behind the curtain.

[EvanED]

What a language is compiled to is entirely implementation-dependent. Even if the "traditional" way is to compile to bytecode, this doesn't have to get one. GCC contains a Java compiler, gcj, that compiles Java to native code for instance.

[torne]

People who like to code assembly to make their code faster? Don't know what they're talking about. The complexity of the simplest instructions on a modern processor is absolutely staggering. A well-written compiler knows how to deal with memory latency and threading and such that require you to know timings of various commands to the microsecond and how everything interacts as it busses back and forth across the processor and the cache. Sometimes your code actually gets faster when you add more instructions. Or when you swap two unrelated lines.

This seems untrue to me, given that I write compiler-beating assembly code on if not a daily basis, at least a weekly one. Not every architecture has a compiler that's actually that good. Not every problem is easy for compilers to tackle. And actually, I know the ARM1136EJ-S instruction cycle timings and pipeline interlocks entirely off the top of my head, and my usual visualisation of functions is in terms of instruction cache lines.

In general I expect to be able to beat any ARM compiler's implementation of any arbitrary function by handrolling it about 50% of the time, though the speedup is only worth the effort perhaps 1% of the time. Fortunately assembly optimisation is a respectable, measurable science, as we have the profiler to tell us when it might be worth it, and to tell what the results were. (also, such neat toys as ETM debug pods, which can log execution traces in realtime and even tell you about cache misses and so on).

This is less common on x86 as compilers are generally better, but believing it's not useful at all upsets me a little. Our OS doesn't have a compiler to thank for its theoretical-bandwidth-limit-hitting implementation of memmov(), I can assure you (though those 500-odd instructions weren't by me *grin*)

[EvanED]

This is less common on x86 as compilers are generally better, but believing it's not useful at all upsets me a little. Our OS doesn't have a compiler to thank for its theoretical-bandwidth-limit-hitting implementation of memmov(), I can assure you (though those 500-odd instructions weren't by me *grin*)

At the same time, I suspect he's not too far off the mark for x86. Sure, there are plenty of examples where someone was able to beat the compiler, but at the same time, I suspect there are also plenty of examples where someone tried to beat the compiler, and their best effort was no improvement at all, and plenty more where their best effort was worse than what the compiler produced.

You make know instruction timings and such for the ARM, but to the best of my knowledge Intel hasn't even released descriptions of what the microoperations are that IA-32 instructions are compiled into on-chip. Without that knowledge, I suspect that predicting what a scheduling sequence will do in terms of performance is very difficult, and finding the best next to impossible.

[aldimond]

Even if Intel released that info there would still be a wide range of different chips out there supporting IA32/AMD64. Optimizing too specifically for any one of them might hurt your general performance.

What torne is doing probably makes perfect sense for his project though. One codebase for one specific chip for a few mass-produced products. x86 ain't the whole world.

[tendays]

People coding Intros are basically forced to write them in assembly. At least the 4K ones. You can hardly squeeze a hello world in 4K, if you write in C...

Man I need to go back to coding demos, that was so fun

I realise this is doing nothing to answer the OP's questions, but I'm feeling nostalgic: I started doing assembly on motorola 68K processors (on Amiga) - I wrote a program that would render a picture, given mathematical formulas giving the rgb intensities given the pixel coordinates. And for extra speed, the program would, at runtime, start by generating an assembly segment for the given formulas.
Also, I used to code in assembly for my HP48. Writing the program on paper, then looking up the opcodes in a book, manually counting the bytes for the jumps. And because there was no memory protection, any kind of mistake and the entire system was wiped out when you made a mistake.
That was fun, and there was no way you could get any kind of speed without resorting to assembly.

You kids with your compilers, you don't know what you're missing.

EDIT: Fixed link to make phpbb happy

[torne]

At the same time, I suspect he's not too far off the mark for x86. Sure, there are plenty of examples where someone was able to beat the compiler, but at the same time, I suspect there are also plenty of examples where someone tried to beat the compiler, and their best effort was no improvement at all, and plenty more where their best effort was worse than what the compiler produced.

That doesn't mean nobody needs to learn, it just means people need to learn it better. Also, seriously, the whole world isn't x86. Even on x86, there's plenty of opportunity to optimise if you pick the right place: the fast path for incoming network packet handling, say, if you're building a multi-gigabit-linespeed network (router|packetmangler|filter|whatever).

You make know instruction timings and such for the ARM, but to the best of my knowledge Intel hasn't even released descriptions of what the microoperations are that IA-32 instructions are compiled into on-chip. Without that knowledge, I suspect that predicting what a scheduling sequence will do in terms of performance is very difficult, and finding the best next to impossible.

It's actually not too tricky to infer what the microops generally are, given that IA-32 breaks down into 1 or 2 microops per instruction (for non-microcoded instructions). Anyway, it just moves the optimisation strategies into a different arena - instead of filling a linear pipeline your goal becomes filling the microop reorder scoreboard, which you can guess at with reasonable accuracy after you have some experience futzing with it on a bunch of different chips, and to other things like subpipeline parallelism (say, knowing that the AMD64 cores have three address generation units in parallel with their three integer ALUs, so if you pick the right operations to interleave, shifts and masks and similar, you can push the parallelism from three to six..)

It's still not that tricky to beat the compiler a few percent of the time. Even ARM has dynamic branch prediction and speculative execution now, though not out-of-order in any silicon I've seen, so my field is getting closer to the x86-like world.

What torne is doing probably makes perfect sense for his project though. One codebase for one specific chip for a few mass-produced products. x86 ain't the whole world.

Not quite - one codebase for about twelve chips (plus more variations based on coprocessor availability, cache layout, etc), not all ARM, for dozens of unique devices per year all with different software stacks, use cases and performance characteristics. Oh, and for a Win32-API-based emulator. The joys of a hard-realtime open OS platform.

[b0b]

I hacked a lot of 8080, 8086 and 68k back in the 80's. I was working in Forth a lot, and sometimes the only way to get any speed going was to dip down into assembly for the innermost loop. In Forth that's pretty easy to do. Forth's basic components - stack, return stack, ip, etc - are mapped to specific registers in the Forth kernel. So you know the state of the processor when you go into assembly, and you know (or should know) how Forth will behave when you pop back out.

Nobody writes Forth anymore, though.

[n0dl]

I just got started programming about a year ago (on my third language, C ). Here's a link I found (and one I am going to eventually use) to learn assembly
http://webster.cs.ucr.edu/AoA/

[Zanik221]

I hacked a lot of ... 68k back in the 80's.

I'm so sorry. I first learned assembly on a 68k processor. Not fun.

[b0b]

I first learned assembly on a 68k processor. Not fun.

compared to the 8080, it was heaven.

[ubergeek42]

This thread gave me the kick I needed to go and take a stab at learning asm. I chose to learn mips asm to begin with(Mostly because I've heard its easy, and partly to better understand how the ps2 works, as I do a fair amount of programming on it)

I searched around and found a really great java mips simulator/assembler called MARS(MIPS Assembler and Runtime Simulator). MIPS assembly seems so easy to use/learn(though I doubt my code would be any faster then a compiler)

[taggedunion]

There are very good reasons that we use C and higher-level languages rather than assembler. But those aren't reason enough to get your feathers ruffled because someone wants to learn it. Just like learning Lisp, even if you never use assembler, learning it is quite beneficial. It teaches you how your computer actually works. Also, it can be rather fun.

There are a few number of situations where hand coding is faster. And one should never do large sections in assembler: asm is for inner loops, inlining, little areas where -- after profiling -- you need the speed boost. Also, there is at least one person alive who can code circles around a compiler: Paul Hsieh.

Graphics & drivers are probably always going to be in ASM & C.

Eventually, though, the fun in little programs is reason enough for me.

I recommend using MIPS with SPIM emulator. It's an excellent reduced instruction set. Also, I like the Zilog-80, especially for the TI-86. There are a lot of resources through Wikipedia and Google for both.

[djn]

I hacked a lot of ... 68k back in the 80's.

I'm so sorry. I first learned assembly on a 68k processor. Not fun.

Nothing wrong with 68k. I had classes with an amiga guy (Rumrunner, from Void) for three years, and even having never laid hands on an amiga, I did get a vague idea of how it works after a while, and it doesn't seem too hairy.

(He used 68k assembly to get a practical feel for e.g. binary trees, so I might have gotten a biased view. )

[EvanED]

Graphics & drivers are probably always going to be in ASM & C.

Careful with that statement, "always" is a long time. I give it 2 to 2 1/2 decades before OSs written in C are only for antiques. Within the decade most or all drivers will have moved into user space, giving implementers much more leeway in their choice of language.

(Also, add C++ into your list; graphics drivers on Windows I belive are typically C++.)

[Rysto]

You really expect microkernels to take off? I bet that we'll be seeing OSes written in a type-safe language like Java before we see microkernels in widespread use.

[EvanED]

You really expect microkernels to take off? I bet that we'll be seeing OSes written in a type-safe language like Java before we see microkernels in widespread use.

I don't expect anything I would consider microkernels any time soon, but the move to user space has already begun. MS is actively encouraging it with Vista (I think they got tired of being blamed for blue screens caused by 3rd party driver code) and I wouldn't be surprised if they start requiring it for at least non-graphics and special purpose drivers in one of the next successors to Vista. I think there's some movement on that front in Linux too, though it's not as strong.

[Rysto]

Yeah, but doing things in user-space is *slow*. Between the costs of context switching and copying things in and out of the process, you lose too much performance.

Of course, a similar complaint exists for Java, at least for now.

[EvanED]

Yeah, but doing things in user-space is *slow*. Between the costs of context switching and copying things in and out of the process, you lose too much performance.

I doubt that's true for most things.

There are some drivers where the speed matters, for instance graphics and low-latency sound drivers. Those will probably still remain in kernel space. (Unfortunately, gfx drivers are the biggest offenders. So I wouldn't be *terribly* surprised if you see even some of these move into user space.)

But most things aren't performance-sensitive enough for it to matter. With some cleverness, a lot of the copying can be avoided too.

For instance, take my SATA controller driver. (My motherboard's too old to have on-board SATA, so I have a PCI card.) If there's an extra pair of context switches, I don't really care; if my SATA driver is becoming involved at all, that means it's going to disk, which means that it's going to be at least 300 μs before the data is ready anyway (and that's if it hits in the disk cache). Even an extra 10 or 20 μs is nothing.

[taggedunion]

Of microkernels -- they're probably used more than you might think. Mac OS X, for one, is implemented as a microkernel.

Anyone saying anything about microkernels and their performance tradeoffs and such should first read at least some of Andrew Tanenbaum's work. I just discovered his stuff a little while ago, and it's been an eye-opening experience. Even if you disagree with him, you'll know more about the microkernel argument and how they prove useful.

And,
the slow argument against Java is total crap. That started, what, in the 90s? It's been a decade! Java is the fastest interpreted language out there,* and is not that much slower than C++. And you're trading that little speed you care so much about for development time and ease. Raise of hands: who likes managing their own memory? If you use tools like Python or shell, especially, you really shouldn't complain too much about the speed hit (maybe you could complain if you were writing drivers or kernel code, but no sane person would that in anything less than C++).

* Some Lisp implementations are pretty damn quick as well.

[taggedunion]

Graphics & drivers are probably always going to be in ASM & C.

Careful with that statement, "always" is a long time. I give it 2 to 2 1/2 decades before OSs written in C are only for antiques. Within the decade most or all drivers will have moved into user space, giving implementers much more leeway in their choice of language.

(Also, add C++ into your list; graphics drivers on Windows I belive are typically C++.)

Kernels need speed, so I firmly believe that kernels will always be written in a close-to-the-machine language like C. I'm not discounting new mid-level-languages, but why reinvent the wheel when the present wheel gets the job done just fine?

Notice I say C-like language. And by that I mean a mid-level language just above assembler. One might use Lisp, O'Caml, or Haskell, but that object code would not be quite as succinct and fast as straight C (or C++ or D).

Oh, and desktop machines might evolve to higher-level languages, but embedded devices are always going to need speed and small object code. It's like how people discount RISC processors and how they "failed", but your car, your cell phone, and your game system runs on CISC processors. ARM and PPC are among the top-selling chips overall because of this (CMIIF, because IANAE).

[Rysto]

Of microkernels -- they're probably used more than you might think. Mac OS X, for one, is implemented as a microkernel.

Mac OS X runs a BSD variant on top of the microkernel. The microkernel is only responsible for low-level device drivers, VM and threading.

And, the slow argument against Java is total crap. That started, what, in the 90s? It's been a decade! Java is the fastest interpreted language out there,* and is not that much slower than C++. And you're trading that little speed you care so much about for development time and ease. Raise of hands: who likes managing their own memory? If you use tools like Python or shell, especially, you really shouldn't complain too much about the speed hit (maybe you could complain if you were writing drivers or kernel code, but no sane person would that in anything less than C++).

* Some Lisp implementations are pretty damn quick as well.

Yeah, but it's still slower than C, isn't it? I'm a big proponent of Java myself, but it doesn't give you enough performance to write a kernel in it.

[EvanED]

Of microkernels -- they're probably used more than you might think. Mac OS X, for one, is implemented as a microkernel.

"Implemented as a microkernel" is a near meaningless statement... if everything is running in ring 0, it's not a microkernel, and it loses almost all the benefits of being structured like one.

OS X at least has some drivers running in the kernel.

This site (the first hit if you Google "os x kernel user space" or something like that) says: "XNU's [the OS X kernel's] Mach component is based on Mach 3.0, although it's not used as a microkernel." Later: "BSD runs not as an external (or user-level) server, but is part of the kernel itself."

If an OS is doing that much in the kernel, I don't consider it a microkernel. (Maybe my definition is too strict, I don't know.)

Raise of hands: who likes managing their own memory? If you use tools like Python or shell, especially, you really shouldn't complain too much about the speed hit (maybe you could complain if you were writing drivers or kernel code, but no sane person would that in anything less than C++).

You don't need to do *that* much memory management in C++ either if you structure things right and aren't tied to terribly low-level programming.

There are some exceptions, especially at module boundaries, and definitely if you're dealing with C libraries.

But auto_ptr and shared_ptr are your friend, and will take care of a great deal for you.

In my experience, it's the other memory safety issues like out of bounds array accesses that are nastier.

Kernels need speed, so I firmly believe that kernels will always be written in a close-to-the-machine language like C. I'm not discounting new mid-level-languages, but why reinvent the wheel when the present wheel gets the job done just fine?

Notice I say C-like language. And by that I mean a mid-level language just above assembler. One might use Lisp, O'Caml, or Haskell, but that object code would not be quite as succinct and fast as straight C (or C++ or D).

I would argue the "just fine" statement as to the present condition; I personally think every OS out there sucks. Though to be fair, this is more because of their choice of features and much, much higher level design decisions. But I can name one OS at least that has had well more than its fair share of exploits that they wouldn't have had if they used a higher-level language that provides memory safety.

Just out of curiosity, if you're even counting Lisp, O'Caml, and Haskell as C-like, what's not C-like? Stuff like Prolog?

Also, I think OSs will go thourgh the same progression that other software did, where in the beginning everyone is concerned with performance, and goes to long lengths to get it, but after time the other concerns such as development cost, time to market, reliability, security, etc. rise to the fore. And at that point, performance will take a back seat to those concerns, and you'll start seeing typesafe languages used for most of the kernel.

Oh, and desktop machines might evolve to higher-level languages, but embedded devices are always going to need speed and small object code. It's like how people discount RISC processors and how they "failed", but your car, your cell phone, and your game system runs on CISC processors. ARM and PPC are among the top-selling chips overall because of this (CMIIF, because IANAE).

This is true. I tend to be too desktop-centric.

[taggedunion]

Of microkernels -- they're probably used more than you might think. Mac OS X, for one, is implemented as a microkernel.

Mac OS X runs a BSD variant on top of the microkernel. The microkernel is only responsible for low-level device drivers, VM and threading.

But the general effect is pretty much the same, neh?

Yeah, but it's still slower than C, isn't it? I'm a big proponent of Java myself, but it doesn't give you enough performance to write a kernel in it.

True, true. But it's not that much slower than C (or, better comparison, C++). There's greater difference in speed between Java and other interpreted languages than there are between Java and C++ and C. But, yes, not something to write kernels in, especially if it's running on a VM rather than compiled to machine code.

[b0b]

I thought that the JIT compiler used by modern Java VMs pretty much settled this issue. Is Java still slower than C++? Last time I looked (maybe 7 years ago) there was only a 10% difference between the two.

I'll tell you this: Java sure compiles faster than C++!!

[EvanED]

I thought that the JIT compiler used by modern Java VMs pretty much settled this issue. Is Java still slower than C++? Last time I looked (maybe 7 years ago) there was only a 10% difference between the two.

It depends on what you're doing. There are some things that will be faster with each. For instance, there are certain pathalogical memory behaviors that will actually be faster with garbage collection than without, though they seem relatively unlikely in practice.

I think the main complaint about Java's speed is that Swing GUIs are still noticably slower than native ones. SWT is better, but that's a third-party library (which Sun should totally adopt, because it kick's Swing's ass).

I'll tell you this: Java sure compiles faster than C++!!

But at least two years ago the compiler error messages and detection was worse than most C++ compilers. I don't know how Sun managed that, because it's a reasonably impressive feat.

The compiler is also too picky. And the language is obnoxious.

[Rysto]

SWT requires manual memory management, though. Ew...

[taggedunion]

From my understanding, Mac OS X is for the most part implemented modularly like a microkernel, but critical pieces are given kernel rights for speed considerations. *shrug* I don't quite know how this makes things. I know it's still different than a vast, monolithic kernel. I'm thinking more of the 2nd Continental Congress.

By C-like, I mean a mid-level language that abstracts machine code to a sufficient height as to be portable. AFAIK, C, Pascal, Ada, and their relatives are the only ones to do this.

I pointed out Lisp, Haskell, and O'Caml because they seem to be the favorites as far as converting down to machine code goes. O'Caml seems to have a good reputation, especially. My intention was not to tie them in as C-like languages. Rather, I intended to constrast them to a mid-level language like C. Sorry if I wasn't clear.

[EvanED]

From my understanding, Mac OS X is for the most part implemented modularly like a microkernel, but critical pieces are given kernel rights for speed considerations. *shrug* I don't quite know how this makes things. I know it's still different than a vast, monolithic kernel. I'm thinking more of the 2nd Continental Congress.

The typical term seems to be a hybrid microkernel. (I first heard that term used in the context of NT; I don't know if MS created it or not.) Wikipedia gives the type of OS X as a hybrid kernel.

I still maintain that you lose most of the benefits of a microkernel (safety, some recoverability, and the flexibility to use untrusted code) if you put things in kernel space.

I pointed out Lisp, Haskell, and O'Caml because they seem to be the favorites as far as converting down to machine code goes. O'Caml seems to have a good reputation, especially. My intention was not to tie them in as C-like languages. Rather, I intended to constrast them to a mid-level language like C. Sorry if I wasn't clear.

Ah, I see. I *do* think that you'll see OSes be written in a langague like these in the not too, too distant future. (Within a couple decades.)

[photosinensis]

Anyone know where I can get tools to learn how to build asm code for the TI-89 Titanium? It's an m68k chipset, but the OS has a few quirks of its own. Furthermore, I do need an assembler that works on OS X 10.5 and on Linux.

[OOPMan]

I know from first-hand experience that a lot of useful code created by the Nintendo DS homebrew community relies on assembly.

Maybe not a general reason to try and pick assembly up, but it's a good enough reason that I'll one day try and factor the time to do so.

[Dark Shikari]

I thought that the JIT compiler used by modern Java VMs pretty much settled this issue. Is Java still slower than C++? Last time I looked (maybe 7 years ago) there was only a 10% difference between the two.

But yet nobody sane would ever consider writing, say, a video encoding in Java. I wonder why?

[dontiego]

I think that today, the only people who use assembly are those who write C compilers. Am I wrong?

One more example if you still need some.

I code embedded software in C.
Some time ago I had a strange overflow on one of my return variables.
The variable was declared as 32-bits long, but it looked like it was only 16.
Impossible to find out why, the variable WAS declared as 32 bits! Why would it behave that way?

I went down to assembler, and saw that my 32-bits variable was cut to a 16-bits upon return.
I compared the assembly code of this function with another one (also returning 32-bits).

Well, shitty compiler.
If a function returning a 32-bits variable was not pre-declared with a prototype, the return variable was cut to 16-bits.
I tried both and compared the assembly.
With a prototype? Returns 32 bits.
Without a prototype? Returns 16 bits.

The best solution would have been "do not use a bad compiler", but how would have I known without seeing the assembly code?

Assembly is good when shit hits the fan.

[EvanED]

I'm pretty sure that's "proper" behavior. Without a prototype, a function's type defaults to 'int ()(...)'. On a system with 16-bit ints, it did the right thing.

[duaneb]

Assembly is key to a good programmer—not to say that you can't program excellently without it, but I think it helps everyone. Why? Simple: It's good to know what the processor is doing when you compile your C code. If you don't know what it does, then it's hard to write good C code for the processor. That's how things such as (I recently found out duff's device.

[phlip]

I'm pretty sure that's "proper" behavior. Without a prototype, a function's type defaults to 'int ()(...)'. On a system with 16-bit ints, it did the right thing.

Only if function call was before the function itself in the source file/in a different translation unit. If the function definition was first, it should act as a declaration.

[Cynic]

ASM is extremely practical when speed is a factor. Eg, I think it was H.264 codec, but recently they added some random optimisation to their encoding routine (which was written in specially-crafted ASM), & achieved a speedup > 10% on intel Core 2 cpus. Can't remember how I got this info, or where it was, but it was pretty recent.

['; DROP DATABASE;--]

I'm surprised nobody's mentioned one of the biggest advantages to knowing assembly: hacking! Just the other day I ResHacked Windows Calculator to make the window smaller, and had to do some assembly work to hack out a routine that was overriding the window size leaving a big empty spot in a window bigger than it needed to be.

Also, Z80 is awesome. As for Java's speed, I think the biggest issue isn't execution speed but startup time. It takes ages for the JVM to load up for me.

[dontiego]

I'm pretty sure that's "proper" behavior. Without a prototype, a function's type defaults to 'int ()(...)'. On a system with 16-bit ints, it did the right thing.

Mmm...

The thing I don't understand is that the compiler did not complain that the function didn't exist.
If it had found the function declaration somewhere, then it would also know what the return type was, right?

The function is prototyped in a header file, but the code itself is precompiled.

I think I'm missing something here.