where there are links to a couple of patents filed by Intel in 2000, about a 64-bit extension of the x86 ISA, which had been implemented in Pentium 4, but which had been nonetheless disabled and hidden from the users, in order to not compete with Itanium.
The page explains the content of the patents.
As already mentioned by another poster, at least on Firefox you have to open a tab and then copy this link there, to avoid being identified as an "undesirable" :-)
Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement.
When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.
I've seen benchmarks that go both ways in terms of a "winner" but in terms of overall variance there seems to be very little. There are some cases where ARM64 or RISCV do better and there are some cases where x86_64 does better. I can't see code density being a relevant factor when picking one ISA over another.
We've got good compilers now anyways.. outside of power consumption.. the ISA wars are dead.
Technically, code density still matters - because both L1 cache memory and L1 instruction fetch misses are very expensive.
But as you point out, code density gets far less attention in tech circles these days. And higher-level decision makers rightfully focus on higher-level system performance metrics.
This site redirects to HN when it notices HN in the referrer.
This is an interesting way to prevent the hug of death. I wonder what the author's reasoning is, also would it really be effective?
I doubt it, the redirect is client-side, I got a flash of the page before the redirect.
If anything, it's going to at least double its traffic this way when people click again assuming they hit back somehow.
If you have JavaScript enabled, that is. JWZ at least does the redirect on the server side.
The following is pulled in from `https://soc.me/assets/js/turnBack.js`:
I wonder why Reddit is "temporarily not undesirable".Wow, I didn't even notice because I have extensions that strip the referrer header. Excellent.
open in new tab
That doesn't seem to clear the referrer, at least on Firefox. Gotta go a step further and outright copy/paste the URL into an already-created tab.
On that page, there is a link to another interesting page on the same site:
https://soc.me/interfaces/intels-original-64bit-extensions-f...
where there are links to a couple of patents filed by Intel in 2000, about a 64-bit extension of the x86 ISA, which had been implemented in Pentium 4, but which had been nonetheless disabled and hidden from the users, in order to not compete with Itanium.
The page explains the content of the patents.
As already mentioned by another poster, at least on Firefox you have to open a tab and then copy this link there, to avoid being identified as an "undesirable" :-)
Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement.
When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.
https://archive.ph/ZMsnQ
I respect the disobedience.
This is in no small part why x86 code density is awful despite variable size encoding.
Awful compared to what?
I've seen benchmarks that go both ways in terms of a "winner" but in terms of overall variance there seems to be very little. There are some cases where ARM64 or RISCV do better and there are some cases where x86_64 does better. I can't see code density being a relevant factor when picking one ISA over another.
We've got good compilers now anyways.. outside of power consumption.. the ISA wars are dead.
Technically, code density still matters - because both L1 cache memory and L1 instruction fetch misses are very expensive.
But as you point out, code density gets far less attention in tech circles these days. And higher-level decision makers rightfully focus on higher-level system performance metrics.