Random-number generation

[Arlet]

In your code, when you do 'rndbyte = (rndbyte + carry)' you should generate an additional carry when rndbyte=255 and carry=1

[Arlet]

Alex1 wrote:

Found '008AA873' at index 0 !
Found '008AA873' at index 11EC9D07 !
Found '008AA873' at index 36982356 !
Found '008AA873' at index B20751BF !

I don't see that. Here is my output (byte #, internal state, output byte)

Code: Select all

11ec9d02 : 8a a0 25 94 ba 34 ef - 55
11ec9d03 : cf 6f 95 29 81 b6 a5 - 24
11ec9d04 : 14 84 19 43 67 1e c4 - a3
11ec9d05 : 59 dd f6 39 65 84 48 - 2d
11ec9d06 : 9e 7b 72 ac 49 ce 16 - 5f
11ec9d07 : e3 5e d1 7d b5 83 9a - 2f
11ec9d08 : 28 87 58 d6 01 85 1f - 1e
11ec9d09 : 6d f4 4c 23 3e c3 e2 - dc
11ec9d0a : b2 a6 f3 16 33 f7 d9 - ea
11ec9d0b : f7 9d 91 a8 a4 9b 75 - d1

[Alex1]

Arlet wrote:

In your code, when you do 'rndbyte = (rndbyte + carry)' you should generate an additional carry when rndbyte=255 and carry=1

ah yes, thanks !

[Arlet]

Here's when I see the bytes 00 8A A8 73 in sequence:

Code: Select all

(index)    : internal state       - output 4-byte sequence
0000000004 : 14 b3 66 74 dc ce af - 73 008aa873
001b4c11af : 2b 0c f5 cc 69 0f 1a - 73 008aa873
031110bb51 : d5 19 99 54 ff aa 8c - 73 008aa873
036d723c01 : 45 71 51 42 13 8c 60 - 73 008aa873
038707f8e7 : 43 72 c4 30 59 ea 2a - 73 008aa873

As you can see, even though the sequence 00 8A A8 73 shows up repeatedly, the internal state differs. That's because you're only watching 4 consecutive bytes, but there are 7 bytes of state.

[Alex1]

Arlet wrote:

Alex1 wrote:

Found '008AA873' at index 0 !
Found '008AA873' at index 11EC9D07 !
Found '008AA873' at index 36982356 !
Found '008AA873' at index B20751BF !

I don't see that. Here is my output (byte #, internal state, output byte)

Code: Select all

11ec9d02 : 8a a0 25 94 ba 34 ef - 55
11ec9d03 : cf 6f 95 29 81 b6 a5 - 24
11ec9d04 : 14 84 19 43 67 1e c4 - a3
11ec9d05 : 59 dd f6 39 65 84 48 - 2d
11ec9d06 : 9e 7b 72 ac 49 ce 16 - 5f
11ec9d07 : e3 5e d1 7d b5 83 9a - 2f
11ec9d08 : 28 87 58 d6 01 85 1f - 1e
11ec9d09 : 6d f4 4c 23 3e c3 e2 - dc
11ec9d0a : b2 a6 f3 16 33 f7 d9 - ea
11ec9d0b : f7 9d 91 a8 a4 9b 75 - d1

Here is the code i use, something wrong with unint_t ? Could you paste your C code ready to compile ?

Code: Select all

#include <stdint.h>
#include <stdio.h>


#define ADD( a, b )                 \
    do {                            \
        x = a + (b);                \
        a = x;                      \
    } while (0)

#define ADC( a, b )                 \
    do {                            \
        x = a + (b) + (x >> 8) % 2; \
        a = x;                      \
    } while (0)

    uint16_t x;

void main()
{
    
    uint8_t s0,s1,s2,s3,s4,s5,s6,res;
    uint32_t z,q;
  
    s0=0;s1=0;s2=0;s3=0;s4=0;s5=0;s6=0;
    q=0xffffffff;
       
    for (z=0;z<q;z++)
    {
        ADD( s0, 0x45 );
        ADC( s1, s0 );
        ADC( s2, s1 );
        ADC( s3, s2 );
        ADC( s4, s3 ^ s6 );
        ADC( s5, s4 );
        ADC( s6, s5 );
        res= s6 ^ s4;
       // putchar( s6 ^ s4 );
        printf("%0.2X",res);
        //printf("%0.2X %0.2X %0.2X %0.2X %0.2X %0.2X %0.2X %0.2X\n", s0,s1,s2,s3,s4,s5,s6,res);
		
	       
    }

}

[Arlet]

That looks good, as far as I can see, but when I run it, I don't see 008AA873 at index 11EC9D07

[Alex1]

Arlet wrote:

