It depends (like usually):
On your interest and the field you want to specialize.
Knowledge is always better, but you need to focus on some things, life is short.
If Intel hires you to focus on the CPU-Renderer, then the assembly code might be very interesting.
If you focus on cross platform software development, assembly language might never cross your ways.
In many cases inline assembly is enough, but in many cases even that is not useful (there is no magic in inline).
en.wikipedia.org/wiki/Inline_assembler
Assembly language is a misleading term:
To assemble, to collect, to gather.
Assembler is the piece of software that converts the text to machine readable code;
instruction and data sequences, which ordered in different sections, so that the Operating system (OS) can provide it to the CPU.
The final file layout depends on the executeable file format that the OS is supporting.
Actually, an assembler is part of the tool-chain if you write C-Code, it is called behind the scene at some late Stage during the compile-progress.
GCC calls GAS; try
in a Ginux (I use that term for a Linux based OS, cause Linux is just the name of the Kernel) shell. If you installed gcc, the assembler tells it version.
I know, most of you people here use Microsoft's OS’s.
Most Assembly language syntaxes aren’t standardized (if there is any?) unlike C/C++.
So the language depends fully on the underlying Assembler (gas/nasm/yasm to name some).
Two syntaxes are more popular, AT&T (used by gas) and Intel (masm, nasm).
The major sum of keywords in Assembly language derived from the processor manufacturer’s CPU manual. These are called mnemonics.
mnemonic from greek μνήμη → memory, to remember, keep in mind.
Some are short words, some are acronyms, like:
push, pop, add, cmp, call, lea, je, xor
So the “language” depends on the Assembler + underlying CPU.
I also said that the final file is organized for the operating system, in a binary (executable file format the operating system understands). It has to follow the OS’s calling conventions and use the OS’s syscalls. So finally it depends on the Assembler, the CPU and the OS.
And there are many CPU’s.
You can assemble the code of the book, but it is 32-bit code.
Like, you compile 32 bit code with:
| gcc -m32 -o output32 hello.c
|
You can do the same for asm files with:
| as --32 -o movtest3.o movtest3.s
|
but you need to link it also:
| ld -melf_i386 -dynamic-linker /lib/ld-linux.so.2 -L/usr/lib/ -lc -o movtest3 movtest3.o
|
There are many documents outside, were the movement from 32 to 64 bit assembly language is described. IMO it is harder to read the Intel manual than to code :)
There are manuals for the manual aswell ^^
ASM (x86/x86_64)
https://software.intel.com/en-us/...cles/introduction-to-x64-assembly
http://eli.thegreenplace.net/tag/assembly
C and asm
https://www.recurse.com/blog/7-understanding-c-by-learning-assembly
I linked this already once in C ressources:
http://download-mirror.savannah.g...grammingGroundUp-1-0-booksize.pdf
Calling Conventions:
http://www.agner.org/optimize/calling_conventions.pdf
Executable file formats:
en.wikipedia.org/wiki/Portable_Executable
en.wikipedia.org/wiki/Executable_and_Linkable_Format
There are several other resources in this forum already.
To answer your second question, I think I can definitely say that I am not a renderer-programming expert.
I am 43, started coding at age of 11, but had many times where I did something else. Since 2007 I did 2 years on 3D Design and in the past 7 years I focused on linux development, C-Programming, 64-Bit Linux Assembly, Bash-Programming and other things.
I dove deep in the source code of
blender.org and
enlightment.org, since 2 Years I do OpenGL and SDL2 Coding, some cross-platform (android) work. And I built an interactive developer help, which is svg based.