Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning to Read X86 Assembly Language

patshaughnessy.net

Post reply on HN
Print view View original

171–180 of 238 posts

Re: Learning to Read X86 Assembly Language

#171

Post by qwertyuiop924 »

Annatar wrote: post #159
qwertyuiop924 wrote: post #42

Earlier quoted context omitted.

Hey, I didn't say it was the only one. Although POSIX and HTML5 hold up a bit better than Win32 and C++, IMHO. Especially POSIX (it's not great, but it works pretty well). But I've heard X11 is absolutely miserable, so the windows folks don't have a monopoly on satanically evil APIs with religious backwards-compatability.

Everything you wrote is actually correct, so I'm really not sure why you're being voted down, but it's a behavioral pattern I've noticed on HN in general: write anything that's not high praise or in any way disagrees with what's popular and expect to be brutally censored. It really has me contemplating ditching HN altogether, if all we're ever going to do here is stroke eachothers' egos and pander to popular trends.…

It's not the worst. There are far worse places. And this sort of problem appears in all forums, but especially voting-based systems like HN (the "internet points" problem).

As forums go, HN is far from the worst. But it could be better.

Re: Learning to Read X86 Assembly Language

#172

Post by qwertyuiop924 »

mangamadaiyan wrote: post #156
userbinator wrote: post #76

Earlier quoted context omitted.

How many of you lot know the ZX line? Spectrum? No? The ZX Spectrum and its clones were very popular in the UK, Eastern Europe, and the former USSR.

... and for a brief period of time in the late '80s, "popular" in India as well. (I quoted popular because they were bloody expensive. In 7th grade, a kid in my class had one. He was the only one in all of the school to have a computer.).

Huh. The Spectrum was popular elswhere because it was so comically cheap.

Re: Learning to Read X86 Assembly Language

#173

Post by qwertyuiop924 »

EvanAnderson wrote: post #107
spc476 wrote: post #67

Earlier quoted context omitted.

For 8-bits I'd recommend the 6809. Two 8-bit accumulators that can be used as a 16-bit accumulator, 4 16-bit index registers (that can largely be interchanged, except for S which is also the stack register) and you can generate pure relocatable code. And the zero-page isn't restricted to address $0000.

This sounds really interesting. I've never taken a look at the 6809 before. I happen to have a working Tandy CoCo I scored in a vintage computer haul. I'll definitely check out 6809 assembler.

I know that asxxxx will assemble for the 6809, if you need an assembler.

Re: Learning to Read X86 Assembly Language

#174

Post by Grom_PE »

burfog wrote: post #164
Grom_PE wrote: post #68

As AT&T syntax is still being used, at this point I'm willing to believe it's to purposely make x86 assembly hard and unpleasant to read and write. Perhaps so people will want to stay away from it, and in a way, to reduce the amount of code that is tied to the x86 platform. It spreads the thinking x86 assembly is terrible and ugly. Intel syntax is much cleaner, in particular, Intel Ideal (as opposed to MASM), and spe…

All of those are misleading because the FS segment override isn't specific to an operand. It applies to the whole instruction, which commonly has one place (a memory reference) for the override to take effect. You can have more than one override, but only the last one remains active. Normally you can have an override even if it isn't used. There are a few instructions with more than one memory access; the override on…

No. This is misleading:

    fs movs byte [edi], [esi]
This is a syntax error:

    movs byte [fs:edi], [esi]
And this is a valid override with sensible syntax:

    movs byte [edi], [fs:esi]

Re: Learning to Read X86 Assembly Language

#175

Post by RX14 »

Annatar wrote: post #154

And, of course, modern compilers will usually produce faster, more optimized code than you ever could, without making any mistakes. This assertion comes up over and over again in the last 30 years. Every time I've had it asserted to me, it always came from non-assembler programmers, who always wrote in a high level language. I have yet to see evidence of optimizing compilers generating code even remotely close in eff…

Bear in mind that this isn't a release build, so the generated assembly will not be optimized at all.

Re: Learning to Read X86 Assembly Language

#176

Post by Grom_PE »

spc476 wrote: post #89
Grom_PE wrote: post #68

As AT&T syntax is still being used, at this point I'm willing to believe it's to purposely make x86 assembly hard and unpleasant to read and write. Perhaps so people will want to stay away from it, and in a way, to reduce the amount of code that is tied to the x86 platform. It spreads the thinking x86 assembly is terrible and ugly. Intel syntax is much cleaner, in particular, Intel Ideal (as opposed to MASM), and spe…

