On Tuesday 16 March 2010 02:33, Joerg Wunsch wrote:
What's the general opinion about moving avr-libc to SVN before
releasing 1.7.0? Are there any objections among the active
developers?
If not, I'd like to prepare a SVN migration SVN dump image, and submit
it to the savannah admins for
Possibly, it is needed to change eeprom_read_byte() definition
to int return value. This can reduce summary size. Opinions?
This does not make sense to me. Eeprom_read_byte() is supposed to read, and
return, a single byte. So why should it return a 16-bit int? In my mind
this would just
On Sunday 22 November 2009 12:32, Andrew Hutchinson wrote:
Could someone add float variations of common functions to avr libc -
this would match gcc expectations for available libc functions.
Good observation.
If no objections, I will do this.
Regards,
Dmitry.
On Friday 26 June 2009 06:29, Joerg Wunsch wrote:
../../../libc/misc/eerd_block.S:80: Error: register number above 15
required gmake[1]: *** [eerd_block_atxmega64a3.o] Error 1
The respective code after preprocessing is:
; Correct EEPROM address to read from data space.
subi r22,
On Friday 03 April 2009 15:50, Dmitry K. wrote:
Fine. I shall (1) to update the patch with current CVS
head and (2) to prepare an all-in-one test with simple
indication.
Done. The patch is updated: the changes are only with
new devices addition since Jan 2009. I have not prepare
any special
On Friday 03 April 2009 01:22, Weddington, Eric wrote:
P.S. For commiting of patch #6718 there are no only
test with real Xmega. Eric, have you any possibility
to do this?
If you are asking me if I can test on real hardware, then yes I can. Please
tell me what to test.
Fine. I shall
On Thursday 02 April 2009 00:46, Weddington, Eric wrote:
I don't see a real need to have the separate *.ctype section, do you?. We
should just have .text.avr-libc and .text.avr-libc.fplib.
Seems, it is not needed.
Likely, this is from time, when a short branches
was used between ctype modules.
On Wednesday 01 April 2009 03:36, Weddington, Eric wrote:
[...]
So, I still stick with the patch, unless someone can show me that it is an
easier patch to do it the other way.
Note, the patching of Avr-libc is not sufficient.
The 'libgcc.a' contains 2 names: '.text.libgcc' and '.text'.
The
On Thursday 05 March 2009 17:50, Joerg Wunsch wrote:
2. isinf()
See the GCC bug #35509. Avr-libc's isinf() work fine.
Hovever, since 4.3 branch the GCC replaces it with
themselves inline code, which return the +1 value for
negative infinity. This is mismatch to traditionaly
isinf()
On Thursday 05 March 2009 06:19, Joerg Wunsch wrote:
As Weddington, Eric wrote:
Some concerns:
Simulate: regression/bug-22828.c atmega128 ... *** simulate failed: 24
Simulate: regression/bug-22828.c at90s8515 ... *** simulate failed: 24
Strange enough, for me this only fails for the
Hi.
1. signbit()
This is my omission. With GCC 4.0 and early the signbit()
function work fine. Since 4.1 branch the GCC replaces it
with themselves inline code with internal compile error in
result (GCC bug #30243). So a long time this function was
untested. Now this bug is corrected and we
Are you able to run this script with the latest simulavr?
As soon as
I try to call either floating or fixed point routines, I am getting
errors:
rm: cannot remove `core_avr_dump.core': No such file or directory
Hi,
I have try the latest simulavr: the same error in result.
1.
On Sunday 22 February 2009 02:58, Weddington, Eric wrote:
Don't forget to put the patch in the simulavr Patch Tracker.
Thanks,
Eric
Done. Also I have submit 2 bugs reports.
Possible, the reason of ATmega8 problem is a cut/paste
garbage in 'src/defn/mega8.h': PORTA record.
Dmitry.
I would like to calculate this data for the fixed point math library
to make comparison easy for user, and to also help me know how to
optimize it better. Does anyone know how to generate this file?
Hi,
I will send the script for this in the nearest
two days (sorry, I am very busy at this
Has the revised FP library made it into the latest WinAvr release? It
wasn't obvious from the libc faq.
AFAIK, yes.
The latest WinAVR release uses avr-libc 1.6.4.
All 1.6.X Avr-libc releases contain the revised FP library.
Regards,
Dmitry.
On Wednesday 24 December 2008 02:30, Anatoly Sokolov wrote:
You consider, it is necessary to add architectures for devices with up to
255 max RAM address? Yes, in this case, for this devices it will be
possible to have more effective functions in avr-libc, but only few such
devices, and C
On Wednesday 24 December 2008 13:59, Weddington, Eric wrote:
I prefer variant avr-libc 2.0 / GCC 4.4. But I assume that
Dmitry would object, he prefers not to restrict the GCC
version for using with avr-libc.
Yes, thanks :-)
In this case, I agree with
the option to add the lib per
On Sunday 21 December 2008 18:03, Anatoly Sokolov wrote:
[...]
It is small advantage, to compile avr-libc with '-mtiny-stack'
optimisation for devices with 8-bit stack pointer. The advantage of this
optimisation appears only for the big functions, at which the size of the
frame buffer is
On Sunday 21 December 2008 13:52, you wrote:
Hi Dmitry,
I now get this message from CVS when I update or when I even do a clean
checkout after your commit:
? update.log
cvs update: move away tests/simulate/string/ffs-1.c; it is in the way
C tests/simulate/string/ffs-1.c
What does this
I against, to build full the avr-libc library for device,
this dramatically
increase compile time and the code size of avr-libc. Instead,
I suggest to
build libc for architecture and add small library with device specific
functions for eeprom, wdt, boot e.t.c. modules.
Hmm... Yes,
On Tuesday 20 May 2008 18:15, Tobias Frost wrote:
Dimitry, could you give just a rough estimation, how long it took you to
implement the libm. (If I rememember correctly, the current solution is
from you). A rough number is fine. Thanks!
Approximately 2 monthes. 3 weeks from this time was
On Monday 19 May 2008 22:16, Tobias Frost wrote:
[...]
The first step will to get in contact with Dimitry. Jörg, can you please
trigger him or send me his contact data? I'm not sure if I found the
right Dimitry on the list. (If his last name is Xmelkov, then my guess
was right and he'll get a
On Thursday 08 May 2008 08:47, Weddington, Eric wrote:
I have just built it with Anatoly's patch to fix WinAVR bug #1956569:
http://sourceforge.net/tracker/index.php?func=detailaid=1956569group_
id=68108atid=520074
I have not tested it yet. If you want to fix the problem with _SFR
macros,
Hi.
We have 3 variants of SFR usage:
1. This is default for C/C++. Port names are like common variables.
2. Port names are defined as ordinary numbers, suitable to use with
IN/OUT instructions.
3. Port names are defined as ordinary numbers (addresses), suitable
to use with LDS/STS
On Sunday 04 May 2008 08:33, Dmitry K. wrote:
We have 3 variants of SFR usage:
1. This is default for C/C++. Port names are like common variables.
2. Port names are defined as ordinary numbers, suitable to use with
IN/OUT instructions.
3. Port names are defined as ordinary numbers
On Friday 25 April 2008 22:48, urriz wrote:
How about adding of preliminary compare with EEPROM contents in
functions
group__avr__eeprom.html#g6081dbb6daa2e5ddbd7ccc56a1620574eeprom_write_byt
e,
group__avr__eeprom.html#g05ef5a5774b7dbefa2500c83c50c931eeeprom_write_blo
ck ?
Hm...
Is avr-gcc for avr6 ready to use?
I have try avr-gcc 4.4-20080404 (4.3.0 does not support avr6)
with binutils 2.18. In result the small program without any
EEPROM usage and without any inline functions gives incorrect
code:
/* avr-gcc 4.4-20080404 + binutils 2.18 produce incorrect code:
On Thursday 10 April 2008 01:15, Stu Bell wrote:
Is avr-gcc for avr6 ready to use? Yes, with warnings. Since gcc
insists on the size of a function pointer to be 2 bytes, anything using
function pointers must be used with caution. If the function resides in
the lower half of flash, the 2
On Thursday 10 April 2008 08:19, Dmitry K. wrote:
Yes, I have obtain the same result of compilation.
Incorrect is result of linking (avr-objdump -d):
ldi r24, 0
ldi r25, 0
in case of foo4() only.
The trampoline stub for foo4() was created correctly.
Now I have look again
On Thursday 10 April 2008 08:55, Weddington, Eric wrote:
As the AVR Binutils port is not maintaned, IMHO,
Dmitry, I have write-after-approval privs on binutils. You can send me a
patch for binutils.
Eric
Good point.
Thanks,
Dmitry.
___
On Wednesday 02 April 2008 05:53, Anatoly Sokolov wrote:
avr-gcc starting with 4.3 save/restore RAMPZ register in interrupt
handler routines if Z register is used in them. Now pgm_read_*_far
functions is reentrant.
What about to do save/restore RAMPZ in other
active GCC branches: 4.1, 4.2 ?
Hi.
The common X-less AVR has a set of 16-bit registers
(those have 16-bit atomic access). This registers are
listed implicitly, for example, with ATmega48p they
are: TCNT1, OCR1A/B, ICR1, TCNT2, ...
But the 'ATxmega A manual' says (page 9):
... each 16-bit register has an 8-bit register for
On Friday 28 March 2008 13:48, Weddington, Eric wrote:
[...]
- how to use (void *)0 ?
Could you explain? How would it be any different than it is now?
I have check this.
The Avr-gcc 4.2.3 and 4.3.0 have not any problems.
The Avr-gcc 4.1.2 and early are too agressive in manipulations
with 0
On Thursday 20 March 2008 09:23, Weddington, Eric wrote:
I'm doing a new release of WinAVR soon. A release candidate
some time this week, with a planned release on April 2. This
release is mainly to support the XMEGA devices, fix various
bugs (avr-libc, WinAVR), and support other new
Hi.
Is the __AVR_3_BYTE_PC__ macro the best for this purpose?
I have find 2 another methods in Avr-libc:
a) if (__AVR_ARCH__ == 6)
b) if defined(EIND)
Thanks,
Dmitry.
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
On Thursday 20 March 2008 08:28, Eric Weddington wrote:
Update of bug #21410 (project avr-libc):
Open/Closed:Open = Closed
I have not close consciously:
And a general question: what is the best method to
do in this case: a bug is fixed only in CVS and
On Saturday 15 March 2008 03:15, Weddington, Eric wrote:
Hi All,
I finally got around to trying the avr-libc test suite on MSYS. Attached
are the test results.
Eric Weddington
Hi Eric, hi All.
I have run with Avr-gcc versions:
3.3.6, 3.4.6, 4.0.4, 4.1.2, 4.2.3, 4.3.0.
All of them are
On Saturday 15 March 2008 12:53, Weddington, Eric wrote:
Simulate: avr/eeprom-1.c at90s2313 ... *** simulate failed: 22
Simulate: avr/eeprom-1.c at90s4414 ... *** simulate failed: 22
Simulate: avr/eeprom-1.c at90s8515 ... *** simulate failed: 22
Simulate: avr/eeprom-1.c atmega8 ... ***
On Sunday 02 March 2008 04:25, Weddington, Eric wrote:
I'm ok to commit to HEAD if these conditions are met:
- builds for all current AVR devices that have EEPROM
- fixes avr-libc bug #21410
- fixes gcc bug #31644
Hi Eric, hi all.
It is commited into CVS HEAD.
. Avr-libc bug #21410 is fixed.
Hi.
Exclude old chips, the EEPROM module permits 3 types
of writing: clean, burn, clean_and_burn. This is
set by 2 bits in control register. Datasheet says,
that this bits are undefined after reset. The text
below says, that this bits are zeros after reset (?).
The ATtiny program example
Hi all.
Rick, thank you for fine explanation of 'project 1'!
Now I have include this project into my local Avr-libc copy,
build and test. Now I am busy to add DOXYGEN.
The list of changes is:
New variant of EEPROM functions: inline byte procedures and library
multibyte
Hi.
After testing with all GCC versions (3.3.6 - 4.3.X)
I intend to update vfscanf() in 1_6 branch (from HEAD).
Any objections?
Thanks,
Dmitry.
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
On Monday 18 February 2008 04:13, Weddington, Eric wrote:
Can you make sure the avr-libc bug #19079 gets fixed?:
https://savannah.nongnu.org/bugs/?19079
Frederic Nadeau was supposed to commit his patch, but hasn't done so yet.
Yes, it is fixed.
I have reproduce the bug example as:
/* bug
On Monday 18 February 2008 05:20, Joerg Wunsch wrote:
[...]
. Restriction of conversion quantity has arisen because of reduction
of the size of the counter up to one byte.
My only concern about that is whether it's still C99 compliant that
way. Curious, did you verify whether the standard
Hi.
In the near future I am going to update vfscanf() function
- a core of all scanf family (first only the HEAD branch).
Function vfscanf() is rewriten. The float point version is optimized
considerably: the expense of a
Hi.
The question is about the NUL character ('\0') with
string conversions ('%s', '%[^'). Now the Avr-libc's
scanf() considers the NUL as a normal character: it is
placed into output buffer and a conversion continues.
The GNU's libc does the same.
Is it a good behavior? What about to stop
On Wednesday 16 January 2008 17:57, Dig Kleppe wrote:
Hi all
I noticed a big codesize difference when using the log function:
without log -- with log
winAVR20070525 2958 4152
winAVR20071221 2940 5744
using math lib. Also in case of without log fp is used
opt = s
Hi,
This is take place for avr-libc 1.4.7, 1.5.1 and 1.6.1 with
avr-gcc 4.1.2 and earlier. The reason: the definition (i.e.
workaround for old compilers) of __AVR_HAVE_LPMX__ was removed from
'avr/io.h' file since 1.43 version.
The same is with __AVR_HAVE_MOVW__ (used in eprom.h).
IMHO, this was
On Monday 24 December 2007 17:31, Joerg Wunsch wrote:
As Dmitry K. wrote:
and includes the section about incompatibilities between
1.6.1 and 1.5.1: behaviour in conversion overflow, specify
nonzero value with signbit() ...
Sorry, it was not clear to me that this list does not cover
On Saturday 22 December 2007 17:25, Joerg Wunsch wrote:
[...]
1.6 is the new stable branch which has just been forked
off, and HEAD is eventually going to become 1.8 some
day.
The question is about HEAD and 1.6. Today there is no
projects to force its different. The wish is to avoid
a double
On Saturday 22 December 2007 17:50, Joerg Wunsch wrote:
I've been too tired last night, so I did it now. The web pages are
now updated, the public documentation thus points to the 1.6.1 docs.
I also converted the Major changes part of NEWS into
changes-1.6.html for a quick overview.
The
On Thursday 20 December 2007 00:53, Weddington, Eric wrote:
Because that bug is completely unimportant and purely cosmetical.
Real embedded applications don't exit() anyway. Mind you, we (at
least you and me) have been shipping compiler/library combinations
where returning from main()
Hi.
Recently to the chapter Changes since avr-libc-1.5.1
a 4 notes are added, about of old float point bugs
fixed. It misleads a reader, since all this corrections
were maked before 1.5.1 More, this was a main reason
to start the new Avr-libc branch.
What about to move (or delete) this notes?
On Thursday 20 December 2007 11:53, Weddington, Eric wrote:
[...]
But I definitely don't want to forget about this issue. I think that
this is an important enough change. Dmitry, would you be willing to add
a Task to the Task Tracker on avr-libc for this?
This bug (#21841) is open at present
On Wednesday 19 December 2007 08:33, Joerg Wunsch wrote:
Update of bug #21841 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Corrections
Hi.
I am bewildered. What is the difference between 'argument'
and 'parameter' in Doxygen usage?
Doxygen obtains two commands. First is the '\a' command
to refer to member arguments. It highlights a name with
italic font. The second is the '\p' command to refer to
member function parameters. It
Hi.
Now the abort() is declared as inline function (which
makes infinite loop). Such declaration does not give
a possibility to the user to link the program with the
own version of abort() function.
What about to declare the abort() as a normal extern
function? The library realization will as:
Hi.
Now in case of unforeseen interrupt the program is
jumped to zero address. As a rule, such behaviour
is bad, as it leads to restart program without
restarting a MCU's hardware.
What about to perform 'reti' in case if the user
does not define own __vector_default ?
Dmitry.
Hi.
Now the file doxygen.config.in (CVS head) is changed.
The Doxygen's CPP will evaluate macroses (which are listen)
and substitute an empty string instead __ATTR_CONST__
(see ChangeLog).
I check this with Doxygen 1.4.7: OK, the __ATTR_CONST__
label is removed.
Is there any objections to this?
On Wednesday 12 December 2007 14:39, Weddington, Eric wrote:
[...]
Dmitry, do you still have stuff you want to commit?
Yes, I have made all commits which wished to make
before the stable release.
Dmitry.
___
AVR-libc-dev mailing list
On Thursday 29 November 2007 02:16, Anatoly Sokolov wrote:
[...]
I suggest to set up the minimal required version of GCC as 4.2.
It will allow:
1. To remove check of new devices which are already supported in the GCC
4.2 from 'configure.ac' file.
2. To remove avr25 divices from
On Tuesday 27 November 2007 10:59, Weddington, Eric wrote:
[...]
Dmitry, are you confident enough in your new math library work to
release it to the world?
I planned to change behaviour at overflow of __fixsfsi() function.
Though the standard supposes any decision, it is better to make it
On Monday 29 October 2007 09:33, Joerg Wunsch wrote:
I plan to release the current state of HEAD as version 1.5.1 ASAP.
[...]
Perfectly!
When you are going to make it?
I would like to see all other changes brought recently,
but there is no time it to borrow over the weekend.
Still it would be
On Tuesday 04 September 2007 18:20, Michael Schulze wrote:
Dmitry K. wrote:
On Monday 03 September 2007 19:59, Michael Schulze wrote:
Hi,
Very interesting idea. Though there is a discrepancy: function
redir_func() keeps the SREG already after it is scratched (sbiw,
eor).
I can't
On Friday 31 August 2007 20:06, Michael Schulze wrote:
Hi all,
I propose a new interrupt vector redirection scheme which can be
integrated seamless into the avr-libc in my opinion without having side
effects.
[...]
Very interesting idea.
Though there is a discrepancy: function redir_func()
In addition to second:
An alternative change (more suited to bigger AVRs) could be made if it
is safe to assume that the stack is given a whole number of pages, plus
some extra for interrupt stack space.
Very interesting idea!
Unfortunately, this trick cannot be used without updating the
On Saturday 14 July 2007 08:55, Joerg Wunsch wrote:
[...]
The question now is, what to chose for the name of TCCR0B when it's
defined as the union/bitfield sketched out above? If we call that
TCCR0B, the old way of handling TCCR0B like
TCCR0B = _BV(CS00) | _BV(CS02);
would be
In ChangeLog, also move Dmitry's section into chronological order.
Thanks, I was careless.
alloca() has always (well, at least for the time I can remember)
been a part of GCC, so you don't need to worry about older
compilers.
OK, I will add into 1.4 branch.
Dmitry.
On Sunday 25 March 2007 14:02, Colin O Flynn wrote:
Follow-up Comment #5, bug #19281 (project avr-libc):
Attached patch should fix it, just deletes the two lines...
I haven't tested it as my CVS checkout doesn't build properly, it errors
out on the atoi.S file.
Can you to specify an error?
On Sunday 25 March 2007 11:59, Eric Weddington wrote:
Update of bug #19280 (project avr-libc):
Priority: 5 - Normal = 9 - Immediate
___
Follow-up Comment #2:
Is it too difficult to fix this in the 1.4
On Wednesday 21 March 2007 01:27, Colin O Flynn wrote:
Follow-up Comment #1, bug #19135 (project avr-libc):
Appears to be fixed in CVS?
Yes, it was fixed at the end of Febr. 2007 in MAIN and
1.4 branches. Also the code was optimized.
Dmitry.
___
Hi.
Very attractive method consists in that to configure
and build a library file individually on each project
(exactly for each AVR chip in project). Alongside with
an opportunity to operate optimization it will give
still a number of new opportunities:
- byte-wide address operations for chips
On Monday 05 March 2007 07:29, Joerg Wunsch wrote:
As Dmitry K. wrote:
Is it by browser wrong?
I do not see a choice to commit a new bug.
Supposedly, when you move the focus over the Bugs headlin,
a drop-down menu appears that has a Submit menu entry.
This even works with JavaScript
On Wednesday 21 February 2007 13:30, [EMAIL PROTECTED] wrote:
I used gcvs on Linux to get the files - OK
Then I used autoconf Makefile.am in the hope that this produces a
Makefile - This did not
The README tells about to run ./configure
[...]
First, `./bootstrap' is needed?
Regards.
On Monday 19 February 2007 21:32, Joerg Wunsch wrote:
As Dmitry Xmelkov wrote:
Log message:
Fix error in __AVR_HAVE_LPMX__ definition. A bit of space improvements.
Sounds like this should also be merged to the 1.4 branch, doesn't it?
I am not shure. There would be a mismatch in case of
On Thursday 15 February 2007 16:29, Dmitry K. wrote:
On Thursday 15 February 2007 16:05, Joerg Wunsch wrote:
As Dmitry K. wrote:
One point is required: to increase the size of the buffer
for float point numbers in vfprintf.c (FLOAT version), as
the range of numbers became wider: up
Hi.
One point is required: to increase the size of the buffer
for float point numbers in vfprintf.c (FLOAT version), as
the range of numbers became wider: up to ~1e-45. I did not
hasten to make this change because I debug now the improved
variant of vfprintf() function which integrates all olds
Hi.
I believe, from the point of view of the Standard, current
realization of main() function is callable. Really, the
programmer can use the return operator to leave main()
function. For example, it is possible and really works:
int main() {
if (foo()) return 1;
for (;;) ;
}
Hi.
Now a new directory - tests - is added.
It contains:
~~~
. simulate/
.progmem.h
.runtest.sh
.fplib/
. add-01.c
. add-02.c
. ...
.math/
. acos-01.c
. ...
.stdlib/
. atoi-1.c
. ...
.string/
. ffs-1.c
. ...
.
atoi and atol both include a check for the lower case v instead of the
vertical tab during initial white space scanning. As a result the vertical
tab character is not scanned properly and the letter v is ignored as white
space.
Besides there is an opportunity a little to reduce a code.
There
Hi.
What is the necessity of occurrence __AVR_HAVE_MUL__
in common/macros.inc? Is it not the same as
__AVR_ENHANCED__?
Thanks,
Dmitry.
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
On Wednesday 17 January 2007 07:30, Allan Schrum wrote:
Thanks. But is it possible to now support Automake 2.61? Our Gentoo
system has now moved to 2.61!
Can be resolve all versions = 2.59? Until there will be a mistake.
Dmitry.
___
AVR-libc-dev
On Tuesday 16 January 2007 00:23, Joerg Wunsch wrote:
[...]
Added files:
devtools : table.tar.bz2
[...]
Curious, what's that file for?
Binary files don't behave very well in CVS.
Yes, you are right. I did not wish to litter a CVS tree
a lot of files. Perhaps, it would be better
On Monday 15 January 2007 08:41, Joerg Wunsch wrote:
As Dmitry Xmelkov wrote:
Modified files:
. : bootstrap
Log message:
Version 2.60 for autoconf is added
This one is probably a candidate for being merged into the 1.4 branch.
Perhaps the doc change to
Hi.
In 'compat/depricated.h' outp() is defined as:
outp(port,val): port -- val.
Possible, this is more convenient, but the older
Avr-libc releases use another order:
outp(val,port): val -- port.
Dmitry.
___
AVR-libc-dev mailing list
On Monday 24 April 2006 09:25, Björn Haase wrote:
David Carr wrote on Montag, 24. April 2006 09:37 :
Just as a point of reference:
Execution times for the aforementioned benchmark
386 (with 387 co-processor) @ 33MHz
.67s
486DX2 66MHz
.121s
Considering that the AVR is 8bit and
On Tuesday 04 April 2006 07:19, Mark v/d W. wrote:
Hi Everyone
I've been wondering for some time now, how can I contribute to avr-gcc
(and everything used with it), and what skills I need to be useful. Are
there any jobs that need to be done? I hear a lot about floating point
routines that
On Sunday 05 March 2006 18:53, you wrote:
[...]
Would you try again, and tag your callback C functions with a
__attribute__(externally_visible)?
Thanks for advice.
In result:
Options: rlx cmb cmb+rlx whp whp+rlx
Congratulation!
I have try a one project. Not the best example:
a very large part consists from asm-writen libraries
where short rcall/rjmp are used. Nevertheless,
a considerable effect is.
--relax withoutwith
flash, bytes 11412 11056
call
Hi.
In two right columns time of operations after addition of
the IEEE 754 rules is shown. After little changes speed has
increased even, sometimes - considerably. Measurements are
lead on files of random numbers (on 500 pieces). Files are
picked up in view of features of this or that function.
Hi.
In two right columns time of operations after addition of
the IEEE 754 rules is shown. After little changes speed has
increased even, sometimes - considerably. Measurements are
lead on files of random numbers (on 500 pieces). Files are
picked up in view of features of this or that function.
Hi.
The fmod() function is not absolutely accurate.
For example:
fmod (101, 100) -- 9.536743e-01
fmod (101, 10) -- 1.015625e+00
The reason is too simple algorithm with float point
arithmetic usage.
fmod() is an important function. It is used in
trigonometric: sin/cos/tan .
On Wednesday 11 January 2006 07:39, you wrote:
Hello.
On some values, like 1.99 (3.99 and so on) log() function
give too worse results. For example:
log(1.999) -- 0.693
True value = 0.688
No, true value for log(1.999) is 0.692647.
Anatoly.
Sorry, I was wrong.
0.688 is
Hi,
is Arv-libc CVS free for reading?
Now I get the next result:
Permission denied (publickey).
cvs [checkout aborted]: end of file from server (consult
above messages if any)
I have try to change login name from 'anoncvs'
to 'anonymous': the same error.
Last time (at November
On Thursday 22 December 2005 17:56, Dmitry K. wrote:
[...]
I have prepare a patch and will send to Savannah after testing.
Subnormals will work also.
Preview of a patch:
[...]
Sorry, I am wrong.
Above patch of ldexp() works only with my changed pair
split/merge functions. It is needed
On Thursday 22 December 2005 09:06, Anatoly Sokolov wrote:
URL:
http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15266
Summary: Function ldexp incorrectly processes overflow and
underflow cases.
[...]
Yes, it is.
I have prepare a patch and will send to Savannah
I vote for something like itoa_fast() and have itoa() keeps its old
features.
Bernard
If anyone is counting votes then mine is to support Bernard, keep itoa as
is but introduce a restricted replacement with a new name.
Nigel Winterbottom
I join this opinion.
Dmitry.
On Monday 21 November 2005 08:28, Dmitry K. wrote:
On Sunday 20 November 2005 21:48, Peeter Vois wrote:
Hi,
The testpackage
http://my.tele2.ee/vois/avrtest-0.0.6.tar.gz
Is it true place? I can not download.
Yes, it is downloaded, thanks.
Very small note.
Looking the file
On Sunday 20 November 2005 21:48, Peeter Vois wrote:
Hi,
The testpackage
http://my.tele2.ee/vois/avrtest-0.0.6.tar.gz
Is it true place? I can not download.
Dmitry.
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
On Saturday 12 November 2005 08:07, Anatoly Sokolov wrote:
Update of bug #13340 (project avr-libc):
Status:None = Fixed
Assigned to: aesok = None
Open/Closed:Open = Closed
1 - 100 of 118 matches
Mail list logo
