Hacker News Reader

Comment by mediocrejoker | Hacker News Reader

> Secondly, there is a common myth among programmers that assembly language is very hard to use and that it takes much longer to code the same program in assembly language than in a HLL. [...] An experienced assembly language programmer can and does code as fast in assembly language as an experienced C programmer does in C. It is simply a matter of familiarity.

I don't really understand this argument. If a few lines of c can generate dozens of lines of assembly, how can it not be faster to have the compiler write assembly for you?

View on HN

Also when writing C you don't have to be 'an experienced assembly programmer' to write performant and portable code. That is one of the driving points of a HLL: you don't need to know as much minutiae to write good maintainable code. I understand getting into assembly for the purpose of learning or squeezing out that last bit of performance, but it isn't a general purpose programming language anymore and shouldn't be a default choice over a HLL for most applications.

I came to post this exact thing. I guess the article is actually quite old. It talks people "migrating from MS-DOS to Unix/BSD" among other things, which sounds more than a little odd to be even from this millennium.

Macro assemblers. It would be a pain without macros.

"It is simply a matter of familiarity."

Your comment focuses on how fast the compiler generates lines of assembly, after the programmer has constructed a solution.

But unless I have misunderstood the author was focusing on how fast the programmer can construct a solution.

The final step of depressing keys to input the solution into the computer can be sped up by using libraries and perhaps macros.

It's also possible to write programs ("code generators") that generate lines of assembly based on a "template". And that "template" need not be written in C or any other popular computer language.

It could be some "DSL", a shorthand for assembly, that the programmer creates for himself.

djb's qhasm might be considered an example.

While it may be generally true that C requires less key punching than assembly (certainly it requires fewer "lines"), this does not mean constructing a solution in C necessarily comes faster than constructing one in assembly... if the programmer is familiar and efficient working with assembly.

Something like "(x3+(y/20)5)" will generate a few lines of assembly (about 3 to 5 in this case, assuming registers are pre-loaded). But usually no, there won't be much more code. For example "while(1){..." equals just one instruction, and "for(x=10, x<0, x--){..." is 2-3 instructions.

edit: idk how to put a asterisk up there in the example above

I have no idea where people get the idea that one line of C equals 10 lines of asm.

PS Assembly is not hard at all, and is good to understand/read assembly when coding C. The only thing is that it is a bit rough to start coding in it (no good tutorials is one of the two-three difficulties).

> I have no idea where people get the idea that one line of C equals 10 lines of asm.

Because coding in asm takes more than just the raw instructions.

x86 doesn't have many registers so you're shifting around stuff across registers and memory all the time, not to mention stack setup/teardown and the error checking (e.g. div0, overflow) you are supposed to do after operations.

C doesn't check for overflows..

I also disagree with "shifting around stuff across registers and memory all the time". An "average" function doesn't really have all that many variables and x86 has 8 GP registers (16 on amd64). You don't even have to declare variables, you just take a register (and/or a location in memory) and use it as you wish.

I'm now sitting here thinking what can be done in C that would end up being a lot of instructions, and i can't think of anything. Going over an array does not, neither does recursion (recursion is just syntactic sugar in the end). What else.. i can't think of anything. Macros ? But macros are cheating in this comparison (not to mention that the flat assembler has actual macros, that are extremely powerful)

C doesn't check for overflows..

This is one of the things where (x86) Asm is definitely easier: divide overflows naturally cause an exception which will get handled automatically, and add/subtract/multiply overflows can be checked with one extra (JO or JC) instruction. In C, this is all undefined behaviour.

I'm now sitting here thinking what can be done in C that would end up being a lot of instructions, and i can't think of anything.

Crypto algorithms come to mind, but like you said, macros can take care of that easily... and on this page is an AES-256 CFB implementation in Asm that is around the same size of source as others in C (but much smaller binary):

http://reimagery.com/fsfd/encrypt.htm

Yes, and C isn't even particularly high level.

Its a common trope expressed by bitter people. In general this happens when you don't keep up with technology trends, you just don't understand why somebody prefers one thing over another when both, peripherally, yield the same product. Its also obviously not true.

Because programmers are not typists? Translating a thought into a programming concept usually takes more time than typing it out, even in assembly.

I dunno. I think by any measure being able to write "x / 3" will gain you productivity vs. "imul eax,2863311531; shr eax,1" (with the trip to the Hacker's Delight page necessary to look up the magic number).

Or just use DIV/FDIV/FIDIV.

DIV is way slower than MUL, so unless you need the extra precision or the result of the modulo, don't use DIV.

We were talking about readability, not speed. (Of course, you could also just write a macro.)

Reply on news.ycombinator.com