From: cr88192@gmail.com   
      
   On 12/25/2025 1:31 PM, Lawrence D’Oliveiro wrote:   
   > On Thu, 25 Dec 2025 03:07:03 -0600, BGB wrote:   
   >   
   >> One entropy-mining process is to use "clock()" or similar and then   
   >> spin in a loop for a certain amount of time effectively building a   
   >> hash of the values returned by clock. The exact timing when the   
   >> values change will tend to carry a certain amount of entropy.   
   >   
   > The turbulence of the air/gas inside disk drives is apparently a good   
   > source of randomness.   
      
   Yeah, but one doesn't easily have access to this information.   
   Likewise to access from the low order bits of CPU thermometers or   
   similar, etc.   
      
   For some of my targets, there is also no HDD (typically, everything runs   
   off of SD cards).   
      
      
   FWIW, in my own CPU design, there is actually a hardware RNG where   
   internal signals are basically gathered up and fed around the bus in a   
   special noise channel and used to continuously feed into a hardware RNG   
   for which a value can be read with a special CPU instruction.   
      
   But, alas, mainline CPUs lack such a feature.   
      
   On x86, it is also possible to get some level of entropy from mining   
   RDTSC, but this is non-portable.   
      
      
      
      
   But, yeah, tested out a few more RNG designs, and ATM:   
   	seed1 ^= ~(seed2>>47);	seed2 ^= ~(seed1>>43);  // 4 cycles   
   	seed1 ^=  (seed1<<13);	seed2 ^=  (seed2>>11);  // 4 cycles   
   	seed1 ^=  (seed1>>19);	seed2 ^=  (seed2<<17);  // 4 cycles   
   	val = ((seed1 ^ seed2) >> 32) & 0x7FFF;         // 6 cycles   
   Seems to be working pretty OK (decent randomness), and is moderately fast.   
      
   Add cost of +4 cycles for LD (2c penalty), +2 ST   
   Est cost: Around 24 clock cycles.   
      
      
   Though, breaking up the shifts and xors using temporaries could be used   
   to micro-optimize it a little more (vs trying to rely on compile-time   
   instruction shuffling).   
      
   Downside as that this particular approach (XOR'ing values with   
   themselves and modifying the original variable before the next step),   
   creates a lot of dependencies which limits the potential ILP (can't get   
   ILP over 2 in this case).   
      
   Where, the interleaved "seed1 = (seed1<>SH2);" pattern   
   allows for slightly higher ILP, but seemingly gets less randomness per   
   shift (so the total dependency length ends up similar).   
      
   In the CPU in question, would effectively need 4 seed values to get   
   better ILP, say:   
   	seed1 ^= ~(seed2>>47);	seed2 ^= ~(seed3>>43);   
   	seed3 ^= ~(seed4>>53);	seed4 ^= ~(seed1>>41);   
              // ~ 4 cycles   
   	seed1 ^=  (seed1<<13);	seed2 ^=  (seed2>>11);   
   	seed3 ^=  (seed3<< 7);	seed4 ^=  (seed4>> 5);   
   	seed1 ^=  (seed1>>19);	seed2 ^=  (seed2<<17);   
   	seed3 ^=  (seed3>>23);	seed4 ^=  (seed4<<29);   
              // ~ 6 cycles   
   	val = ((seed1 ^ seed2) >> 32) & 0x7FFF;  // 6 cycles   
            //+ 8 cycles (Global LD/ST)   
   Est Cost: Around 24 clock cycles.   
      
   (24 cycle estimate assuming compiler shuffles instructions into a   
   roughly optimal order).   
      
      
   Though, with more operations still likely to be slower, despite the   
   higher ILP potential (the higher ILP would merely reduce the slowdown   
   from having more operations).   
      
   In this case, ideally one wants to be able to have groups of 6   
   non-dependent ALU operations on a 3-wide CPU with 2-cycle ALU latency.   
   Though, in this case, achieving peak ILP would actually require ~ 6 or 8   
   seed registers. Though, in this case, would require using XG3, for   
   RISC-V it would also suffer due to RV64 only having 32 GPRs rather than   
   64, so trying to use 8 seeds in parallel would run out of GPRs on RISC-V   
   (don't want to spill, this will hurt a lot worse than the lost ILP).   
      
   Where, if ILP is maximized, one can get to around 0.3 clock cycles per   
   operation.   
      
      
      
   But, on the target in question, 2 or 4 seeds is still likely to be   
   considerably faster than, say:   
   	seed = seed * 0x0000FC4BA2F7ACABULL + 1;   
      
   Which suffers from the "great evil" known as "slow 64-bit multiply"   
   (needs 68 cycles to do a 64-bit multiply, similar to performing a divide).   
      
   Where, the cost of the 64-bit integer multiply will stomp all over the   
   cycle cost of the former (well, and not like "rand()" tends to be used   
   all that heavily in any case).   
      
      
   Well, contrast to the naive lookup-table approach:   
      index=(index+1)&255; //latency = 8 cycles (3 LD, 2 ADD, 2 AND, 1 ST)   
      val=table[index];    //latency = 5 cycles (2 ADD, 3 LD).   
   So: ~ 13 cycles of latency.   
      
   So, looks simple, but not great in this case (both weak, and latency   
   isn't great for its weakness).   
      
      
   Then again:   
      seed = seed * 0x0000FC4BA2F7ACABULL + 1;   
        //75 cycles: 3 LD, 1 const, 68 MUL, 2 ADD, 1 ST   
      ret = (myseed >> 48) & 0x7FFF;  //4 cycles: 2 SHR, 2 AND   
   Cost: Around 80 cycles.   
      
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)