31–40 of 73 posts
Earlier quoted context omitted.
For those who don't know, that's why big and little endian were called that, because the debate was so frivolous. It's a reference to the book Gulliver's Travels by Jonathan Swift in which an island folk was split about from which end you should crack a boiled egg. (I'm a big endian for example).
I'm firmly in the little-endian camp for eggs, but big-endian for CPUs.
Assume RAX points to the root node and nodes just contain two child pointers and everything is aligned and whatever. :invert cmp rax, 0 jnz swap: ret :swap push rax mov rax, [rax] call invert mov rbx,[rsp] xchg rax, [rbx+8] mov [rbx], rax call invert pop rax ret The last time I used an assembler was before x86-64 was invented, I am not even sure I ever used one in protected mode. But that seems a totally reasonable w…
The variables on the stack are the most efficient after registers, so you are right that a local variable should be kept into a register if possible, otherwise in the stack, and only then in other places (e.g. if it is too large for the stack). However, when writing in assembly one must pay attention that at least RBX, RBP and R12 through R15 must be preserved by any function (on Windows also RDI and RSI must be pres…
Earlier quoted context omitted.
The variables on the stack are the most efficient after registers, so you are right that a local variable should be kept into a register if possible, otherwise in the stack, and only then in other places (e.g. if it is too large for the stack). However, when writing in assembly one must pay attention that at least RBX, RBP and R12 through R15 must be preserved by any function (on Windows also RDI and RSI must be pres…
I know none of the calling conventions in any detail anymore and just used the registers in alphabetical order. Totally expected that this would violate something.
mov cr0, ...Earlier quoted context omitted.
I was thinking of this from the perspective of CPU pipeline pressure, but in reality it seems prosessors are indeed smart enough to avoid burdoning the ALUs execution with these kinds of special cases. Read more here https://stackoverflow.com/questions/17981447/microarchitectu... > [...] these zeroing instructions extremely efficient, with a throughput of four zeroing instructons per clock cycle. Also, the xor instru…
The xor reg, reg is also special cased because it's a quick way for compilers to reinitialize a register and indicate that future uses of that register don't depend on any previous operations. It helps the cpu to parallelize any future instructions that use that register since the cpu knows that those instructions don't depend on anything that happens before the the xor.
https://randomascii.wordpress.com/2012/12/29/the-surprising-... is almost ten years old and thus likely dated, but still may be educational.
Earlier quoted context omitted.
For those who don't know, that's why big and little endian were called that, because the debate was so frivolous. It's a reference to the book Gulliver's Travels by Jonathan Swift in which an island folk was split about from which end you should crack a boiled egg. (I'm a big endian for example).
I'm firmly in the little-endian camp for eggs, but big-endian for CPUs.
Which is a real thing. There are systems that would store, say, a 32-bit word as two 16-bit words that were big endian relative to each other, but little endian within the 16-bit word.
This is pretty damn cool, but unfortunately you failed the interview as you accepted the challenge to use x86 assembler, but solved the problem using a different programming language from the one we asked you to use. We'll keep your resume on file, and if there are any openings in the future we encourage you to apply for those.
Also, we'd like to remind you that you can only re-apply after our cool-off period, which is 25 years.
> I will be using x64 assembly with the AT&T syntax as it is objectively superior than the Intel syntax. This made me laugh because it must be a reference to this: https://news.ycombinator.com/item?id=33652023 > I contend that the AT&T syntax is harmful and bad, and should never be used, for any reason, under any circumstances, by anyone.
>I will be using x64 assembly with the AT&T syntax as it is objectively superior than the Intel syntax. Them's fighting words.
That solution is terrible, with a bad algorithm that requires O(tree_height) space (the optimal one involves temporarily using left/right pointers as a parent pointer so that you only need constant space) and lacking any sort of assembly optimization, being worse than what a compiler would produce (e.g. it's a real mystery how the author managed to decide that local_right should be spilled on the stack). Definitely n…