Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
As George Spelvin wrote: > Simulate: regression/bug-22828.c atmega128 ... /tmp/cciW6XcS.o: In function > `main': > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:50: undefined > reference to `eeprom_write_block' > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:52: undefined > reference to `eeprom_read_block' That's quite strange, they are supposed to be there (from assembly sources). > Simulate: regression/bug-27242.c atmega128 ... *** simulate failed: 8 > Simulate: regression/bug-27242.c at90s8515 ... *** simulate failed: 8 Saw this yesterday, will have to investigate. > Simulate: stdlib/dtostrf-01.c atmega128 ... In file included from > stdlib/dtostrf-01.c:36:0: > stdlib/dtostrf.h: In function 'run_dtostrf': > stdlib/dtostrf.h:99:8: warning: assignment discards 'const' qualifier from > pointer target type [-Wdiscarded-array-qualifiers] > pv = & pt->pattern; > ^ I already fixed those last night, please do "svn up". -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
> I'd propose you use GCC trunk HEAD and Binutils master; if that and > rerunning bootstrap does not do the trick, you found a bug and I > wonder how the folks are testing avr-libc :-) I'm working on compiling GCC trunk, but it has required a little debugging. The build has failed a couple of times, and $objdir/gcc/fixinc_list is getting created with the contents ";", which causes an error at "make install" time. Clearing that file makes the error go away and I have a working compiler, but no file, which causes some later configure tests to fail. But I can see one in $objdir/gcc/include-fixedlimits.h/limits.h and manually copy it to $prefix/lib/gcc/avr/7.0.0/include-fixed That seems to be working. Then I screwed myself up because I only did "make clean; make" in the avr-libc directory and didn't re-run configure. But after all that, I get lots of tests passing! Quite a few failures, such as: Simulate: regression/bug-22828.c atmega128 ... /tmp/cciW6XcS.o: In function `main': ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:50: undefined reference to `eeprom_write_block' ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:52: undefined reference to `eeprom_read_block' collect2: error: ld returned 1 exit status *** compile failed Simulate: regression/bug-25723.c atmega128 ... OK Simulate: regression/bug-25723.c at90s8515 ... OK Simulate: regression/bug-27235-1.c atmega128 ... OK Simulate: regression/bug-27235-1.c at90s8515 ... OK Simulate: regression/bug-27242.c atmega128 ... *** simulate failed: 8 Simulate: regression/bug-27242.c at90s8515 ... *** simulate failed: 8 Simulate: regression/bug-28135.c atmega128 ... OK Simulate: regression/bug-28135.c at90s8515 ... OK Simulate: regression/bug-31644.c atmega128 ... /tmp/cc1lM4bi.o: In function `build_pwm_table': ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:77: undefined reference to `eeprom_read_word' ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:79: undefined reference to `eeprom_read_word' ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:80: undefined reference to `eeprom_read_word' ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:81: undefined reference to `eeprom_read_word' ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:82: undefined reference to `eeprom_read_word' /tmp/cc1lM4bi.o:~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-31644.c:83: more undefined references to `eeprom_read_word' follow collect2: error: ld returned 1 exit status *** compile failed Simulate: regression/bug-35093.c atmega128 ... OK Simulate: regression/bug-35093.c at90s8515 ... OK but it generally looks good. One annoying error that pops up a lot is Simulate: stdlib/dtostrf-01.c atmega128 ... In file included from stdlib/dtostrf-01.c:36:0: stdlib/dtostrf.h: In function 'run_dtostrf': stdlib/dtostrf.h:99:8: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] pv = & pt->pattern; ^ OK Simulate: stdlib/dtostrf-01.c at90s8515 ... In file included from stdlib/dtostrf-01.c:36:0: stdlib/dtostrf.h: In function 'run_dtostrf': stdlib/dtostrf.h:99:8: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] pv = & pt->pattern; ^ OK Simulate: stdlib/dtostrf-big.c atmega128 ... In file included from stdlib/dtostrf-big.c:37:0: stdlib/dtostrf.h: In function 'run_dtostrf': stdlib/dtostrf.h:99:8: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] pv = & pt->pattern; ^ OK I'll submit a patch for that. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
On Wednesday 07 December 2016 02:39 AM, Georg-Johann Lay wrote: George Spelvin schrieb: Either Debian is running patches atop GNU, or avr-libc test suite has not been adjusted to factor out different gcc versions. The Debian diffs can be found in the right-hand column of https://packages.debian.org/sid/gcc-avr specifically http://http.debian.net/debian/pool/main/g/gcc-avr/gcc-avr_4.9.2+Atmel3.5.3-1.diff.gz That comes with external references, e.g. all the XMEGA stuff and many others like 55-gcc-4.3.0-attiny167.patch etc. I'd propose you use GCC trunk HEAD and Binutils master; if that and rerunning bootstrap does not do the trick, you found a bug and I wonder how the folks are testing avr-libc :-) Presumably, someone adds this option by hand, because if avr-gcc added it the error message would be "ld: cannot find -latmega128". That is indeed what runtest.sh does. Here's the result of "bash -x ./runtest.sh -s". The actual compiler invocation is the tenth last line. [...] + avr-gcc -Wundef -I. -gdwarf-4 -W -Wall -pipe -Os -isystem ../../include -nostdlib -std=gnu99 -mmcu=atmega128 -o aux.elf time/aux.c ../../avr/lib/avr51/libc.a ../../avr/lib/avr51/libm.a ../../avr/lib/avr51/atmega128/libatmega128.a -lgcc avr-gcc: error: ../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory Presumably, it goes like follows: avr-libc detects from the version of avr-gcc that it does not add -latmega128 and hence skips building libatmega128.a, hence no such .a in the avr-libc build tree. Yes. For gcc lesser than 5.1, it do not enable device library by default. If the gcc is < 5.1 and patched to have device library, then users can use --enable-device-lib option to configure avr-libc to build device libraries. Regards, Pitchumani ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
George Spelvin schrieb: Either Debian is running patches atop GNU, or avr-libc test suite has not been adjusted to factor out different gcc versions. The Debian diffs can be found in the right-hand column of https://packages.debian.org/sid/gcc-avr specifically http://http.debian.net/debian/pool/main/g/gcc-avr/gcc-avr_4.9.2+Atmel3.5.3-1.diff.gz That comes with external references, e.g. all the XMEGA stuff and many others like 55-gcc-4.3.0-attiny167.patch etc. I'd propose you use GCC trunk HEAD and Binutils master; if that and rerunning bootstrap does not do the trick, you found a bug and I wonder how the folks are testing avr-libc :-) Presumably, someone adds this option by hand, because if avr-gcc added it the error message would be "ld: cannot find -latmega128". That is indeed what runtest.sh does. Here's the result of "bash -x ./runtest.sh -s". The actual compiler invocation is the tenth last line. [...] + avr-gcc -Wundef -I. -gdwarf-4 -W -Wall -pipe -Os -isystem ../../include -nostdlib -std=gnu99 -mmcu=atmega128 -o aux.elf time/aux.c ../../avr/lib/avr51/libc.a ../../avr/lib/avr51/libm.a ../../avr/lib/avr51/atmega128/libatmega128.a -lgcc avr-gcc: error: ../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory Presumably, it goes like follows: avr-libc detects from the version of avr-gcc that it does not add -latmega128 and hence skips building libatmega128.a, hence no such .a in the avr-libc build tree. Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
> Either Debian is running patches atop GNU, or avr-libc test suite has > not been adjusted to factor out different gcc versions. The Debian diffs can be found in the right-hand column of https://packages.debian.org/sid/gcc-avr specifically http://http.debian.net/debian/pool/main/g/gcc-avr/gcc-avr_4.9.2+Atmel3.5.3-1.diff.gz They do disable the documentation, to prevent conflicts with other GCC versions, and there are a couple of small patches that look like bugfixes (one is documented as allowing building with GCC 6), but I don't see much. The ./configure arguments are CONFARGS = -v \ --enable-languages=c,c++ \ --prefix=/usr/lib \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --bindir=/usr/bin \ --libexecdir=/usr/lib \ --libdir=/usr/lib \ --enable-shared \ --with-system-zlib \ --enable-long-long \ --enable-nls \ --without-included-gettext \ --disable-libssp \ --build=$(DEB_BUILD_GNU_TYPE) \ --host=$(DEB_HOST_GNU_TYPE) \ --target=$(TARGET) \ $(shell dpkg-buildflags --export=configure | sed -e 's/-Werror=format-security//g') > Presumably, someone adds this option by hand, because if avr-gcc > added it the error message would be "ld: cannot find -latmega128". That is indeed what runtest.sh does. Here's the result of "bash -x ./runtest.sh -s". The actual compiler invocation is the tenth last line. + set -e + myname=./runtest.sh + : avr-gcc + : avr-nm + : avr-objcopy + : simulavr + : ../.. + : atmega128 at90s8515 + : atmega128 at90s2313 at90s4414 at90s8515 atmega8 atmega16 + HOST_PASS= + HOST_ONLY= + MAKE_ONLY= + FLAG_STOP= + FLAG_KEEPCORE= + getopts a:icg:ktTsh opt + case $opt in + FLAG_STOP=1 + getopts a:icg:ktTsh opt + shift 1 + test_list='time/*.c regression/*.c stdlib/*.c string/*.c pmstring/*.c printf/*.c scanf/*.c fplib/*.c math/*.c other/*.c avr/*.[cS]' + CPPFLAGS='-Wundef -I.' + CFLAGS='-gdwarf-4 -W -Wall -pipe -Os' + CORE=core_avr_dump.core + HOST_CC=gcc + HOST_CFLAGS='-W -Wall -std=gnu99 -pipe -O2 -I.' + n_files=0 + n_emake=0 + n_ehost=0 + n_esimul=0 + for test_file in $test_list + case `basename $test_file` in ++ basename time/aux.c + n_files=1 ++ basename time/aux.c .c + rootname=aux + '[' ']' + '[' -z ']' + case $rootname in + prlist=PR_STD + case `dirname $test_file` in ++ dirname time/aux.c + mcu_list='atmega128 at90s8515' + elf_file=aux.elf + for prvers in $prlist + for mcu in $mcu_list + echo -n 'Simulate: time/aux.c ' Simulate: time/aux.c + case $prvers in + echo -n 'atmega128 ... ' atmega128 ... + Compile time/aux.c atmega128 aux.elf PR_STD + local crt= + local libs= + local flags= + '[' -z ../.. ']' ++ avr-gcc -mmcu=atmega128 -print-multi-directory + local multilibdir=avr51 + [[ avr51 != \a\v\r* ]] + crt=crtatmega128.o + flags='-isystem ../../include -nostdlib' ++ find ../../avr/lib -name crtatmega128.o -print ++ head -1 + crt= + libs='../../avr/lib/avr51/libc.a ../../avr/lib/avr51/libm.a ../../avr/lib/avr51/atmega128/libatmega128.a -lgcc' + case $4 in + case `basename $1` in ++ basename time/aux.c + flags='-isystem ../../include -nostdlib -std=gnu99' + avr-gcc -Wundef -I. -gdwarf-4 -W -Wall -pipe -Os -isystem ../../include -nostdlib -std=gnu99 -mmcu=atmega128 -o aux.elf time/aux.c ../../avr/lib/avr51/libc.a ../../avr/lib/avr51/libm.a ../../avr/lib/avr51/atmega128/libatmega128.a -lgcc avr-gcc: error: ../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory + Err_echo 'compile failed' + echo '*** compile failed' *** compile failed + '[' 1 ']' + Errx Stop + echo './runtest.sh: Stop' ./runtest.sh: Stop + exit 1 ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
George Spelvin schrieb: Thanks for the help. It's not on the critical path yet, but I would like to get some self-tests working. This looks strange. With avr-libc from trunk and a reasonable up to date avr-gcc (5.2+) the crt should be located in $prefix/avr/lib/avr51/crtatmega128.o Perhaps the fact (I mentioned in in passing in a previous message to the list) that I'm using 4.9.2 (because that's what Debian has packaged) has had an effect? avr-gcc 4.9 shouldn't try to link against libatmega128.a at all, and this is how my 4.9.2-pre1 (home-brew canadian cross) behaves. avr-gcc 4.9 defines a spec function to add -lm128, but that spec function is dead :-) http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/avr/avr.h?view=markup#l495 The question is where the libatmega128.a is coming fromcomes from... Either Debian is running patches atop GNU, or avr-libc test suite has not been adjusted to factor out different gcc versions. Presumably, someone adds this option by hand, because if avr-gcc added it the error message would be "ld: cannot find -latmega128". Another thing is that I haven't installed *anything* yet; there is no $prefix/avr directory. I was assuming that the tests would run against the built tree *before* installation. (If I can't run "make check" before "make install", that smells like a bug that needs fixing.) Well, I never ran avr-libc tests, I am just doing the avr-gcc thing... Maybe for the time being it's the simplest approach to build your own GCC and Binutils all with same $prefix in $HOME, dito for libc. avr-libc can build against non-installed avr-gcc by CC="$build/gcc/xgcc -B$build/gcc" where $build refers to the gcc build dir, which should never be in $source b.t.w. Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
Thanks for the help. It's not on the critical path yet, but I would like to get some self-tests working. > This looks strange. With avr-libc from trunk and a reasonable > up to date avr-gcc (5.2+) the crt should be located in > > $prefix/avr/lib/avr51/crtatmega128.o Perhaps the fact (I mentioned in in passing in a previous message to the list) that I'm using 4.9.2 (because that's what Debian has packaged) has had an effect? Another thing is that I haven't installed *anything* yet; there is no $prefix/avr directory. I was assuming that the tests would run against the built tree *before* installation. (If I can't run "make check" before "make install", that smells like a bug that needs fixing.) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
(This is a much lower priority than the printf work; I just noticed it
in passing.)
>> For example, couldn't rand_r save a jump by declaring it
>>
>> int rand_r(unsigned long *ctx) __attribute__((alias("do_rand")));
> I don't think that would work, as do_rand() is declared "static", so it
> doesn't yield a linker-visible symbol.
I don't think that's a problem. The assembly generated is basically:
.type do_rand, @function
do_rand:
.size do_rand, .-do_rand
.global rand_r
.setrand_r,do_rand
The assembler is generating two symbols that happen to have the same
value, and one is exported while the other is not.
The important thing is that the linker knows that the reference in rand()
is to the non-exported symbol, so even if someone overrides rand_r,
rand() will still call do_rand().
(Speaking of the linker, I wish it could relax conditional branches.
It has all the information it needs in the R_AVR_7_PCREL relocation
table entry. Just flip bit 10 of the opcode to negate the sense of the
branch and append an RJMP or JMP to the destination.)
>> But the real problem is the choice of algorithm.
>> 32x32-bit multiplies are very ugly and bloated on an 8-bit AVR.
> It's simply been ported from a known-to-be-good algorithm.
Actually, that's something of a known-to-be-bad algorithm, but yeah,
it's okay as LCRNGs go. You might note that, per
https://en.wikipedia.org/wiki/Park%E2%80%93Miller_RNG#Parameters_in_common_use
http://www.firstpr.com.au/dsp/rand31/p105-crawford.pdf
Park and Miller suggested changing the multiplier to 48271.
These are available in the C++ library as:
http://www.cplusplus.com/reference/random/minstd_rand0/
http://www.cplusplus.com/reference/random/minstd_rand/
>> I could replace it with an 8-bit lag-3 multiply-with-carry generator
>> with the same period (2^31 - epsilon) and state size (32 bits) which
>> would be a lot faster.
> If it produces the same good degree of (pseudo-)randomness, this is
> certainly another Good Thing.
Obviously, any generator with a 32-bit state is limited in the period
it can generate, but there are plenty of decent ones. I was just
trying to keep the math simple.
>> But do people depend on that exact sequence of values being generated?
> As another option, we could include the existing algorithm in the
> library (in a separate module), but rename it, say, to
> "__park_miller_rand" etc. Then, we offer (and document) a switch that
> allows an application to pick the Park & Miller algorithm by #defining
> __PARK_MILLER_RAND before including . Thinking more about
> it, I'd prefer it that way.
Okay, that sounds simple enough.
>> If they are, there's still room for improvement. You could at least
>> replace the hideous mess of 32-bit divides with a two 16x16->32-bit
>> multiplies (since the multiplier 16807 fits into 16 bits) and some
>> simpler modular reduction code.
> That could still be done nevertheless. In that case, I suggest to
> implement testcase code though, so we can make sure the desired
> sequence of pseudo-random numbers is still retained for the Park &
> Miller case. (There is a testbench around in avr-libc, even though
> I guess only few developers know about it.)
A README in test/simulate would definitely help. Based on my
quick glance at things:
"The tests are all compiled and simulated by runtest.sh. Each *.c
file is compiled and simulated on several representative models of AVR.
The simulator halts when exit() is called, and the 16-bit return value
is extracted from the register file in the core dump.
"If the exit code is non-zero, the test has failed. Usually the exit code
is the line number where the failing test was called.
"You may add new files to the existing test directories freely, but adding
a new directory requires updating the list in runtest.sh."
However, I can't get it to work. For me, it generates a near-infinite
stream of errors:
Simulate: time/aux.c atmega128 ... avr-gcc: error:
../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory
*** compile failed
Simulate: time/declination.c atmega128 ... avr-gcc: error:
../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory
*** compile failed
Simulate: time/equation.c atmega128 ... avr-gcc: error:
../../avr/lib/avr51/atmega128/libatmega128.a: No such file or directory
*** compile failed
...etc.
[921]$ ls -l ../../avr/lib/avr51/atmega128/
total 108
-rw-rw-r-- 1 colin software 30385 Dec 5 20:12 Makefile
-rw-rw-r-- 1 colin software 3434 Dec 5 20:00 Makefile.am
-rw-rw-r-- 1 colin software 33194 Dec 5 20:01 Makefile.in
-rw-rw-r-- 2 colin software 8884 Dec 5 20:14 crtm128.o
-rw-rw-r-- 2 colin software 8884 Dec 5 20:14 gcrt1.o
-rw-rw-r-- 1 colin software 9672 Dec 5 20:14 libcrt.a
I can't find a "libatmega128.a" anywhere. :-(
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?
As George Spelvin wrote:
> As I'm looking through the rest of the code, I notice a few silly things.
>
> For example, couldn't rand_r save a jump by declaring it
>
> int rand_r(unsigned long *ctx) __attribute__((alias("do_rand")));
I don't think that would work, as do_rand() is declared "static", so it
doesn't yield a linker-visible symbol.
> But the real problem is the choice of algorithm.
> 32x32-bit multiplies are very ugly and bloated on an 8-bit AVR.
It's simply been ported from a known-to-be-good algorithm.
> I could replace it with an 8-bit lag-3 multiply-with-carry generator
> with the same period (2^31 - epsilon) and state size (32 bits) which
> would be a lot faster.
If it produces the same good degree of (pseudo-)randomness, this is
certainly another Good Thing.
> But do people depend on that exact sequence of values being generated?
We could always offer a compile-time #ifdef, so people who depend on a
particular order can compile their own. We did so using the
USE_WEAK_SEEDING #ifdef, but I think that one can finally go away.
As another option, we could include the existing algorithm in the
library (in a separate module), but rename it, say, to
"__park_miller_rand" etc. Then, we offer (and document) a switch that
allows an application to pick the Park & Miller algorithm by #defining
__PARK_MILLER_RAND before including . Thinking more about
it, I'd prefer it that way.
That is only needed for rand_r() / rand() / srand(). random() and
srandom() are meant to be compatible with the standard, so any version
that complies is fine.
> If they are, there's still room for improvement. You could at least
> replace the hideous mess of 32-bit divides with a two 16x16->32-bit
> multiplies (since the multiplier 16807 fits into 16 bits) and some
> simpler modular reduction code.
That could still be done nevertheless. In that case, I suggest to
implement testcase code though, so we can make sure the desired
sequence of pseudo-random numbers is still retained for the Park &
Miller case. (There is a testbench around in avr-libc, even though
I guess only few developers know about it.)
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
