CryptoRndIV

[srvaldez]

So, I tried this:

Code: Select all

*(Cast(Uinteger Ptr, BaseBuffer) + Counter) = GetRdRand

that should work, your dword prefix error must be caused by something else

[deltarho[1859]]

Ah! I commented what I thought, was the offending statement and I still get 'Error: redundant dword prefix'

In the original code I had: 'movd xmm0, [wax]' and adeyblue changed that to 'movd xmm0, dword [wax]'

The dword prefix is redundant because it is implicit by virtue of movd

I had four like that and corrected them.

However, I am still getting 'Error: redundant dword prefix' and, presently, cannot find the offender.

How the blazes did that compile the other day. Answers on a postcard to ...

[deltarho[1859]]

I am now in deep trouble.

I have four instances of using a dword prefix, and they are all connected with a Ulong, so they are OK.

In 64-bit mode I am still getting the same error but '#define data_size qword' is being used.

There are no other dword prefixes for the compiler to complain about.

[srvaldez]

try something like this

Code: Select all

  Asm
    mov rax, [ptrBuffer]
    mov eax, dword [rax]
    mov [Function], eax
  End Asm

[deltarho[1859]]

I made another change and with gas64 I am getting 'Error: junk at end of line, first unrecognized character is `-'. With gcc -O2 in 64-bit mode, I am getting I am getting Error: `dword' is not supported in 64-bit mode.

Where is the compiler getting this rubbish from – ChatGPT?

[adeyblue]

Compile with -RR and then you can look in the asm file at the offending line the error is complaining about. Now at least you can know which line of your assembly it's complaining about

[deltarho[1859]]

Thanks, adeyblue.

I don't find asm files particularly readable.

In 64-bit mode I saw a lot of 'push' going on. I thought we couldn't use push in 64-bit mode.

In FillBuffer I only found one Dword mentioned and that was to do with a Ulong.

So -RR did nothing for me. I cannot remember when it ever did, but I haven't used it much. After so many useless uses, I stopped using it.

[deltarho[1859]]

Sorry, srvaldez I missed your post.

You are asking me to try something that the compiler is not complaining about, so I won't be trying that.

Currently, I don't know what the compiler is complaining about. It isn't fbc because it creates the asm. Having said that, gas64 comes up with a barmy complaint – 'Error: junk at end of line, first unrecognized character is `-'; entirely different to gcc's complaint.

[deltarho[1859]]

I have just commented all references to FillBuffer, and I am getting no warnings or errors, so something is wrong with FillBuffer.

I shall now plod through that line by line with my fingers crossed.

PS Tomorrow – it is late in the UK.

[deltarho[1859]]

OK, I found the issue. It was a monumental error – I jumped out of an asm bock into BASIC.

RdRand is an opcode, so failing anything else we have to use asm and we should not assume a success. 'RdRand wax' effectiively generates three flags. One flag advises a success, another flag advises a retry, and the third flag advises us to give up and use a FB #5 random number. The likelihood of the latter is almost zero because 10 tries are allowed

In asm it is easy to jump to the appropriate action.

What I needed to do was to save those flags in a BASIC variable, excepting the retry, which can be done in the asm block. After leaving the asm block we can simply read the BASIC variable and act accordingly.

Having done that, I am now getting a compilation with all four compilers.

That was easy, nearly.

However, I have a counter, in BASIC, which moves us along the buffer storing successful RdRands.

For the four half buffers initially populated the counter should increment by 4,4,4,4 then 8,8,8,8 and so on for 32-bit. However, the counter is incrementing on every pass of the FillBuffer procedure, so the buffers do not get saturated. This does not happen when we count using registers in the asm version of FillBuffer.

I suppose I could count the passes and only increment the counter every four passes of FillBuffer. However, after the second buffer is populated, four half buffers, we reduce the passes to two half buffers. There is always an answer, but the BASIC is going to get a bit heavy compared with the asm version, defeating the object. It could well be that on this occasion the asm route is the better of the two approaches.

