ASM Program vs Optimizing Compiler - Epic Grudge Match

[MusicalMike]

First of all, I hope you all enjoyed the humor of the topic subject line..

Second and mainly, I was reading a very old thread a while back:

http://www.masm32.com/board/index.php?topic=14510.0

Due to the age of the thread, I figured it would be better to start a new one and link to it because other forums I have been on frown on reviving old threads. But I did have a question. It would seem to me that a few people on here, (for example e^cubed) believe that as well researched and developed as optimized compilers are, a competent human assembly programmer can still do better. In fact, e^cube referred to optimizing compilers as "a joke".

So my question is, putting aside the fact that HLLs are usually good enough for most purposes and the fact that assembly language programs take longer to write and debug, how does optimized compiler generated code really stack up to hand crafted assembly code nowadays? Can hand optimized code really outperform compiler optimized code drastically enough to warent being called "a joke"? If so, why do most textbooks I have read on assembly language tell you in the first chapter that compilers are on par?

And if I misunderstood what was said on that thread, feel free to set me straight.

[dedndave]

first - that thread wasn't that old
i can still remember the discussion, so it can't be that long ago   :lol

modern compilers can crank out some very nice code, actually
assembly language programmers can sometimes learn tips and tricks from the resultant listings

anything a compiler can do, can be done in assembly, as well
most of us that write assembler code do so as a matter of preference
there are certainly bound to be areas where an assembly programmer can do better

in the end, if you feel more comfortable with C, than you are likely to develop faster with it
most of us have a set of canned routines that are quite fast, so development time isn't as bad as you might think
many of the forum members use high-level structures, etc
their code winds up looking very similar to a C program   :P

[MusicalMike]

I've been here quite a while, and I learned a great deal from you guys. I am relatively comfortable using assembly language. Sometimes I can't be bothered to deal with the arcane hardware specific details such as not being allowed to move data directly from one memory location to another, and having to manage the ever so scarce x86 registers.

Lately, I have been tinkering with a lot of system level programming, (writing boot sectors, fiddling around in real mode, etc), and most kernel programming examples are given in C, and not in assembly language, macros and high level structures or otherwise. Quite frankly, I enjoy this kind of bare metal programming and want to do it for a living when I get out of college if at all possible. I guess my question is, when you are programming on bare metal where absolute control of the hardware is essential, why don't you see more people using assembly language with macros as opposed to C? I have nothing against C, I am just genuinely curious.

[jj2007]

Actually, no idea why C is so ubiquitous. It is clumsy, error-prone and not faster than a decent BASIC dialect.
Maybe its strong point is that it is so ubiquitous?

As to speed: Look at the CRT routines. Recently I needed a fast ascii to float algo, for files in the Gigabyte range. So I tried sscanf, sloooow... and went down to the lowest CRT level, strtod. My Tip of the Day: Launch Olly, and see how the over-over-optimised CRT routine strtod performs the difficult task of converting a string to a float... :green2

Code Select Expand

2972    cycles for Ascii2FloatJJ
7097    cycles for StrToFloat (Masm32 library)
99938   cycles for strtod

[clive]

Actually, no idea why C is so ubiquitous. It is clumsy, error-prone and not faster than a decent BASIC dialect.
Maybe its strong point is that it is so ubiquitous?

Well given it's been around since the late 70's, and been ported all the 16-bit+ platforms, and a lot of 8-bit ones too, and that it maps effectively to most architectures, it's likely to be the first thing built as a bridge-head to a new platform/architecture. It offers a great deal of portability. I can rebuild code I wrote in the late 80's with ease, something I wouldn't even to bother to do with DOS/assembler code, which would be easier just to rewrite from scratch.

I'm not convinced it's more error-prone than assembler, a clumsy programmer is going to write awful code with whatever tools you give him.

BASIC has lost favour with the programming elites, but it isn't nearly as poisonous as it is portrayed. Unfortunately there are too many nuanced versions for it to gain the cross-platform traction things like C/FORTRAN have achieved.   

[redskull]

Good assembler is better than a good compiler, but a bad compiler is better than bad assembler.  The downside is that lots of people think that "good assembler" means regurgitating a list of tricks from outdated assembler books that haunt the local school libraries.  CPU's don't execute like the 8086 anymore, and the biggest mistake you can make is to assume that they do; for instance, even something as simple as moving from registers to memory (the "slowest" operation you can do) is often really just moving back and forth to the cache (a much qucker process).

-r

[clive]

Quite frankly, I enjoy this kind of bare metal programming and want to do it for a living when I get out of college if at all possible. I guess my question is, when you are programming on bare metal where absolute control of the hardware is essential, why don't you see more people using assembly language with macros as opposed to C?

Well you should be looking at embedded platforms rather than Windows/x86, although that is still migrating to C/C++, and 32-bit. The x86 is a bit of an aberration in terms of success, you should study more widely and look at ARM, MIP, 68K, RISC, VLIW, etc.

