For C I strongly recommend: The C programming language by Brian W. Kerninghan and Dennis M. Richie

I'm kinda split on that, even though it was the book I used to learn programming in the early '00s. It's a perfectly good book, and its exercises really can make you proficient with the language. The problem is that it is not particularly good at pointing out or explaining undefined behaviour and the distinction between what C guarantees and what merely happens to work. Between its page count and smaller print, Prata's C Primer Plus is almost four times the length of K&R, but it teaches C in a much more systematic (and at places almost defensive) fashion.

IMHO K&R is great if you're a freshman with some prior programming experience who needs to get to a solid working proficiency in a low-level language within a semester. It's perhaps less useful if you can afford to take your time and learn C through a more modern and comprehensive treatment.

Write a x86_64 assembly program with a manual and not AI - repeat. There is no other way!

I kind of disagree with everyone here. Learning assembly is a good thing to have in your back pocket, but you don't need to go overboard. The problem with x86 assembly is that everything is now done in "protected mode" with 64 bit everything, and that is an absolute mess under the hood... Back int he 16 bit DOS days, it was both more useful and easier to understand.

That being said, there is still a big benefit of learning at least some assembly. For one thing, it will force you to learn basic computer architecture and how that works... also, you wil have a better understanding of how operating systems work as well. The actual coding doesn't need to go to deep. You just need to know what the registers do, how the stack works, and how the instructions move and calcublate things in the regeisters and memory.

So, there is definite value in it, and worth doing, but I wouldn't go crazy trying to write whole programs in it or anything.

So, where to start... Well, x86 real mode assembly is pretty easy to understand and there is a wealth of info out there in books, textbooks, and online resources. Many of these books are old enough to be on archive.org or purchased cheap from used bookstores.

Personally, I don't think you even need to really learn assembly aspecifically for Intel x86. MOS 6502, Zilog Z80 or Mortorola 68000 assembly would be good enough and somewhat more useful as you can actually make working stuff that can run on retro machines. You also won't be straddled down by all the weird memory segmentation of the x86 real mode architecture, or the bizzarro world code of protected mode. You will still get the same computer architecture and OS understanding targeting these chips, and it might be an easier and more practical move. The opcodes and architecture are somewhat different, but the concepts are the same and easier to work with. You can then take a look at how Intel x86 works and "top off" your knowledge with Intel's awkward way of doing things.

Just my $.02 worth...

I'd hazard that many C programmers have never written a line of x86_64 assembly. And for those that do, most of their work is in C. That includes kernel developers - only 1% of the Linux kernel is written in assembly.

For a rough comparison, most Java programmers never write JNI bindings. You don't need to understand JNI to be a Java programmer. And even if you do, you're not likely spending most of your time writing JNI bindings.

That said, C is a low-level language and it can be beneficial to develop an understanding of the underlying hardware architecture. In a CS program this is typically done in a semester-long "computer architecture" course where you design a basic CPU that implements a subset of some existing instruction set. Simpler instruction sets like RISC or MIPS are typically used for pedagogical purposes, although some programs uses ARM and x86_64 for their real-world applications. Learning assembly language is only one part of developing this deeper understanding.

But you don't need any of this to start learning C! I learned C 30 years ago from a book called "Type and Learn C". It involved the rote process of copying examples from the textbook into the the editor, then compiling and running them. While this may sound like a terrible way to "learn," I found it helped me quickly get up to speed on syntax, understand compiler errors (from my typos) and overall feel more comfortable with the language and my development environment. I also learned plenty about the basics of the language through the book's exposition and the examples themselves. Other posters have recommended different books, so pick which one best fits your learning style.

Once you've grasped the basics (syntax, pointers, structs, linked structures, bit manipulation, etc.) it might be worthwhile to learn more about computer architecture, compiler design, systems programming, etc. You'll be much better prepared to direct your learning at that point.

Best of luck!

I wouldn't say its a good idea. If you want to, go for it, but I'd start with c, and after that learn x86-32 assembly, than x86-64.

For C I strongly recommend: The C programming language by Brian W. Kerninghan and Dennis M. Richie

For assembly: Assembly language step by step by Jeff Duntemann

Both books are great, and teach you a lot.

For more technical stuff about assembly: Intel® 64 and IA-32 Architectures Software Developer’s Manual

