By: ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com), June 5, 2022 7:37 am
Room: Moderated Discussions
Eric Fink (eric.delete@this.anon.com) on June 5, 2022 4:26 am wrote:
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on June 4, 2022 11:39 am wrote:
> The two major differences between a fixed-length and a variable-length encoding are that (1)
> > variable-length encoding takes a small amount of time to
> > initialize/determine those time-invariant boundaries
> > and offsets and (2) fixed-length encoding is slightly less
> > space efficient and thus takes slightly longer to
> > load from memory in case of a cache miss. In practice, (1) and (2) cancel each other out.
>
> I understand that that is the case if the variable-length encoding were more dense in practice. But there
> is very little practical difference in code density (as in — actual memory required to store the encoded
> instructions) between say x86-64 and Aarch64. So I don't see how (2) applies to this case.
(I suspect that in the following I am repeating something that has already been written elsewhere)
FL-ISA = fixed-length ISA
VL-ISA = variable-length ISA
If x86-64 had the same age as Aarch64 then x86-64 would be more space efficient than Aarch64, because a VL-ISA can use https://en.wikipedia.org/wiki/Huffman_coding where the structure of the Huffman tree is based on expected execution traces and/or on real-world execution traces.
FL-ISA cannot evolve over time using instruction prefixes of size 1 byte (unless the length of the fixed-length instructions is 1 byte or smaller). In VL encoding, the few bits reserved for future ISA extensions (such as: 2 bits in the 1st byte) are enough to enable a virtually infinite extensibility over time.
A VL encoding (such as: x86) which has accumulated various instruction prefixes over its evolution gives rise to the idea/feeling that the encoding is a compiler/programmer interface to a slightly different internal encoding specific only to the current generation of the VL-ISA CPU.
It is probable that if a FL-ISA and a VL-ISA started to be designed at exactly the same time and were introduced to the market at exactly the same moment (assuming the CPU has approximately 1 billion transistors), then consumer products with the FL-ISA would have a _temporary_ advantage over the VL-ISA products because the FL-ISA can be designed to more closely match the internal physical structure of the CPU (for example: the number of FL instructions in a cacheline is a known quantity).
-atom
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on June 4, 2022 11:39 am wrote:
> The two major differences between a fixed-length and a variable-length encoding are that (1)
> > variable-length encoding takes a small amount of time to
> > initialize/determine those time-invariant boundaries
> > and offsets and (2) fixed-length encoding is slightly less
> > space efficient and thus takes slightly longer to
> > load from memory in case of a cache miss. In practice, (1) and (2) cancel each other out.
>
> I understand that that is the case if the variable-length encoding were more dense in practice. But there
> is very little practical difference in code density (as in — actual memory required to store the encoded
> instructions) between say x86-64 and Aarch64. So I don't see how (2) applies to this case.
(I suspect that in the following I am repeating something that has already been written elsewhere)
FL-ISA = fixed-length ISA
VL-ISA = variable-length ISA
If x86-64 had the same age as Aarch64 then x86-64 would be more space efficient than Aarch64, because a VL-ISA can use https://en.wikipedia.org/wiki/Huffman_coding where the structure of the Huffman tree is based on expected execution traces and/or on real-world execution traces.
FL-ISA cannot evolve over time using instruction prefixes of size 1 byte (unless the length of the fixed-length instructions is 1 byte or smaller). In VL encoding, the few bits reserved for future ISA extensions (such as: 2 bits in the 1st byte) are enough to enable a virtually infinite extensibility over time.
A VL encoding (such as: x86) which has accumulated various instruction prefixes over its evolution gives rise to the idea/feeling that the encoding is a compiler/programmer interface to a slightly different internal encoding specific only to the current generation of the VL-ISA CPU.
It is probable that if a FL-ISA and a VL-ISA started to be designed at exactly the same time and were introduced to the market at exactly the same moment (assuming the CPU has approximately 1 billion transistors), then consumer products with the FL-ISA would have a _temporary_ advantage over the VL-ISA products because the FL-ISA can be designed to more closely match the internal physical structure of the CPU (for example: the number of FL instructions in a cacheline is a known quantity).
-atom
