Re: Byte Addressability And Beyond

Anton Ertl wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Tue, 28 May 2024 16:02:10 -0000 (UTC), Thomas Koenig wrote:
>

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

>
On Mon, 27 May 2024 19:09:51 -0000 (UTC), John Levine wrote:
>

According to EricP  <ThatWouldBeTelling@thevillage.com>:

>
One could have instructions that make it easier to parse the variable
length UTF-8 sequences into codepoints.

 What for?  Dealing with code points is rarely necessary, so adding
instructions for that is a waste (and it's not surprising to me that
neither AMD64 nor ARM A64 have such instructions; IBM z seems to be
add special instructions that are rarely useful as marketing
argument).
 

That would be the CU14 instruction on zSeries, to turn UTF-8 into
UTF-32. CU41 goes the other way.

>
What is the point, in this day and age, of having special machine
instructions to convert character encodings?

>
Have you looked at decoding algorithms for UTF-8?

>
Of course. Isn’t the point of RISC that these complex operations are more
efficiently performed by a sequence of simpler instructions?

 The IBM z series are not RISCs.
 Anyway, such instructions can be done in a RISCy way (pure
register-to-register instructions) or in a CISCy way
(memory-to-memory).
 A RISCy way to do UTF-8 -> UTF-32 would be to have the first 4 bytes
of the remaining string in a register and producing an UTF-32 code
point in another register and a length in a third register (or in the
high part of the destination register to reduce write port
requirements).  Similarly for UTF-32->UTF-8, with the length
specifying the length of the result; that would need to be combined
with a length masked store to make it easy to store the result.
 This approach can also be SIMDified, converting regbits/32 code points
in one representation to the same number of code points in the other
representation plus a length of the UTF-8 representation.
 The disadvantage of this approach exists particularly for
UTF-8->UTF-32: this is a very sequential approach full of dependences:
each use of the conversion instruction is followed by a dependent load
of the next input fragment, and the next use of the conversion
instruction depends on that load.

Rather the opposite:
UTF8->UTF32 looks a _lot_ like an easier example of a byte-oriented variable length (x86?) instruction decoder, but with the big simplification that the first byte directly tells you how long the sequence is.
Doing a SIMD version corresponds to a superscalar x86 in that the decoder needs to grab a variable number of bytes for each instruction, starting the next immediately after.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"