Introduction to ASM

Anyone know a good way to start learning ASM? What's the best ASM language for x86?

You should probably start off with x86.

>>2 There are multiple assembly languages for x86. AT&T, intel, etc.

>>3
There are two major syntaxes for the IA32 assembly language, commonly known as x86, the AT&T and Intel, I personally prefer the Intel one.

>>2
>starting with a shitty CISC like x86
>not starting with glorious PowerPC, ARM or MIPS

http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/index.html

Oh, it doesn't look like AoA has been updated to 64 bit, but all you really need to know is that the 64 bit registers have the prefix r, e.g. rax, rbx, etc. There are a bunch of other changes but they aren't relevant to a nub.

Autoassembler!

CheatEngine.org

>>5
hipster faggot

>>9
Admit it, you know the x86 instruction set is a steaming pile of ass.

>>5

MIPS is trash

An irregular instruction set by itself isn't necessarily bad, x86 has aged some.  I'm not very interested in SSE/MMX.  Are those any good, or is it gimacks?

It's usually a bad idea to "argue with the answerbook" so the SSE/MMX must be good at least in some cases.  I'd like to hear from anyone who has used them... just curious.

OP, start off with the Intel manuals. They have everything you need to know, and more.

>>4
AT&T syntax is horrid.

>>5
Start with x86 and you'll find the RISCs boring and the encodings somewhat inefficient.

>>6,7
AoA does not teach asm, but some bastardized "HLA" language which is part asm and part high-level language. No one takes it seriously for that reason.

>>10
It's complex but elegantly extended.

>>12
Of course they're good at what they do; they're specialized instructions intended for efficiency in a specific use case.

I've used them for a couple of demoscene demos back in the 90's and they helped my demos be rendered efficiently on the hardware that was available at that time.

>>15

You lie.  Give real info or shut-up.

What speed-up factor?  I thought so.

>>16
SEE and MMX is good, but you will have increased latency and your data needs to be structured to accomodate the use of these instructions(typically vectors of similar variables)
[edit] Example

The following simple example demonstrates the advantage of using SSE. Consider an operation like vector addition, which is used very often in computer graphics applications. To add two single precision, four-component vectors together using x86 requires four floating-point addition instructions

vec_res.x = v1.x + v2.x;
vec_res.y = v1.y + v2.y;
vec_res.z = v1.z + v2.z;
vec_res.w = v1.w + v2.w;

This would correspond to four x86 FADD instructions in the object code. On the other hand, as the following pseudo-code shows, a single 128-bit 'packed-add' instruction can replace the four scalar addition instructions.

movaps xmm0,address-of-v1          ;xmm0 = v1.w | v1.z | v1.y | v1.x
addps xmm0,address-of-v2           ;xmm0 = v1.w+v2.w | v1.z+v2.z | v1.y+v2.y | v1.x+v2.x              
movaps address-of-vec_res,xmm0

>>16
My demoscene days were from the 90's and I don't have that code or data anymore because I've moved on from that hobby. Why should I maintain esoteric knowledge about things that I will NEVER directly use in the future? Why should I invest effort into gathering esoteric data right now for the sole purpose of this discussion? If you really want that data, it won't be hard to get it yourself.

The point I was making is that the SSE/MMX systems are intended for a specific use case: problems that are easily divided into SIMD systems. I have used these instructions in the past to process some audio and graphics tasks in the case of my demos. Some other applications of this system would benefit tasks such as video codecs, audio codecs, general sorting and indexing, and recursive cyclic graph processing. I don't work with these instructions any more because I've found that I can use other people's libraries to solve these sorts of problems.

All these esoteric tricks lead to three common objectives:
1.Reduce the cycle count
2. Reduce cache misses
3. Reduce branching
SSE often does all three at negligible cost. In machines without a GPU, it would be a stable basis for software rendering.

>>8
nope. it's buggy as fuck and leaves symbols left over everywhere. enjoy your lack of scoping.

>>17
VEX too

>>17
Image processing is where I see a lot of MMX code.

What's the best ASM language for x86?
Try x86 assembly

>>22
Didn't SSE supersede MMX?

>>24
No. SSE uses XMMx registers while MMX uses MMx which actually alias to the x87 arithmetic stack.

>>25
I know, but what I meant was, doesn't SSE replace MMX' functionality?

>>16
The speed-up factor can be up to 8x for SSE2, but typically it's about 2x-4x for most tasks. LoseThos would probably benefit a lot from it specially if it does silly things such as software-painting the whole screen 60 times a second.

>>26
SSE was mostly floating point, whereas MMX is integer. SSE2 added integer support and is what effectively replaced MMX. Now we have the same story: AVX is FP only and therefore useless for a lot of stuff, AVX2 is going to add integer support.

Also while we're at it, MMX is 64-bit wide, SSE(2) is 128, and AVX(2) 256.

http://pastebin.com/ccLEs6Gr

The speedup here is often 10x but that might be because GCC sucks ass at codegen.

How can an OS author, who says he loves programming and built an OS for programming on x86-64 not know or care about SSE or AVX, or SIMD in general?

I find it hard to believe. I bet if he were to rewrite his video drivers using SSE for rasterization, he'd be able to switch over to a 32-bit RGBA VESA linear framebuffer with decent real-time performance. I mean, shit, you can run UT99 in software rendering with 32-bit color on modern hardware and good get good frame rates.

>>27
Now we have the same story: AVX is FP only and therefore useless for a lot of stuff
Oh come on, really? Why do they do this shit every time, do they learn nothing of past mistakes?

Ooo  Oooo!  I see a spot whre I can add two 64-bit numbers at once!  Woopiee!

>>31
kill yourself faggot

>>31
this.

assembly is nerdy like that.

>>30
Because there's only so much surface area to pack in new features on a given process node. Ivy Bridge with AVX2 is on 22nm, while Sandy Bridge with AVX was on 32nm.

>>31
Think bit-blitting. With SSE2, you can blit 16 bytes in a single instruction and maximize memory throughput if you ensure that the instruction pipeline is well padded. Want to handle things like translucency in 32-bit RGBA? No problem, you can blend 4-pixels at once. The integer bitwise SSE2 instructions let you handle things like sprites with transparent pixels as well.

Really, you're retarded if you can't see outside of the box at how SIMD is good for graphics.

It's no wonder you're consigned to a life of living in a basement apartment, living off of social security and disability payments, working on an OS that no one but yourself actually uses, and not even sharing your source code to the world. It sure is a sad existence. More so when you consider that your Lord and Savior, God Almighty himself is a figment of your imagination.

>>34
But Ivy Bridge won't have AVX2 support.

>>35
Do you really think he's the real thing and not just a troll like any other troll on this board, such as the ultrafinitist?