Re: Byte Addressability And Beyond

On 5/5/2024 12:20 PM, John Savard wrote:

On Wed, 1 May 2024 00:09:28 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
 

Big-endian
supposedly had the advantage of making memory dumps easier to read, but
little-endian always made more logical sense.

 There is one practical argument for big-endian encoding.
 Let us suppose that a computer has the ability to do *both* decimal
arithmetic and binary arithmetic.
 So a word in the computer might contain just bits, for binary
arithmetic. Or it might contain BCD digits, for decimal arithmetic.
 Since it's possible to design an adder where carrying early between
nibbles can be turned on or off, on for decimal arithmetic, and off
for binary arithmetic, clearly the order of digits - big-endian or
little-endian - should be the same between binary and decimal.
 Also, though, for ease of conversion, the order of BCD digits _should
be the same as the order of the characters of which these digits are
the last four bits_ in the representation of a decimal number as a
character string.
 And that means big-endian.
 If you have decimal arithmetic, there's a direct connection between
how numbers are represented for reading and writing, and how they are
represented for internal arithmetic.
 

Why would one burn 8 bits per BCD digit?...
More efficient to merely burn 4 bits per digit, and then use whatever is the native integer alignment (probably LE).
But, I suppose, if one had lots of ASCII decimal, could make sense to have instructions to, say, take the low 4 bits of every 8 bits in a 64/128-bit input and pack them into a 32/64-bit output, or, expand every 4 bits to 8 bits 0011xxxx, ...
Then again, in my case I had added some BCD ops as an experiment, and seemingly the only real practical use-case that came up was "well, maybe could be used to make 'printf()' slightly faster...".
Mostly moot though, as the amount of CPU time spent printf'ing decimal numbers tends to be negligible.
Vs, say, in my case if running a GUI in 256-color mode, the biggest user of CPU time tending to be the logic to repack RGB555 to 256-color, which also tends to have around a 40% L1 miss rate (mostly due to the 64K lookup table).
If anything, I would benefit more from an RGB -> 256-color converter instruction, but this would imply effectively baking a variation of the system color palette into the ISA (and probably also having an image quality reduction, *).
*: An algorithmic solution is possible, but my attempts at purely logic-driven encoding of this palette scheme have tended towards lackluster quality.
Mostly, this would involve encoding the luma in the low 4 bits, and a normalized chroma (~ RGBI) in the high 4 bits. Luma is easier, but selecting the best color vector in terms of chroma is harder.
The current palette also has an orange and azure axis (placed sideways in the "near black" area), but would likely ignore these for a HW encoder (assuming the simpler case of 16-levels of 16 colors, and clamping Y=0/1 to C=0, or the gray axis; Where: 0=Gray, 7/8/F represent off-white C/M/Y, 1..6 are high saturation RGB, and 9..E are low saturation RGB).
Would need to normalize the colors, say (pseudocode):
   Cy=max3(R,G,B);
   Yadj=31-Cy
   Rn=R+Yadj
   Gn=G+Yadj
   Bn=B+Yadj
   Cb={ 0, Rn[4], Gn[4], Bn[4] };  //high sat
   if(Cb==7)
   {
      Cb={ 1, Rn[3], Gn[3], Bn[3] };  //low sat
      if(Cb==15)
      {
         //off-white or grayscale
         if(!Rn[2])
           Cb=7;  //Cyan
         else if(!Gn[2])
           Cb=8;  //Magenta
         else if(!Bn[2])
           Cb=15; //Yellow
         else
           Cb=0;  //Gray
      }
   }
   if(cy<2)
     Cb=0;
   Ci={Cb, Cy[4:1]};  //indexed
Note that this approach was too slow to be used (in normal C) for direct color conversion, and still annoyingly slow (and not terribly accurate) for building a lookup tables.
Better lookup tables were possible by evaluating every palette color from its RGB555 value in terms of euclidean distance (and picking a pair of colors for dithering based on the closest distances to the target color), but this is impractically slow to run on a 50 MHz CPU (and could not be used for a HW encoder).
...

John Savard