As I recall, the "dword ptr" stuff was only necessary if the instruction was otherwise ambiguous. Using EAX means you are using a 32-bit destination. But something like: move fs:[ebp-10],5 is ambiguous. Is that an 8-bit constant? 16 bits? 32-bits?

I believe MASM-style assemblers require "dword ptr" at all times and many disassemblers keep outputting that in unambiguous situations.

Your example won't assemble because size can't be guessed, but this will:

    mov dword [fs:ebp-10], 5

Re: Learning to Read X86 Assembly Language

#178

Post by wolfgke »

voltagex_ wrote: post #121
makmanalp wrote: post #82

Earlier quoted context omitted.

OK, so it's not a magical convention - it works it out bottom-up. First decide on registers for each parameter when you generate the code for the function, then based on that generate specific code for the instances where you call that function. Cool, thank you. Also that example, heh. I tried to go back gcc versions to see if there was a case where it didn't do TCO - nope. Also, I like how returning 0 is "xor eax, e…

> Also, I like how returning 0 is "xor eax, eax". Why is it so different with different optimisation levels? The default emits quite a bit of code, -O1 is `mov eax, 0`

> > Also, I like how returning 0 is "xor eax, eax".

> -O1 is `mov eax, 0`

Simply because it is shorter: On x86-64 (and x86-32)

  xor eax,eax
encodes as

   31h C0h or 33h C0h
(depending on the assembler; typically the first one is used) - 2 bytes, while

  mov eax,0x0
encodes as

   B8h 00h 00h 00h 00h
- 5 bytes.

Having privately analyzed some 256b demos I cannot even imagine how one could even come to the idea to use `mov r32, imm32` for zeroing a register (except for the reason that people don't want to understand how the assembly code is internally encoded) - the canonical way to use is `xor` (`sub` also works in principle, but `xor` is the way that is recommended by Intel).

EDIT: Here is an article about that topic: https://randomascii.wordpress.com/2012/12/29/the-surprising-...

Re: Learning to Read X86 Assembly Language

#179

Post by xxs »

Annatar wrote: post #154

And, of course, modern compilers will usually produce faster, more optimized code than you ever could, without making any mistakes. This assertion comes up over and over again in the last 30 years. Every time I've had it asserted to me, it always came from non-assembler programmers, who always wrote in a high level language. I have yet to see evidence of optimizing compilers generating code even remotely close in eff…

>>because compiler algorithms can't reliably make such contextual decisions

They can actually. Compiler optimizations have come long way, even Java's JIT should be able to optimize that. (ok, not using the AL register)

My personal story - I used to use exclusively assembler for 6502 and 8086 as it actually ran fast enough. In the mid 90s I saw Delphi's code (and Delphi was not known for its optimizations) but it was able to use the Pentium instruction pairing which takes quite an effort to accomplish by hand.

While beating an old compiler was easy it was the time the compilers began making strides rivaling humans.

Still, hand written inner loops in Assembly might yield some performance (iirc, grep still relies on) but overall there are very limited amount of settings where there would be significant difference... to warrant the effort (incl. correctness and [micro]benchmarks)

Re: Learning to Read X86 Assembly Language

#180

Post by wolfgke »

haberman wrote: post #116
userbinator wrote: post #70

What a train wreck! It’s hard to imagine a more confusing state of affairs. I'd say that's more attributed to someone many many years ago deciding they would not follow the official Intel syntax (for what reason I do not know), and somehow convincing the rest of the community to follow them. That's actually one of the things that could make for a very interesting article: how one processor family got two different an…

This. The AT&T syntax for x86 thing is a huge mistake. All the official docs are Intel syntax. Intel syntax is easier to read and write. Half the gotchas in this article are problems that don't exist in Intel syntax, like the instruction suffixes. The instruction suffixes get even weirder when you get to the sign extending instructions. I wrote an article about this here: http://blog.reverberate.org/2009/07/giving-up…

I prefer Intel syntax and admit that you have a good argument in your article why the AT&T syntax might be problematic, but for newer extensions (SSE etc.) the instruction naming in Intel syntax actually converged towards AT&T syntax: Just to give an example from SSE2 (from http://softpixel.com/~cwright/programming/simd/sse2.php):

  paddb - Adds 16 8bit integers.
  paddw - Adds 8 16bit integers.
  paddd - Adds 4 32bit integers.
  paddq - Adds 2 64bit integers.
Post reply on HN