4 ms·

With such a high percentage of text on the web in UTF-8, and many uses for variable-length integers, I hope that we'd see single instructions for reading and wr

by KMag 8y ago

With such a high percentage of text on the web in UTF-8, and many uses for variable-length integers, I hope that we'd see single instructions for reading and writing Unicode codepoints to/from UTF-8, as well as reading/writing 128-bit variable length integers (preferably prefix-encoded[0] rather than LEB128). A while back, I read that the Chinese Longson processors were a (subset?) of the MIPS instruction set with added instructions for Unicode handling, but that's all I've heard of processors with Unicode accelerating instructions, and I'm not sure which encoding(s) was/were accelerated. [0]https://news.ycombinator.com/item?id=11263378 https://news.ycombinator.com/item?id=11263378

chrisseaton 8y ago
> With such a high percentage of text on the web in UTF-8, and many uses for variable-length integers, I hope that we'd see single instructions for reading and writing Unicode codepoints to/from UTF-8 If we took this attitude with every new technology, we'd have a large number of instructions that are now useless. At one time it probably seemed a good idea to have custom instructions for parsing XML, and people really were doing custom instructions for interpreting JVM bytecode.
- mywittyname 8y ago
  I disagree. It's reasonable to assume UTF-8 will is here to stay. It will likely outlive any processor architectures designed today. Plus, there are already several instructions on x86 that for string manipulation.
  - loeg 8y ago
    > Plus, there are already several instructions on x86 that for string manipulation. Also SHA1, AES, CRC32, and other specialized functions that may have less staying power than UTF-8 (SHA1 in particular, but also AES being a block cipher has some nuisances that means it is not always used in new algorithms).
    - GolDDranks 8y ago
      What irks me is that the CRC32 instruction in the x86 architecture uses different polynomial than many of the CRC32 implementations in the wild, which makes the instruction unusable for them...
- AceJohnny2 8y ago
  > and people really were doing custom instructions for interpreting JVM bytecode. Ah yes, ARM Jazelle, and the good ol' ARM926EJ-S... https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle Did the concept die with ARMv8 (64bit)?
  - sigjuice 8y ago
    I don't see java in the list of features on my Raspberry Pi 3 $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
  - gsnedders 8y ago
    Yes, it's gone in ARMv8.
  - monocasa 8y ago
    It had been essentially dead for a while even before AArch64. It's slightly obfuscated by the fact that there's a version of Jazelle that's basically a nop mode that'll trap on each bytecode.
- deleted 8y ago
  [deleted]
