See comments below
On Mon Apr 29 2013 05:56:08 PM CEST, Joerg Wunsch j...@uriah.heep.sax.de
wrote:
===
--- trunk/avr-libc/configure.ac 2013-04-29 12:21:04 UTC (rev 2371)
+++ trunk/avr-libc/configure.ac 2013-04-29 15:56:07
Spotted some typos.
I hope it is readable, my phone email client is not the best.
On Mon Apr 29 2013 11:06:52 PM CEST, Joerg Wunsch j...@uriah.heep.sax.de
wrote:
Revision: 2374
===
---
Mike Rice schreef op 2013-03-31 23:05:
+__SREG__ = 0x3f
+__tmp_reg__ = 0
+__zero_reg__ = 1
+
+.globalsystem_tick_i
+ .type system_tick_i, @function
+system_tick_i:
+ push r1
+ push r0
+ in r0,__SREG__
+ push r0
+ clr __zero_reg__
+ push r24
+
Weddington, Eric schreef:
-Original Message-
From: Weddington, Eric
Sent: Thursday, June 17, 2010 9:15 PM
To: 'Wouter van Gulik'; avr-libc-dev@nongnu.org
Subject: RE: [avr-libc-dev] LPM instructionsin optimized code
causes unintended behavior in execution
As a matter of fact
Joerg Wunsch schreef:
As Wouter van Gulik wrote:
IMHO, the respective code is hand-crafted asm code in avr-libc.
Are you sure? The code is about a jump table, is that in avr-libc?
Errm, you are right...
We should probably file a bug report at binutils as well. gas is
excepting
Wouter van Gulik schreef:
Joerg Wunsch schreef:
As Wouter van Gulik wrote:
IMHO, the respective code is hand-crafted asm code in avr-libc.
Are you sure? The code is about a jump table, is that in avr-libc?
Errm, you are right...
We should probably file a bug report at binutils as well
- Oorspronkelijk bericht -
As Thomas Carsten Franke wrote:
I did not restored the NVM CMD because I
didn't know that it would has to be.
This is correct. We recently added a note to the documentation in the
header file avr/pgmspace.h telling that on Xmega devices, all the
On 17/06/10 10:15, Thomas Carsten Franke wrote:
Am 17.06.2010 09:38, schrieb Wouter van Gulik:
Wouter van Gulik schreef:
Joerg Wunsch schreef:
As Wouter van Gulik wrote:
IMHO, the respective code is hand-crafted asm code in avr-libc.
Are you sure
- Oorspronkelijk bericht -
As Wouter van Gulik wrote:
Although true, I rather think this is a GCC bug. The avr instruction
documentation says LPM R31, Z+ has undefined results. In the example
it was oke to use LPM R31, Z.
IMHO, the respective code is hand-crafted asm code
Joerg Wunsch schreef:
+
+\code
+#define cli() __asm volatile( cli ::: memory )
+#define sei() __asm volatile( sei ::: memory )
+
+unsigned int ivar;
+
+void test2( unsigned int val )
+{
+ val = 65535U / val;
+
+ cli();
+
+ ivar = val;
+
+ sei();
+}
+\endcode
+
+compiles with optimisations
Hi list,
Currently putchar is defined as
#define putchar(__c) fputc(__c, stdout)
which causes C code like this:
putchar(' ')
To generate assembler like this:
lds r22,__iob+2
lds r23,(__iob+2)+1
ldi r24,lo8(32)
ldi r25,hi8(32)
call fputc
This is 8 bytes (lds == 4 bytes) for loading
Weddington, Eric schreef:
Mainly because this is a total rewrite of the implementation. The API
(interface) stays the same. I'm certainly fine with putting the old
copyrights back on.
I thought the address thingy was taken from Bjoern Haasse's
implementation. So that's why I thought he
Weddington, Eric schreef:
Bah! Trying again.
Thanks for everyone's patience.
Eric Weddington
So I got the header and my first consideration in is the copyright...
All previous contributers are now gone? I hope this is WorkInProgress.
Second why all these hideous define with there
uart_puts (strcpy_P (buf, (PGM_P)pgm_read_word (sms_keys[num][2])))
I'd expect this to print the numth string starting at the 3 character
(it works as expected in non-embedded normal C). Am I doing something
cluelessly wrong, or am I tickling a bug in the compiler? I'm using
Or inline functions defined in a header file.
Sheesh. You guys are making comments about *how* I implemented the
functionality, not if it *actually works*.
Well I would, if I knew where to get the sources... There not on the list,
not in the avr-libc bug report. So where can I find
It's a bit late to be discussing these issues, or reworded: I wish that
discussions like this were done a lot earlier.
I'm planning on release WinAVR with GCC 4.2.2. The most major issue that
I see right now is GCC bug #29524
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
I would like to see
Shaun Jackman schreef:
Follow-up Comment #2, bug #21623 (project avr-libc):
Definitely remove r30 and r31 from the clobber. The spm instruction doesn't
clobber the Z register, since it has the same value going out as coming in. If
it did modify the Z register, it should be listed with a
in devices with 8-Bit address registers
As Wouter van Gulik wrote:
What is the main reason not to build a per-device lib, apart from
the time to do such a thing? I quickly scanned the mailing archives
but I could only find the build time as a reason. Is this still
valid?
Basically yes
Lars Jonsson schreef:
Follow-up Comment #2, bug #21382 (project avr-libc):
Ok, good that is is known but I don't really get the concept of private
bugs.
I don't get this either.
Maybe because it's somehow a potential security issue?
What is a private bug? And why?
HTH,
Wouter
Joerg Wunsch schreef:
As Joerg Wunsch wrote:
I disabled the privacy field in the Web form, because I think it
doesn't make any sense for the avr-libc deliveries. There have
been two other (already closed) bugs with privacy set to Private,
so I postum made them public as well.
Oke thanks! I
Haase Bjoern (PT/EMM1) schreef:
Yes I will try to put together a patch with the minimal changes. I only
need
to know one thing; can I assume that using this construction:
/** \ingroup avr_eeprom
Read one 16-bit word (little endian) from EEPROM address \c addr.
*/
uint16_t
Haase Bjoern (PT/EMM1) schreef:
Yes I will try to put together a patch with the minimal changes. I only
need
to know one thing; can I assume that using this construction:
/** \ingroup avr_eeprom
Read one 16-bit word (little endian) from EEPROM address \c addr.
*/
uint16_t
Hi List,
I found that bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644 is
probably more related to avr-libc than gcc.
The problem is the eeprom_read_word definition. It returns it's values
in r31:r30 instead of the regular r25:r24.
This somehow kills the compilers ability to relocate the
I agree, this whole setup seems strange. Perhaps if you look in the CVS
log
(you can do it online at the avr-libc project), perhaps there may be some
comments as to why it was originally done this way. Note that the EEPROM
API
was originally written (copyrighted) by Marek Michalkiewicz.
Hi List,
I found that bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644 is
probably more related to avr-libc than gcc.
The problem is the eeprom_read_word definition. It returns it's values
in r31:r30 instead of the regular r25:r24.
This somehow kills the compilers ability to relocate the
25 matches
Mail list logo
