Post #2716197

2026-04-24 19:24 UTC

Writing C++ code? You should be able to mentally translate this into C. Where are the creator/destructors happening, and what do they turn into? Is that function call virtual? How does that work in practice, and what are the perf implications? If you're writing C, you really should be able to read assembly, and know what instructions are available, how flow control turns into branches, what a cache line is, what happens when you run out of registers.

Replies (4)

@TomF@mastodon.gamedev.place 2026-04-24 19:24

And if you're writing assembly, you should absolutely know the principles of branch prediction, micro-ops, how atomic instructions work, and M(O)ESI(F). But there's no need for a Python coder to know the whole stack. Even if they do (like I happen to) - if they try to think about them all at once, their head will explode!

Open ##2716198
@Doomed_Daniel@mastodon.gamedev.place 2026-04-24 19:34

@TomF@mastodon.gamedev.place Doesn't that propagate down? Like, if I have a performance problem in C++, how does it help me to know what the equivalent C-code is if I need to know assembly to figure out why that code would be slow?

Open ##2716218
@JamesWidman@mastodon.social 2026-04-24 19:48

@TomF@mastodon.gamedev.place re translating C++ to C: this would have been pretty much trivial to do back in the days of Cfront. I think it may still even be possible with compilers that use the EDG front end...? (Or at least, if you get the front end directly from EDG, it has a C-generating back-end just like Cfront did.) But if you're using, say, Clang, you probably want to think in terms of LLVM IR, or possibly the new ClangIR (and its translation to LLVM IR).

Open ##2716220
@synlogic4242@social.vivaldi.net 2026-04-24 20:06

@TomF@mastodon.gamedev.place I started in 6502 assembly and only later learned C. makes one appreciate it more too.

Open ##2716227