[continued from previous message]   
      
   Many vector machines (RISCV-V) have a way of specifying the vector   
   length and element size, but it tends to be a global setting which may   
   be overridden in some cases by specifying in the instruction. For Qupls   
   it also allows setting based on the data type which is a bit of a   
   misnomer, it would be better named data format. It is just three bits in   
   the instruction that select one of the fields in the VLEN, VELSZ   
   registers. The instruction itself specifies the data type for the   
   operation on an opaque bag of bits. It is possible to encode selecting   
   the integer size fields, then performing a float operation on the data.   
      
   The size agnostic instructions use the micro-op translator to convert   
   the instructions into size specific versions. The translator calculates   
   the number of architectural registers required then puts the appropriate   
   number of instructions (up to eight) in the micro-op queue.   
      
   Therefore, there are lots of vector instructions in the ISA. SIMD type   
   instructions where the size of a vector is assumed to be one register,   
   and the element size is specified by the instruction. So, separate   
   instructions for 1,2,4 or 8 elements. (For example 50 instructions *   
   four different sizes = 200 instructions). Then also size agnostic   
   instructions where the size/format comes indirectly from the VLEN   
   (vector length) and VELSZ (vector lane size) registers.   
      
   The size agnostic instructions allow writing a generic vector routine   
   without needing to code the size of the operation. This avoids having a   
   switch statement with a whole bunch of cases for different vector   
   lengths. It also avoids having thousands of vector instructions. (50   
   instructions * 5 different lanes sizes * 64 different lengths).   
      
   The vectors are opaque blobs of bytes in my case. Size specs are in   
   terms of bytes. The vectors are not a fixed length. They may (currently)   
   use from 0 to 8 GPR registers. Hence the need to specify the length in   
   use. While the length could be specified as part of the format for the   
   instruction, that would require a wide instruction.   
      
   *****   
      
   .flic file format is supposed to be fast enough to allow use “on the   
   fly”. But I just decompress all the frames into a matrix of bitmaps at   
   game startup, then select the appropriate one based on direction and   
   timing. With dozens of different sprites and hundreds of frames, I think   
   it takes about 3GB of memory just for the sprite data. I had trouble   
   running this on my machine a few years ago, but maybe with newer   
   technology it could work.   
      
   Experimented some with LZ4 and Huffman encoding. Huffman used for ECC logic.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)