Here's when I see the bytes 00 8A A8 73 in sequence:

Code: Select all

(index)    : internal state       - output 4-byte sequence
0000000004 : 14 b3 66 74 dc ce af - 73 008aa873
001b4c11af : 2b 0c f5 cc 69 0f 1a - 73 008aa873
031110bb51 : d5 19 99 54 ff aa 8c - 73 008aa873
036d723c01 : 45 71 51 42 13 8c 60 - 73 008aa873
038707f8e7 : 43 72 c4 30 59 ea 2a - 73 008aa873

As you can see, even though the sequence 00 8A A8 73 shows up repeatedly, the internal state differs. That's because you're only watching 4 consecutive bytes, but there are 7 bytes of state.

Okay so you find the same repetitive outputs, but why don't you find them at the same indexes as on my side?
Can an onverflow cause this?
something with uint16_t and uint8_t ? Data loss during conversion?

[gfoot]

I think you need to cast up to uint16_t before adding, inside the macros. Otherwise it does the add truncated to 8 bits, even though the result is stored in a 16 bit variable.

Edit: here for sure in ADD - doesn't matter which operand you cast:

Code: Select all

x = (uint16_t)a + (b);

And maybe similarly in ADC though in that one the fact that "x" is involved might mean it's already evaluated at 16 bits - I don't recall whether these things associate left or right though so maybe casting the a or b term would be needed.

[Alex1]

gfoot wrote:

I think you need to cast up to uint16_t before adding, inside the macros. Otherwise it does the add truncated to 8 bits, even though the result is stored in a 16 bit variable.

could you give me an example ?

[Arlet]

According to C standard, addition of smaller integer types should be promoted to 'int' before doing the addition, so there's no need to do a cast first.

[Arlet]

Alex1 wrote:

Okay so you find the same repetitive outputs, but why don't you find them at the same indexes as on my side?

I copied your program, and then let it run to the point where you found the first repetition, and printed out the values. At that point, I did not see the pattern in the output.

[gfoot]

Arlet wrote:

According to C standard, addition of smaller integer types should be promoted to 'int' before doing the addition, so there's no need to do a cast first.

Ah OK, apologies, I had thought it just promoted to the wider width of the two.

[Alex1]

Arlet wrote:

Alex1 wrote:

Okay so you find the same repetitive outputs, but why don't you find them at the same indexes as on my side?

I copied your program, and then let it run to the point where you found the first repetition, and printed out the values. At that point, I did not see the pattern in the output.

Then it's a compilation problem. I'm on linux ARM.

How should i cast your code to try if the problem is solved with it ?

[Arlet]

gfoot wrote:

Ah OK, apologies, I had thought it just promoted to the wider width of the two.

It does that too, but only if one of the types is larger than 'int'. So if you do int + long, it will first promote the 'int' to 'long' and then do long+long addition.

[Arlet]

I added this to your code:

Code: Select all

        ADC( s3, s2 );
        ADC( s4, s3 ^ s6 );
        ADC( s5, s4 );
        ADC( s6, s5 );
        res= s6 ^ s4;
        if( z > 0x11EC9D00 )
        {
            printf("%08x : %0.2X %0.2X %0.2X %0.2X %0.2X %0.2X %0.2X = %0.2X\n", z, s0,s1,s2,s3,s4,s5,s6,res);
            if( z > 0x11EC9D10 )
                break;
        }

When I run it, I get this:

Code: Select all

11ec9d01 : 8A A0 25 94 BA 34 EF = 55
11ec9d02 : CF 6F 95 29 81 B6 A5 = 24
11ec9d03 : 14 84 19 43 67 1E C4 = A3
11ec9d04 : 59 DD F6 39 65 84 48 = 2D
11ec9d05 : 9E 7B 72 AC 49 CE 16 = 5F
11ec9d06 : E3 5E D1 7D B5 83 9A = 2F
11ec9d07 : 28 87 58 D6 01 85 1F = 1E
11ec9d08 : 6D F4 4C 23 3E C3 E2 = DC
11ec9d09 : B2 A6 F3 16 33 F7 D9 = EA
11ec9d0a : F7 9D 91 A8 A4 9B 75 = D1
11ec9d0b : 3C DA 6B 14 06 A2 17 = 11
11ec9d0c : 81 5B C7 DB D2 74 8C = 5E
11ec9d0d : C6 21 E9 C4 1B 90 1C = 07
11ec9d0e : 0B 2D 16 DB E2 72 8F = 6D
11ec9d0f : 50 7D 93 6E C4 37 C7 = 03
11ec9d10 : 95 12 A6 14 98 D0 97 = 0F
11ec9d11 : DA EC 92 A7 C8 98 30 = F8

can you try that too?