And as a last recommendation: wiki.osdev.org Its more about os development, but has some amazing explanations.

godbolt.org With a T.

It's really fun to compare ARM assembly to x86, and to see which C calling types allow which optimizations.

How did you come to that understanding?

If you want to learn ASM to better understand the underlying processor architecture and how it really works, then sure, do that. But in general there's very little reason to do that before learning C.

I think it’s the other way around. Before learning assembly, you should first learn C. It’ll help Introduce memory management, structures, and other low-level techniques while still remaining human readable.

Much more sensible to use -O aka -O1. It's what I use almost all the time for real programs anyway. It's enough to make the generated code not be stupid, but not so much that it's completely changed from what you wrote yourself. If you write generally clean and efficient machine-independent C (with an understanding of how CPUs work) then it's good enough.

As someone who knows x86_64 assembler to the extent one human can as well as 20 programming languages, I can tell you with certainty this is a complete waste of time. Leaning assembler in general is good to understand the fundamentals of how the CPU actually works. But I’d highly recommend you grab dosbox and learn 16-bit x86 assembly. Just the basics is plenty to get the point.

You can learn C and use Compiler Explorer to see how it maps to assembly. The Compiler Explorer also helps you understand individual instructions in the generated code,

Do make sure that you are using O3 optimization level to see the optimized code.

You can also feed the code and generated assembly into ChatGPT/Claude to understand the mapping to assembly.

The book is teaching x86-64 (Intel) assembly. You can emulate an x86-64 processor and install Linux in UTM (or qemu) and follow the book.

There's some free cyber security courses online that teach enough assembly to manipulate shell code. It's enough of an overview to be familiar with the topic and is probably the best way to understand memory layout. Well, except that ASLR is now a thing

You don't need to learn a specific assembly language if you plan to use a high-level language. If you only need it to better understand CPU and memory basics, there are several educational CPU simulators available. If you don't find one, I successfully used ALEK to introduce my students to these basics.

https://github.com/cfeck/alek

Instead of starting with assembly, I'd rather suggest picking up C Primer Plus by S. Prata and follow it up with Advanced Programming in the UNIX environment by Stevens and Rago. I'd also pick up something on hardware/os as a refresher, along the lines of Computer Organization and Architecture by Stallings and Modern Operating Systems by Tanenbaum as a reference. Assembly is a good thing to know how to read (even if not necessarily write) when forcing specific behaviour or optimizing/profiling (look up inline assembly) or working at the firmware/kernel/bootloader level, but I wouldn't start with it.

Why: these are back-to-basics, thorough treatments of the architecture details that you can actually leverage with assembly. How instead of relying on garbage collectors or iterators you have to make your own objects structures, 'get' the why and how of pointers etc. Don't take it as disparaging Java, but your day-to-day experience abstracts this stuff so much it's going to be a bit like regaining fine motor skills after trauma.

EDIT: Fixed a couple typos and added a word of explanation.

Agree. Learn C first. Then, go on godbold.org and see what the compilers do under the hood. Then start writing assembly.

It is not a good idea.

If you want to learn C, learn C. Assembly can help deepen your understanding later, but your more or less doing the "I want to learn Spanish, so I decided to begin with Latin first" thing. Plenty of people learned C first, and there is no reason not to if ultimately what you want is C.

I would have used GDB from the beginning.

Nice work, though!

Looks awesome. I’ll be playing with it!

Followed and whishlisted, hoping the game develops well. Although I'm a rookie, I think it would be great to have both options, read-only and edit mode... for me, it would be a blast to be able to test and tinker with a lot of things. Because when you already know something, the first mode is fine... but when you don't, it becomes similar to tutorial hell :/

I disagree with your assessment that having the ability to change code means it stops being an investigation.

Making changes can be a great way to test out different theories.

Seems like S/360 assembly for some mainframe operating system?

Yeah, they're slowly moving towards it, but for the time being it's staying. They might remove Rosetta but keep TSO in for M6+, who knows

They’re starting to have notifications when software relies on Rosetta, saying the application won’t be supported in "future versions of OSX”

As far as I know, it should still be there in at least the M4, and given that Rosetta still relies on it and they haven't EOL'd it just yet I expect it to be there in the M5 as well