Not being an asm expert, it can be difficult to convert BASIC to asm every so often. Converting asm to BASIC is proving a nightmare. Getting it to BASIC will result in more readable code, but it isn't much use if it doesn't work.

Anyway, I shall keep chugging away, but the fun is dropping like a stone.

Oh, I did another test calculating the averages of 10^8 requests with the asm version of FillBuffer to cheer myself up and got this:

Code: Select all

Av DW  2147489867.361357
Av S  0.4999929391914737
Av SX -5.49521476356592e-005
Av D  0.5000331828187322
Av DX  6.946084683554035e-006

Now isn't that a joyful sight?

[deltarho[1859]]

I have been too busy today doing other things, but I have had a thought.

There are three stages with the thread pooling method employed: ThreadInit, ThreadStart, and ThreadWait. The individual buffer addresses are passed to FillBuffer via ThreadStart(Byval p As Any Ptr). Currently, p is only the address of BaseBuffer. It could be the address of a UDT with the address of BaseBuffer and its counter.

I will be busy again tomorrow, so will have a look at that over the weekend.

[Provoni]

Through the years I have followed your threads about rng's with interest and the topic of randomness intrigues me highly.

It is a deeply profound concept and something which I consider to be an anti-primitive since I cannot think or fathom any process that could produce true random numbers in the most absolute and highest meaning of the word 'randomness'.

Yet we do understand the concept and know how it should behave and invent algorithms that approximate its behaviour for various meaningful reasons. Yet we cannot truly have it. For me, this is typical of life, handle it with grace and you will do well.

Also thanks to fxm for his work on threading.

[deltarho[1859]]

It is a deeply profound concept

It is and one which many have difficulty in grasping.

I have had umpteen arguments over at PowerBASIC about John Walker's ent.exe.

Many are convinced that Chi Squared is a good test for randomness. It isn't. It can be used to test goodness of fit. If we take the data to be analysed and dropped them onto the floor and picked them up sorted descending or ascending or at random the chi squared value is unaltered. Chi squared is interested only in comparing observed data with expected data. In other words the distribution uniformity. QBASIC's random number generator has a remarkable distribution uniformity, but its randomness is poor.

What fascinates me with true random numbers is what motivates an event to occur when or where without any relationship whatsoever with previous events.

It seems to me that in the relativistic world, there is no such thing as truly random. On the other hand, in the quantum world truly random seems to be the order of the day. To get true random numbers, we need to venture into the quantum world, and RdRand takes a stab at that by analysing the noise on the surface of a CPU. It is then subjected to a few cryptographic procedures to give us 16, 32, and 64 bits of results.

Microsoft's BCryptGenRandom gathers an enormous amount of data from a running PC.

PractRand is good for testing randomness. However, beyond a certain point it fails to differentiate between RdRand and BCryptGenRandom, reckoning them to be equally good. RdRand must be better than BCryptGenRandom. When it comes to making decisions, I doubt that BCryptGenRandom would lead us up the garden path. RdRand is as good as it gets without resorting to additional hardware. Some PRNG's like MsWsII and PCG32II have a faster throughput than CryptoRndIV, but I doubt that our applications would benefit.

Also thanks to fxm for his work on threading.

Yes, that is an astonishing achievement and well beyond the capabilities of most of us on this forum.

[adeyblue]

So -RR did nothing for me. I cannot remember when it ever did, but I haven't used it much. After so many useless uses, I stopped using it.

The bits between /APP and /NO_APP in the asm file are from FB Asm blocks. The line number in the assembler error message correspond with the lines in the asm file.


This doesn't compile for instance because you can't push or pop 32-bit values in x64 assembly. Not that that's a particularly obvious conclusion from the first error message, but we can't really do anything about gas's error messages.

[deltarho[1859]]

@adeyblue

Thanks for that. I haven't used Notepad for years. The 'Go To Line' is very handy.