Live data from Hacker News

Does a compiler use all x86 instructions? (2010)

pepijndevos.nl

131–140 of 198 posts

Re: Does a compiler use all x86 instructions? (2010)

#131

Earlier quoted context omitted.

Sure, there is a lot of historical baggage in microprocessors--the BCD stuff and x86-16 support in general only exist for backwards compatibility (although note that BIOS starts up in x86-16). But the reason that Intel keeps adding instructions is, well, because they're useful. > - Why do microprocessors not strive for simplicity, implement only a handful of instructions in an optimized way, with a very small chip fo…

> What you're describing is a GPU I would say I'm describing something halfway between a CPU and a GPU. It's not just an ALU, it's a complete microprocessor, with pipelining, caches, etc. The main difference is that the instruction set is optimized, backward compatibility is no longer a requirement, and redundancy of the architecture is eliminated.

That's literally what a GPU is.

Re: Does a compiler use all x86 instructions? (2010)

#132
post #4

> but I have no clue why there are so many lea everywhere. Pointer arithmetic? Which is used for well, ... many things.

Your username is an effective proof that the answer to the title question is "no". :)

Sorry didn't get the joke, how does it interact with reading the timestamp counter?

Isn't LEA intended to calculate addresses? It seems it also doesn't alter flags and can put its result in any register.

Re: Does a compiler use all x86 instructions? (2010)

#133

Earlier quoted context omitted.

Sure, there is a lot of historical baggage in microprocessors--the BCD stuff and x86-16 support in general only exist for backwards compatibility (although note that BIOS starts up in x86-16). But the reason that Intel keeps adding instructions is, well, because they're useful. > - Why do microprocessors not strive for simplicity, implement only a handful of instructions in an optimized way, with a very small chip fo…

> What you're describing is a GPU I would say I'm describing something halfway between a CPU and a GPU. It's not just an ALU, it's a complete microprocessor, with pipelining, caches, etc. The main difference is that the instruction set is optimized, backward compatibility is no longer a requirement, and redundancy of the architecture is eliminated.

GPUs have both pipelining and caches, so those don't serve to distinguish your idea from a GPU. Also remember that the barrier to spreading out computation over more cores is that many of our algorithms don't parallelize well, not that we can't fit 1024 cores into a computer. There's already been a huge incentive to get programs (even those used on regular desktops and not high performance computers) to parallelize well since we hit the clock-rate ceiling, but a lot of problems still have trouble saturating even a 4 core system.

Re: Does a compiler use all x86 instructions? (2010)

#134
post #78

And therein lies the rub. What is the minimum number of instructions a compiler could make use of to get everything done that it needs? I came across an article that says 'mov is turing complete' [1]. But they had to do some convoluted tricks to use mov for all purposes. I think it's safe to say that about 5-7 instructions are all that's needed to perform all computation tasks. But then: - Why do compilers not strive…

> - Why do microprocessors not strive for simplicity, implement only a handful of instructions in an optimized way, with a very small chip footprint, to be followed by proliferation of cores (think 256-core, 512-core, 1024-core).

Because that would not make CPUs faster or cheaper.

If you think that modern CPUs are large because they implement a lot of instructions, you are completely wrong. The entire machinery needed for executing more than a couple of different instructions is less than 1% of the core. The space is not taken up by decoding tables or ALUs, it's taken up by forwarding networks, registers, and most of all, cache. And all of those are things very much required to make a CPU fast. CPUs have a lot of instructions precisely because the cost of implementing a new instruction is negligible compared to the size of the CPU.

Re: Does a compiler use all x86 instructions? (2010)

#135
post #4

> but I have no clue why there are so many lea everywhere. Pointer arithmetic? Which is used for well, ... many things.

Pointer creation I think.

Originally it was for address calculations it seems. But can also be used to do other calculations not just for addresses.

Which I assumed to be equivalent to something like: res = ptr_base + offset

Re: Does a compiler use all x86 instructions? (2010)

#137

In general: * x87 floating point is generally unused (if you have SSE2, which is guaranteed for x86-64) * BCD/ASCII instructions * BTC/BTS/related instructions. These are basically a & (1 * MMX instructions are obsoleted by SSE * There's some legacy cruft (e.g., segment management) that's generally unused by anyone not in 16-bit mode. * There are few odd instructions that are basically no-ops (LFENCE, branch predicto…

> * There's some legacy cruft (e.g., segment management) that's generally unused by anyone not in 16-bit mode.

x86 NaCl uses segments for sandboxing.

Re: Does a compiler use all x86 instructions? (2010)

#138

Earlier quoted context omitted.

Modify the backend, or do a binary translation from one to the other and test. If `lea` is the predominate instruction, there might be microcode optimizations that favor `lea` over `movl`. My hunch is that is will be mostly the same barring overflowing the instruction cache. The microps should compile to the same instruction stream.

No, LEA issues as a single micro-op on modern Intel CPUs, but no x86 CPU will merge a sequence of shift and add into a single micro op.

How would one find this out? Sounds like it would be fun to figure out how to develop all possible reasonably compact instruction combinations to achieve the same basic block and then compare timings.

Re: Does a compiler use all x86 instructions? (2010)

#140

Earlier quoted context omitted.

No, LEA issues as a single micro-op on modern Intel CPUs, but no x86 CPU will merge a sequence of shift and add into a single micro op.

How would one find this out? Sounds like it would be fun to figure out how to develop all possible reasonably compact instruction combinations to achieve the same basic block and then compare timings.

http://www.agner.org/optimize/

Document 4.

Post reply on HN