4 ms·
> the compiler chooses whether and when to spill variables to the stack. In my experience the behavior is stable i.e. doesn't often change between rebuilds (at
by Const-me 8y ago
> the compiler chooses whether and when to spill variables to the stack.
In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++). I can manage this by looking at compiler's output: when I find there something I don't want, be it stack spilling or other reasons for me not liking the assembly, I go fix my C++ code.
> so writing functions takes a bit longer
Also reading is hard, therefore refactoring/improvements is hard, too. I have an impression the assembly is write only language.
- Daemon404 8y ago> In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++). This is less true when you try and support many versions of many compilers, however, in my experience.
- Const-me 8y agoYeah, that makes sense. I usually deliver results of my work in binaries so I can choose the compiler, and inspect compiler output of performance critical parts. Authors of that decoder didn’t have that luxury.
- SomeCallMeTim 8y agoAssembly is very readable with enough practice. Source: I've ported multiple assembly language games from one assembly language to another.
- Const-me 8y agoI think I have enough practice. I find assembly very readable on small scale. But when I need to write larger pieces of vectorized code, higher-level C++ constructs help a lot with readability, following reasons. Local variables and function arguments are named, as opposed to xmm/ymm register numbers. I can use (forcefully inlined) C++ functions to compose code from smaller pieces. In some cases, even OOP. Even in vectorized code there’re pieces running on scalar blocks of cores: loops, addresses calculations, conditions. With assembly you have to use it for the whole things.