How to Learn Assembly?

What book and what architecture?

Learn assembly? It's queue of instructions in a text file, nothing complicated.

You don't need a book. Just find a document that has all the instructions listed for your architecture. You can try x86 if you like computers, or maybe some AVR if you like micro controllers.

Generally though, you can't use assembly in much useful way. It is a lot more useful to learn C properly, as modern C compilers tend to create better code than skilled assembly programmer can do in short time.

>>2

There are a lot of nuances, like out of order execution, stack-vs-register, CPU caches and common idioms (xor ax ax). Although I don't remember any good book on assembly.

SICP would teach you all the basics. One of SICP assignments is a virtual machine for a simplified pseudo-assembly DSL, an interpreter for Scheme written in this pseudo-assembly, and finally, a compiler for Scheme that spits out pseudo-assembly code.

>>1
If serious, apply your questions to your nearby search engine. I already gave the ones I use daily:
https://bbs.progrider.org/prog/read/1382520568/10

The Art Of Assembly, of course. Or that PC Assembly Language
by Paul A. Carter using NASM architecture.

Basically what >>3 said.

Read SICP.

>>6

reading SICP to learn Assembly
only on /prog/

>>7
Please refrain from quoting what hasn't been said.

>>8

quote my anus

What are /prog/riders' opinions of the relevance of [M]MIX? From an
abstractionist perspective, it seems like it would be very useful to
learn the way things are done in an asm environment, such that one can
then simply build on that with the specific ops for MIPS/ARM/etc. when
actual implementation needs to be done. Then again, perhaps
`abstractionist' isn't the correct way to look at learning asm in the
first place.

>>5 is ok, though I started with the old IBM PC Assembly Language and Programming by Abel, you will find many erratas BUT it was really nice for a 14 years old boy back then (ie me). You should get a copy of the Intel manuals as well (they used to send you physical copies for free).
Go first with x86 (without extensions). You may use NASM or FASM. Then try to learn some pure RISC architecture.
Also if you like electronics try to get some PIC or Atmel micro-controller.

ASM is just a macro for machine language. It's like binary with lots of preprocessor abuse.

>>12
By that logic, C is a macro for ASM. And Python is a macro for C?

>>13
Not him, but a difference I see is that in terms of output, C means different things depending on target arch, while ASM either means exactly one thing or has no meaning.

Check em

You can try x86 if you like computers

x86 is the absolute worst. It will make you HATE computers.
If you want to experience a well engineered CISC system try VAX instead.

AVR assembly is relatively easy to learn, especially if you're interested in microcontroller stuff: you know, timing and a lot of hardware interrupts. for something more practical, ARM64 isn't bad either and it will introduce you to RISC pipeline nicely although it tends to have multiple similar instructions for slightly different things despite being RISC. 32-bit ARM is much messier though given the posssibility (and occasionally - depending on restrictions - necessity) of jumping between 32 and 16 bit modes.

I do not recommend learning x86 assembly because it's very complex due to neverending feature creep and different vendor-specific extensions. also, there's literally no reason to learn it unless you're interested in low-level hacking/exploitation/vuln research (which I personally am, although I'm currently doing it with ARM64) because compilers are generally better at optimizing for it than programmers are and unlike alsmot every other fucking assembler it doesn't even make it easy to write constant-time code. it doesn't even guarantee that things you put there will be executed at all (http://blog.erratasec.com/2015/03/x86-is-high-level-language.html)

>>16
Strongly disagree. x86 is the best and most versatile. That is why it is used everywhere. It was also my first programming language, so it is easy to learn. No need to forcememe RISC/ARM crap, when people already know x86.

>>18
There are also a fuckload of documentation on x86, compared to obscure architectures.

>>18
Your brain was tainted by x86 first so your opinion doesn't count.

>>18, 19
actually no, x86 is badly documented because it's cobbled together with different instruction set extensions and at that point nobody even knows what's happening under the hood (see the link in >>17).

x86 is like windows, OOP or XML - it's 'good' because it's everywhere and you often simply don't have much choice. it's also a lot like C in that it has a fairly understandable base onto which a lot of crap was added as the requirements and expectations started to change. ubiquity and backwards compatibility are an upside but the downside is the messy architecture, a metric fuckton of obscure instruction and the aforementioned fact you don't actually know what is going on at the hardware level.

also

It was also my first programming language, so it is easy to learn.

depending on when you learned it, it might have been the case. if you're a 16-bit era oldfag then yeah, it was far easier than it's now.

>>21

x86 is badly documented

It has great documentation. Read Intel manuals and accept Yahweh. It is 21st century already. Your RISC is so 90ies playstation1-nintentdo64-kiddie-products.

Check em

>>21
Common Lisp is like windows, OOP or XML - it's 'good' because it's everywhere and you often simply don't have much choice. it's also a lot like C in that it has a fairly understandable base onto which a lot of crap was added as the requirements and expectations started to change. ubiquity and backwards compatibility are an upside but the downside is the messy architecture, a metric fuckton of obscure symbols and the aforementioned fact you don't actually know what is going on at the hardware level.

>>24

the aforementioned fact you don't actually know what is going on at the hardware level.

well yeah, if you want to know shit at the hardware level (like when you write cryptographic code that needs constant time execution) then you don't use a functional high level language like common lisp but assembly. the problem here is that x86 assembly doesn't guarantee that.

also, I wouldn't say that common lisp is everywhere. OOP is a dominant paradigm, functional is much less widespread nowadays. but that really has nothing to do with the thread because we're comparing processor architectures, not programming languages.

>>25
Since you assumed common lisp is functional, I can conclude that you know nothing about common lisp.

is Common Lisp a Lisp?

Is Common Dubs a Dubs? Check em

Check em

>>25
You fuckhead, most Common Lisp implementations include their own fucking assembler to compile CL down to machine code, and expose that to the user. If you want to know shit at the hardware level, if you want to create new language semantics that directly manipulate CPU features (without having to wrap them in a function or text macro like C's fucking shitty bullshit), then use Common Lisp to bang the metal.

>>30
plz write more, I'd like to know more about systems programming in Common Lisp

>>31
Greenspun's 10^th.

>>32
it doesn't teach me how to do systems programming in lisp

Check em

>>31
Nice goalpost change, going from crypo libs to system programming, you flaccid minded pussy.

But here's one article: https://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrinsics-in-sbcl/

Check em

>>30-34,35
Lisp is a kike scam. Those kikes stole billions of dollars from the taxpayers.

>>35
but writing secure crypto libs and systems programming have a lot in common. both require fine-grained low-level control over the machine - they do so for different reasons (to prevent side-channel attacks in crypto, to ensure that everything JUST WERKS and has good performance in systmes) but require similar tools

just learn 68k or ARM. with 68k you can do megadrive programming which is pretty cool

Why to Learn Assembly?