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 > does

Re: [avr-libc-dev] Interested in 64-bit printf support?

On 04.12.2016 23:53, George Spelvin wrote: The developers of the TICC time interval counter are having a problem printing 64-bit integers: https://github.com/TAPR/TICC/blob/master/TO-DO.txt I went to work figuring out how to do that conversion, and after some false starts, came up with some quit

Re: [avr-libc-dev] Interested in 64-bit printf support?

Thanks for the comments! May of your comments have been obviated by my later work (particularly the assembler version), but I really appreciate them anyway. I should mention that the code you commented on was a proof of concept. It's something that *could be adapated* to avr-libc, so a couple of

Re: [avr-libc-dev] Interested in 64-bit printf support?

> Again, we can safe code size by slightly slowing things down, e.g. > > mod5 (uint8_t x) > { > #if __AVR_ARCH__ > asm ("0: $ subi %0,%1 $ brcc 0b $ subi %0,%n1" : "+d" (x) : "n" (35)); > asm ("0: $ subi %0,%1 $ brcc 0b $ subi %0,%n1" : "+d" (x) : "n" (5)); > return x; > #else >

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

George Spelvin schrieb: A README in test/simulate would definitely help. Based on my quick glance at things: [...] "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

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

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

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

[avr-libc-dev] [bug #49781] Definition incorrect in avr/iotnx5.h

URL: Summary: Definition incorrect in avr/iotnx5.h Project: AVR C Runtime Library Submitted by: None Submitted on: Tue 06 Dec 2016 08:39:44 PM UTC Category: Header S

[avr-libc-dev] I just noticed OPTIMIZE_SPEED

Perhaps the two different reduction-mod-5 schemes should depend on OPTIMIZE_SPEED? Speaking of optimization, there are a significant number of places in libc/string (and libx/pmstring) where adding one instruction could save one cycle per byte. Most of the loops end with subilen_lo,

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

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As Georg-Johann Lay wrote: > 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. Yep. However, Pitchumani added (in r2520) code to runtest.sh that

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

As Joerg Wunsch wrote: > This yields a few new simulation errors: > > Simulate: avr/eeprom-1.c attiny2313 ... *** simulate failed: 70 > Simulate: avr/eeprom-2.c attiny2313 ... *** simulate failed: 46 > Simulate: avr/eeprom-3.c attiny2313 ... *** simulate failed: 64 > > Not sure what's wrong here

Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED

As George Spelvin wrote: > Perhaps the two different reduction-mod-5 schemes should depend on > OPTIMIZE_SPEED? Doesn't really matter much. Since the library is pre-compiled, you cannot map it to the user's -Ox compiler option anyway. As Johann already explained, most AVR users care for saved f

Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED

>> Perhaps the two different reduction-mod-5 schemes should depend on >> OPTIMIZE_SPEED? > Doesn't really matter much. Since the library is pre-compiled, you > cannot map it to the user's -Ox compiler option anyway. Er... AFAICT, that option has nothing to do with -O compiler flags, but is set a

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.debia