Prelim
We will start with the following assumptions. We have a pseudo random number generator with a period of $2^P$ which returns a uniform (in all bits) bitwidth result per state update.
For a 32bit generator, the basic result returns a uniform integer: uint32_t rng_u32()
Other bitwidths follow naturally assuming that they are the fullwidth of the working register. Also I will only talk about singles. A simple replacement of appropriate values/terms extends to doubles (or other poweroftwo FP representations). I will assume familarity with IEEE binary formats.
Equidistant uniform what all generators do
The standard method of generating uniform floats:
Breaking this down we start with a 32bit integer. Shifting right^{1} by eight leaves us with 24 unbiased and uniform bits and 24 is the number of bits of precision a single can hold in the normal range. Finally we multiply by $2^{24}$ giving us with a uniform (and unbiased) single on $\left[0,1\right)$
Another way to look at it is we are producing $2^{24}$ distinct values of the form $\frac{u}{2^{24}}$ with integer $u \in \left[0, 2^{24}1\right]$. These values are all equidistantly spaced across the range. This is the standard method since it’s both cheap and commonly what one needs.
Breakit down
If we think about how binary floating point values are represented, we have a sign bit (we’ll ignore), a poweroftwo exponent, and a significand (including the implied bit).

A result in top half of the range $\left[.5, 1\right)$ occurs with a probability of .5, the exponent (without offset^{2}) is 1 and the equidistant method geneates all $2^{23}$ representable values on the range. We are in this range if the top bit of $u$ is set.

If the top bit of $u$ is clear but the second bit is set, then were on $\left[.25, .5\right)$, the exponent is 2 and it generates half the representable values on the range.

If the top two bits are clear but the third is set, then were on $\left[.125, .25\right)$, the exponent is 3 and it generates one quarter of the representable values on the range.

At the other end we have one value with exponent of 24, two with 23, four with 22, etc. (setting aside the $u=0$ case)
This all boils down to:
 We have uniform bits
 The probability any given bit is clear is .5, so the probability that the top $n$ bits^{3} are clear is $2^{n}$.
 This is the geometric distribution^{4} with $p=.5$
 The conversion of integer to float implictly performs a lead zero count
 We’re dropping one bit of density per exponent because of the lead zero count/geometric distribution.
Of course none of this matters unless you actually need uniform results with higher density.
Dense uniform floats
Defining an toy problem statement: Generate a uniform float on $\left[0,1\right)$ which produces all representable values on the interval.
All the code snippets are example toys. The final section is important.
Instead of throwing away bits and then using the automatic leadzerocount of integer to float conversion we can manually perform the LZC to generate dense uniform floats. The newjack CS way is to break the problem down into easy/reusable parts. So first we need to generate a random value with a geometric distribution with .5 probability of success:
The loop is ensured to terminate. On any given iteration the probabilty we fall through is $12^{32} \approx 0.9999999998 $. Note that LZC on a 32bit integer returns a value on $[0,32]$ which is 33 values..an easy thing to get tripped up on.
We can rewrite^{5} to eliminate uneeded overhead for the statistically significant case:
Taking the definition of binary32 format our dense float routine becomes:
Which isn’t too bad, not much over embellishment. Just needs some comments and meanful numeric defines.
Let’s do something similar in an OG style. Rather than recreate the same thing, let’s generate a value on $\left(0,1\right)$ with all representable value on the normal range (the smallest value will be $2^{126}$). Not only are denormals highly unlikely to occur they are probably useless or undesirable results.
First we’ll generate one uniform integer and try to get as far as we can with it. We need 23 bits for the significand, so that leave us 9 to try to compute the exponent. If that didn’t work out can we complete with exactly one more? And if THAT doesn’t work out, well we don’t care very much.
Statistically we done after generating one uniform instead of the minimum two in the previous. There are many possible variants possible here.
The parts I’m not tell you
Aside: Although written in terms of leading zeroes any choice of leading/trailing ones/zeroes is okay.
As written the results will be biased^{6}. Not due to the pigeonhole principle, but the because of the period of the generator. A given assumption is that we have a generator with period $2^P$. Considering the state of the generator as a $P$ bit integer, then the sequence produced is a permutation of $\left[0,2^P1\right]$. Specifically each value will occur exactly once in the sequence. As an example let’s say we’re using a 32bit generator with $P=32$ (a single state chunk). Zero be returned exactly once per period by rng_u32()
, so our geometric generator would return exactly one value greater than 31 (based on whatever number follows zero in the sequence) once per period and never any greater values. Additionally many current generators have periods of $2^P1$, where zero is excluded from the sequence. In the $2^{32}1$ case the geometric generator would never return a value greater than 31. For an output value of $n$ there would be $2^{31n}$ positions in the sequence that generate that value. The few the positions the less random these results will be.
Possible solutions:
 Don’t care and structure the code to not deal with impossible situations.
 Use a generator with larger $P$.
 Don’t use all the returned bits, such as XOR the top half with bottom half and use that half bitwidth result.
 Extension of previous: generate two values, XOR and use that result instead.
References and Footnotes

Under the assumption of uniform in all bits, masking off the low bits is equivalent. ↩

Using offset instead of bias to prevent confusion. ↩

Likewise any for any choice of $n$ bits being all cleared or set. ↩

If language/compiler supports probability hints then adding the hint is reasonable. ↩

I don’t know how to measure this bias. :( ↩