avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] rand(3) in avr-libc


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] rand(3) in avr-libc
Date: Wed, 16 Oct 2002 17:59:15 +0200
User-agent: Mutt/1.2.5i

This discusion happened a while ago.  I just noticed that the
uncommitted changes were still lingering around here.

As E. Weddington wrote:

> > It fixes the remaining problems with using long constants in the
> > source code (that silently got truncated to 16 bits before), it uses
> > the newer algorithm by default to produce better randomness, and IMHO
> > we also need to pass an unsigned long * (as opposed to an unsigned *)
> > in rand_r() since we'd otherwise truncate the temporary storage which
> > defeats the entire algorithm.  Even the old algorigthm (that's used if
> > USE_WEAK_SEEDING is defined) required a `long' for temporary storage.

All fixed now.

> > As for supplying an additional set of functions returning long instead
> > of the standards-mandated int, there are two options i would see:
> > 
> > 1 We copy over the existing rand.c into a random.c, and just replace
> >   the result type (and the type passed to srandom()) from `int' to
> >   `long', including of course using RANDOM_MAX == 0x7fffffff for
> >   limiting the result.  The advantage is that the resulting file will
> >   still be relatively small (~ 300 bytes of ROM).

I did just that.

> > 2 We port over the full-fledged random.c from BSD.  This would offer a
> >   more sophisticated pseudo-random number generator that while using
> >   the same algorithm that's now in the proposed rand.c file, can use a
> >   lot more of temporary storage for state information (up to 256
> >   bytes) to increase the period.  To quote the BSD man page:
> > 
> >      With 256 bytes of state information, the period of the random
> >      number generator is greater than 2**69 which should be sufficient
> >      for most purposes.

That remains as an exercise for the user should anyone really pop up,
and actually need it.  I once did it, it's not all that much work to
port the BSD file over to the AVR (just replace a few "int" by "long"
etc.), but right now and given its relatively high costs, i don't see
there's much demand for it.

Should we ever want to import that into avr-libc, however we need to
decide about the naming, since random()/srandom() are now taken.  If
someone's going to do this inside an application, there's not much
collision with the version in avr-libc: the function prototypes for
random() and srandom() are identical between our new 32-bit version
and the BSD version, and supplying a user implementation file will
always take precedence over the library.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]