Because it is a function in the C Standard Library. Programs are typically prohibited from declaring these functions. You can if you don't link with libc and pass in the correct compiler flags (gcc will turn some raw loops into a memcpy call as an optimization even without linking libc afaik)
Compilation units are required to declare all standard library functions they call. They usually do so by including the compiler's header files rather than doing more work and risk errors with explicit declarations.
I don't know how practical that optimization would be in this particular use case, wouldn't that mean the context switch code would have to be inlined at every call site? Then when you switch back to that context how would you generate that code correctly? You would need to know which registers were not saved by green thread A, and not touched by green thread B. So the compiler would basically need to know the runtime behavior of your program to optimize pushing and popping context records, unless I misunderstood your point?
If you set a breakpoint in say a win32 fiber switch, and look at the disassembly, it jumps to an internal function that just saves all the registers (and flags) to the active context and restores all the registers from the resumed context every time. Don't know how more optimal that can be for the general case.
That graphic of the language families seems to misspell Estonian (as Estinain) and Finnish (as Finish) ?
Seems like an odd oversight for such a project.
I came here to post this (and add little to any substantial discussion). I'm glad to see someone else beat me to it!
Also: Slovak (Solvak) and Slovenian? (Solvene).
There were so many I thought maybe I misunderstood how they were being represented in that graphic.
I have not worked in medical (my experience is in games) but my best guess is its more about reliability and predictability. Using a heap suffers from the fact that you can run out of memory to satisfy a malloc/new request (either due to system memory limit or due to fragmentation).
With static memory techniques you can "prove" the system has enough memory to work in all modes, i.e. device consumes 20 readings per second, keeps them in a ring buffer backed by a static fixed array, that buffer is large enough to satisfy processing rate.
I would just like to note, that as a human I can only store a finite number of passwords in my brain and would love if web apps like these would at least provide OAuth with another identity provider (gmail, etc.) as an option.
Most of the memory used by programs are pointers, and if you double your pointer size, it has a negative impact on the efficientcy of the L1 and L2 cache.
>> Most of the memory used by programs are pointers
This is a huge generalization, may I add.
Yes, I will not argue that cache usage is less efficient, but I am sure you know that register access is faster than cache access, and we double the amount of registers in x64.
To quote Donald Knuth, a 64 bit program would "waste half the memory [and] effectively throw away half of the cache".
You may double the number of registers, but you are still shuffling tons of data between your caches and memory, and that is going to be your constraint for most programs. Losing half of the 4mb or 12mb of your L2 or L3 cache because you use 64 bit pointers has a much bigger impact than doubling the number of registers.
This is actually not true. They started as a way to transfer money or IOUs between palm pilots. The web portion of the product got so much more traction that they pivoted.
https://www.gnu.org/software/libc/manual/html_node/Reserved-...