2 ms·

Alright, this is Hacker news, so I'm gonna nitpick... > It even would have a special instruction for unpacking UTF-8 characters From https://en.wikipedia.org/

Alright, this is Hacker news, so I'm gonna nitpick... > It even would have a special instruction for unpacking UTF-8 characters From https://en.wikipedia.org/wiki/Reduced_instruction_set_computer#Characteristics_and_design_philosophy https://en.wikipedia.org/wiki/Reduced_instruction_set_comput... : > The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced—at most a single data memory cycle—compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction. I don't think what you're describing is a RISC processor at all.

kbolino 2y ago
Whether accelerated UTF-8 decoding breaks RISC-ness is an interesting question, and not one with an obvious answer IMO. Supposing we loaded 4 bytes into a register with a load instruction (quite RISC), we could then have a "decode UTF-8" instruction which could set two output registers: one receiving the decoded code point, and the other receiving the number of bytes consumed (1-4). That's another perfectly RISCy operation: read one input register, operate on it, update two output registers. Most RISC architectures also allow base+offset addressing at least, so you can chain this to another load using the output of that second register; worst case, you'd need to add base+offset in a dedicated instruction. No violations of RISC here. However, you'd start running into problems with alignment. Loading 4 bytes into a register typically requires 4-byte alignment, but UTF-8 is a variable-length encoding (hence the desire to accelerate it in the first place!). Is unaligned load RISCy? Many architectures now support it, but they usually didn't start off with it. Then again, 64-bit architectures can just ignore the problem entirely, since they can load 8 bytes at a time, which will always be enough to fit an arbitrary 4-byte value at any alignment. You'd just need to shift the value in the register by the amount of the misalignment, which is another valid RISC operation. If you wanted to sidestep the alignment issue, then an alternate solution would be to decode the UTF-8 sequence straight from memory, but that definitely feels more like CISC to me.

kbolino 2y ago

Whether accelerated UTF-8 decoding breaks RISC-ness is an interesting question, and not one with an obvious answer IMO. Supposing we loaded 4 bytes into a register with a load instruction (quite RISC), we could then have a "decode UTF-8" instruction which could set two output registers: one receiving the decoded code point, and the other receiving the number of bytes consumed (1-4). That's another perfectly RISCy operation: read one input register, operate on it, update two output registers. Most RISC architectures also allow base+offset addressing at least, so you can chain this to another load using the output of that second register; worst case, you'd need to add base+offset in a dedicated instruction. No violations of RISC here. However, you'd start running into problems with alignment. Loading 4 bytes into a register typically requires 4-byte alignment, but UTF-8 is a variable-length encoding (hence the desire to accelerate it in the first place!). Is unaligned load RISCy? Many architectures now support it, but they usually didn't start off with it. Then again, 64-bit architectures can just ignore the problem entirely, since they can load 8 bytes at a time, which will always be enough to fit an arbitrary 4-byte value at any alignment. You'd just need to shift the value in the register by the amount of the misalignment, which is another valid RISC operation. If you wanted to sidestep the alignment issue, then an alternate solution would be to decode the UTF-8 sequence straight from memory, but that definitely feels more like CISC to me.