Assembler represents the most unportable code within any project, and precludes the change of architecture when a specific part goes EOL (End-of-Life), or becomes too power hungry, or cost sensitive.

The real issue here with assembler vs compiler, is that the instruction execution speed, apparent in terms of throughput, is close to a single cycle, or less when things pair or group well. In days of yore you could readily shave off a few hundred cycles by carefully crafting assembler routines based on a clear knowledge of what the code is doing, today unless you're using SIMD/vectorizing you might well be viewed as less productive (lines of code) than some average joe programmer pounding out lots of lackluster, but functional code. Most of the gains you're likely to achieve are through a better selection and implementation of algorithms.

[MusicalMike]

Well you should be looking at embedded platforms rather than Windows/x86, although that is still migrating to C/C++, and 32-bit. The x86 is a bit of an aberration in terms of success, you should study more widely and look at ARM, MIP, 68K, RISC, VLIW, etc.

Assembler represents the most unportable code within any project, and precludes the change of architecture when a specific part goes EOL (End-of-Life), or becomes too power hungry, or cost sensitive.

The real issue here with assembler vs compiler, is that the instruction execution speed, apparent in terms of throughput, is close to a single cycle, or less when things pair or group well. In days of yore you could readily shave off a few hundred cycles by carefully crafting assembler routines based on a clear knowledge of what the code is doing, today unless you're using SIMD/vectorizing you might well be viewed as less productive (lines of code) than some average joe programmer pounding out lots of lackluster, but functional code. Most of the gains you're likely to achieve are through a better selection and implementation of algorithms.

As far as other architectures go, I am teaching myself MIPS and ARM. And I would like to learn m68k except that Easy68k is not available for the mac, whereas SPIM is readily readily available and qemu will emulate a lot of well known ARM based kit. My main problem with MIPS is its branch and load delays although over all I think its a much cleaner and better designed ISA than IA-32 or x86-64. While, books on MIPS for embedded programming are ubiquitous, I am having significantly less luck finding any books on ARM that aren't geared towards a specific arm implementation. A lot of companies are using proprietary ARM implementations. TI has one that they use in their NSpire line, Apple uses them in their iPhones. I would just like a book that runs me through the basics of the ARM architecture. I can worry about stuff like Cortex3, TI-NS2006A or the A4 chip later. I know this is starting to get off topic, so let me just say, if you have any good ARM book suggestions, message me.

[Twister]

You should also learn the Z80 architecture.

If it's not the top most used embedded architecture, then it is one them!

[clive]

Joseph Yiu's book on the Cortex-M3 is pretty good on the micro-controller side of things.

For a good background in ARM and where they're coming from, the ARM7 and ARM9 is that place to start from. Books by Furber and Sloss are recommended, there is a lot of good stuff online.

ARM is used a lot in SoC designs (System On Chip) where it is integrated with other peripherals and devices. The density of chips is such that more and more is being pulled onto a single piece of silicon. I have a couple ARM9 SoC device in my portfolio. Don't let the SoC issue prevent you from digging into the basic architecture, the peripheral change a bit, but it's all pretty portable knowledge. On the more generic level the parts from ATMEL, ST, NXP, MARVELL, SAMSUNG, etc offer a good entry point into development.

MIPS is used a lot too, it's in more things than you might think (TV/STB/Network). I have a couple of parts using M4K SoC designs, and have others that use a LEON3 Sparc implementation.

68K is a superbly clean design, I have a couple of legacy devices that use a lot of assembler and Fortran code. It's not hugely relevant in today's market. I think the Acorn guys/gals took a lot of best aspects of the 68K and 6502 into consideration during the original ARM design.

[clive]

You should also learn the Z80 architecture. If it's not the top most used embedded architecture, then it is one them!

It's pretty high, but they kept going bust and fumbled the follow on chips. I'd say things like the 8051's are far more prolific, as are PIC's, based on my experiences. It's really about time 8-bit just died. They probably won't, we use them as throw away initialization devices (jamming parameters into more complex devices/systems at startup) because they are cheaper/easier than an EPROM + FPGA state machine. That or caretaking hardware that is doing the real processing.

It's a vast improvement on the 8080/8085, but not sure it's worth the time/effort today. The money's going to be in 32 or 64-bit. There's a whole bunch of us old guys who know this stuff, and a large faction of them are still stuck there unwilling to embrace 2011.

[MusicalMike]

I tried learning z80 on my old ti 84+ a long time ago. Suffice to say, it didn't go well. Actually it was about the time I signed up for this forum. Just reading "Z80" on my screen causes me to shutter. Oh well, I've learned a lot since then. Maybe now that I know a bit more it wouldn't be so bad.

[dedndave]

the old 8-bit stuff has it's uses
some functions are just too simple to require more
alarm systems, sprinkler systems, and toys come to mind

the crunch is not the chip, itself, but the support hardware and power consumption considerations
no matter how you slice it (PUN), an 8-bit latch is always going to be cheaper than a 32-bit latch   :P