- cyphar 8y ago
  The fact that we have AES-NI (despite the fact that AES constructions are being replaced with EC constructions in quite a few protocols, due to the difficulty of using AES in a safe way) should be clear that CPU designers don't really care about longevity, all that matters is current performance characteristics. Not to mention that I think it's fair to say that UTF-8 will outlast AES (it's actually older than AES). After all, AES was only standardised in 2001 -- and AES-NI was added when it was 7 years old. Unicode (and UTF-8) were standardised in 1991. So if we have AES instructions we should already have UTF-8 instructions.
  - rauhl 8y ago
    > The fact that we have AES-NI (despite the fact that AES constructions are being replaced with EC constructions in quite a few protocols, due to the difficulty of using AES in a safe way) Say what? Unless you mean something other than ‘elliptic curve’ by ‘EC,’ that doesn’t make sense to me: AES & EC are completely different kinds of thing, the former being symmetric & the latter being asymmetric. Indeed, it’s quite common to use an EC-derived secret as the key for AES-encrypted material.
- basementcat 8y ago
  Thanks to CPUID and analogous hardware capability registers on other platforms, outdated instruction sets can be deprecated and removed when there is no longer market demand for them.
  - chrisseaton 8y ago
    That doesn’t help if you have binaries using those instructions that you want to keep running. If it’s so easy to remove instructions how come it almost never happens for real?
    - basementcat 8y ago
      Motorola removed 64 bit MUL/DIV as well as transcendental floating point instructions (FCOS, FSIN, ...) in the 68060, ARM removed Jazelle instructions, AMD removed 3DNow! instructions. https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle https://web.archive.org/web/20131109151245/http://developer.amd.com/community/blog/2010/08/18/3dnow-deprecated/ https://web.archive.org/web/20131109151245/http://developer....
- fao_ 8y ago
  > we'd have a large number of instructions that are now useless. We already have a large number of instructions that are useless. Look at the difference between CISC and RISC.

by KMag 8y ago

chrisseaton 8y ago

> With such a high percentage of text on the web in UTF-8, and many uses for variable-length integers, I hope that we'd see single instructions for reading and writing Unicode codepoints to/from UTF-8 If we took this attitude with every new technology, we'd have a large number of instructions that are now useless. At one time it probably seemed a good idea to have custom instructions for parsing XML, and people really were doing custom instructions for interpreting JVM bytecode.

mywittyname 8y ago
I disagree. It's reasonable to assume UTF-8 will is here to stay. It will likely outlive any processor architectures designed today. Plus, there are already several instructions on x86 that for string manipulation.
- loeg 8y ago
  > Plus, there are already several instructions on x86 that for string manipulation. Also SHA1, AES, CRC32, and other specialized functions that may have less staying power than UTF-8 (SHA1 in particular, but also AES being a block cipher has some nuisances that means it is not always used in new algorithms).
  - GolDDranks 8y ago
    What irks me is that the CRC32 instruction in the x86 architecture uses different polynomial than many of the CRC32 implementations in the wild, which makes the instruction unusable for them...
AceJohnny2 8y ago
> and people really were doing custom instructions for interpreting JVM bytecode. Ah yes, ARM Jazelle, and the good ol' ARM926EJ-S... https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle Did the concept die with ARMv8 (64bit)?
- sigjuice 8y ago
  I don't see java in the list of features on my Raspberry Pi 3 $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
- gsnedders 8y ago
  Yes, it's gone in ARMv8.
- monocasa 8y ago
  It had been essentially dead for a while even before AArch64. It's slightly obfuscated by the fact that there's a version of Jazelle that's basically a nop mode that'll trap on each bytecode.
deleted 8y ago
[deleted]
cyphar 8y ago
The fact that we have AES-NI (despite the fact that AES constructions are being replaced with EC constructions in quite a few protocols, due to the difficulty of using AES in a safe way) should be clear that CPU designers don't really care about longevity, all that matters is current performance characteristics. Not to mention that I think it's fair to say that UTF-8 will outlast AES (it's actually older than AES). After all, AES was only standardised in 2001 -- and AES-NI was added when it was 7 years old. Unicode (and UTF-8) were standardised in 1991. So if we have AES instructions we should already have UTF-8 instructions.
- rauhl 8y ago
  > The fact that we have AES-NI (despite the fact that AES constructions are being replaced with EC constructions in quite a few protocols, due to the difficulty of using AES in a safe way) Say what? Unless you mean something other than ‘elliptic curve’ by ‘EC,’ that doesn’t make sense to me: AES & EC are completely different kinds of thing, the former being symmetric & the latter being asymmetric. Indeed, it’s quite common to use an EC-derived secret as the key for AES-encrypted material.
basementcat 8y ago
Thanks to CPUID and analogous hardware capability registers on other platforms, outdated instruction sets can be deprecated and removed when there is no longer market demand for them.
- chrisseaton 8y ago
  That doesn’t help if you have binaries using those instructions that you want to keep running. If it’s so easy to remove instructions how come it almost never happens for real?
  - basementcat 8y ago
    Motorola removed 64 bit MUL/DIV as well as transcendental floating point instructions (FCOS, FSIN, ...) in the 68060, ARM removed Jazelle instructions, AMD removed 3DNow! instructions. https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle https://web.archive.org/web/20131109151245/http://developer.amd.com/community/blog/2010/08/18/3dnow-deprecated/ https://web.archive.org/web/20131109151245/http://developer....
fao_ 8y ago
> we'd have a large number of instructions that are now useless. We already have a large number of instructions that are useless. Look at the difference between CISC and RISC.