Re: [avr-gcc-list] Need USB?
On Tuesday 06 February 2007 17:55, Christopher X. Candreva wrote: USB Remote Control: http://tinyurl.com/5gsgc = 500 Internal Server Error How about the actual link ? try: http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB (AVR)_eng.htm -- Scanned by: ClamAV 0.88.7/2526/Tue Feb 6 03:42:08 2007 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] CodeWright 7.0
I understand that Borland has resurrected CodeWright 7. I really like CodeWright 7 and I'm going to do the $99 upgrade. How do you get CodeWright 7 to work as the default editor in AVR Studio? Also, you guys like CodeWright 7? Barry ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5,regression?
David Brown wrote (in part): ... I don't know if the C standard is clear on expressions such as a = b = c, when some or all of these are volatile ... It is clear. The assignment operator has right-to-left associativity so b = c is evaluated first. The result of an assignment is the value assigned. So, the value assigned to b is then assigned to a. I can't see how volatile could affect this, but it certainly can't make things less well-defined. At the risk of sounding patronising, I'd say that almost any code with a = b = c expressions is incorrect code because it is far from clear what you mean, and if volatiles are involved then it is undoubtedly wrong. You don't sound patronizing, just wrong. When the code is re-written to actually say what you mean, do you still get a difference? This is a useful question/suggestion, however, and may shed some light on the problem. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?
On Tue, 20 Feb 2007 03:24:49 -0500, David Brown [EMAIL PROTECTED]
wrote:
If you can't post a cut-down version, then at least post a compilable
section of your code with the minimal necessary typedef's and other
definitions included. To be able to test your code, people will have to
be able to reproduce the bug.
I understand the issue, but the Boss would not be happy
if I posted all of the code, and when I cut it down I can't
reproduce the problem
At the bottom of this message is a version that shows the essence of what
I'm trying to do, however it does not reproduce the initial problem,
which maybe leading us down a path that is a waste of everyones
time. It does raise a question about assignment to volatiles.
pattern_flash_ptr_reload_u8_v = (PGM_UP)
pgm_read_word( pattern_table[ pattern_u8++ ] );
Has been removed in both 3.4.5 and 4.1.1. Should not the assignment to
a volatile always be done?
If the same code is generating assembly with different ordering despite
the volatiles, then it is quite likely that there is a bug somewhere.
Yes.
However, I don't know if the C standard is clear on expressions such as
a = b = c, when some or all of these are volatile - it could be that
both implementations are correct because the rules are not strict.
I concede your point on the volatile issues.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
5.1.2.3 point 3.
6.7.3
I'd say that almost any code with a = b = c expressions is incorrect
code because it is far from clear what you mean,
I do not see how a = b = c; is in anyway outside of the C standard,
when volatiles are not involved, and the types are the same.
The order of assignment is always right-to-left. We are not mixing
any left-to-right/right-to-lefts here.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
6.5.16.2 Compound assignment
When the code is re-written to actually say what you mean, do you still
get a difference?
There is no change, object code is identical between:
pattern_flash_ptr_u8_v = pattern_flash_ptr_reload_u8_v = (PGM_UP)
pgm_read_word( pattern_table[ pattern_u8++ ] );
and
pattern_flash_ptr_reload_u8_v = (PGM_UP)
pgm_read_word( pattern_table[ pattern_u8++ ] );
pattern_flash_ptr_u8_v = pattern_flash_ptr_reload_u8_v;
Footnote #114 seems to be violated here (removed), and in my original
problem (reordered).
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
114) A volatile declaration may be used to describe an object
corresponding to a memory-mapped
input/output port or an object accessed by an asynchronously interrupting
function [pattern_flash_ptr_u8_v]. Actions on objects so declared shall
not be 'optimized out' by an implementation or reordered except as
permitted by the rules for evaluating expressions.
Leaving me to wonder what I'm missing about permitted by the rules for
evaluating expressions,
in this context.
Also I know from previous experiments that in AVR-GCC
a = b = c; produces smaller code, in some cases,
than b = c; a = b;, otherwise the ojbect code size is the same.
The exception being if you are assigning
zero, due to r1 always containing zero, a = 0; b = 0; c = 0;
produces smaller code than a = b = c = 0;
http://www.open-std.org/jtc1/sc22/wg14/www/standards
Example Code, for Tiny2313.
#include avr/interrupt.h
#include avr/io.h
#include avr/pgmspace.h
#include inttypes.h
#define SLEEP()__asm__ __volatile__ (sleep \n\t :: );
typedef uint8_t PROGMEM prog_uint8_t;
#define PGM_UP constprog_uint8_t *
static volatile PGM_UP pattern_flash_ptr_u8_v;
static volatile PGM_UP pattern_flash_ptr_reload_u8_v;
static uint8_t mode_button_press_count_u8, max_button_presses_u8
= 2;
static uint8_t pattern_u8;
ISR( TIMER1_COMPA_vect )
{
PORTB = pgm_read_byte( pattern_flash_ptr_u8_v++ ); /* Output the
pattern, then point at the next pattern */
if( 0 == pgm_read_byte( pattern_flash_ptr_u8_v ) )/* A zero indicates
that it is time to start pattern over */
{/* If we have reached the end of the table, so restart at the beginning
*/
pattern_flash_ptr_u8_v = pattern_flash_ptr_reload_u8_v;
}
}
#define LED2 _BV(5)
uint8_t model_100[] PROGMEM =
{
LED2,
0 /* Mark end of table */
};
PGM_UP pattern_table[] PROGMEM = {
model_100,
model_100,
model_100,
model_100,
model_100,
};
int main( void )
{
/* I/O Setup would be here */
for(;;)/*ever*/
{
/* Clear variables for this run: */
mode_button_press_count_u8 = 0; /* etc. */
/* Enable Interrupts here, after loading default values for the
pattern pointers */
do{
pattern_flash_ptr_reload_u8_v = (PGM_UP)
pgm_read_word( pattern_table[ pattern_u8++ ] ); /* Pattern will overflow
array bounds in this example code */
pattern_flash_ptr_u8_v = pattern_flash_ptr_reload_u8_v;
/* Interrupts should be disabled during the above */
#if 1/* Setting to zero causes 4.1.1 to
Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?
Graham Davies wrote: David Brown wrote (in part): ... I don't know if the C standard is clear on expressions such as a = b = c, when some or all of these are volatile ... It is clear. The assignment operator has right-to-left associativity so b = c is evaluated first. The result of an assignment is the value assigned. So, the value assigned to b is then assigned to a. I can't see how volatile could affect this, but it certainly can't make things less well-defined. There are at least two of ways to interpret a = b = c while maintaining right-to-left associativity, when the variables are all volatile: int x = c; // volatile read of c b = x; // volatile store to b a = x; // volatile store to a or int x = c; // volatile read of c b = x; // volatile store to b int y = b; // volatile read of b a = y; // volatile store to a I don't know which of these is specified by the standard - I believe, but am not sure, that it is unclear. At the risk of sounding patronising, I'd say that almost any code with a = b = c expressions is incorrect code because it is far from clear what you mean, and if volatiles are involved then it is undoubtedly wrong. You don't sound patronizing, just wrong. Code which is unclear to the writer and to readers is bad code. Certainly different programmers have different ideas of what is clear or not, but I think that when you get to the stage of experienced programmers looking up the semantics in the standards, the code is bad. When the code is re-written to actually say what you mean, do you still get a difference? This is a useful question/suggestion, however, and may shed some light on the problem. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] __disable_interrupt();
Many Thanks, with the # define the compilation it's ok. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?
Graham Davies [EMAIL PROTECTED] wrote: It is clear. The assignment operator has right-to-left associativity so b = c is evaluated first. The result of an assignment is the value assigned. So, the value assigned to b is then assigned to a. I can't see how volatile could affect this, but it certainly can't make things less well-defined. As the volatile qualifier *only* demands the objects to be stable at sequence points, it's quite clear to me that the actual order the assignments might happen is not guaranteed by anything -- not even for volatile objects. The order of evaluation (which is what associativity is about) does not necessarily match the order of execution. Basically, if a and b have the same type, the order of evaluation doesn't matter at all, as it does not affect the result. This order only gets important if they have different types (as type promotion rules might become important then). So if you care about the sequence, you *have* to write: b = c; a = b; If a and b are qualified volatile, that would guarantee they are being written in exactly that order. Another way would be using the comma operator, as it also creates a sequence point. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Wrong excution order in 4.1.1, but not 3.4.5, regression?
I wrote a lengthy reply from work this morning, but it has never shown up on the list. When the code is re-written to actually say what you mean, do you still get a difference? Saying: a_volatile = b_volatile = c; produced exactly the same object code as: b_volatile = c; a_volatile = b_volatile; Problem remained the same, compiled with 3.4.5 the code works, with 4.1.1 it did not. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Avr-gcc versions comparison.
Hi. I have compile CVS version avr-libc (2007-02-20) with for different compilers. Results are below. AVR: at90s8515 atmega8 avr-gcc version: 3.3.6 3.4.6 4.0.4 4.1.2 3.3.6 3.4.6 4.0.4 4.1.2 -- dtostre(1.2345,s,6,0) Flash: 1024 1024 1120 1212 954 954 1038 1112 Stack: 15151517 15151517 Time:1199 1199 1289 13151060 1060 1123 1155 -- dtostrf(1.2345,15,6,s) Flash: 1668 1690 1698 16701514 1530 1570 1546 Stack: 35383838 35383838 Time:1672 1623 1669 16091482 1439 1495 1446 -- qsort(s,sizeof(s),1,cmp) Flash: 1316 1304 1222 12241088 1080 996 998 Stack: 36363636 36363636 Time: 21917 21898 20184 20476 16978 16966 16004 16296 -- rand() Flash:550 550 500 494 510 510 480 482 Stack: 18181818 18181818 Time:1507 1507 1486 14861499 1499 1484 1484 -- sprintf(s,%d,12345) Flash: 1806 1782 1776 17141610 1590 1584 1524 Stack: 59596057 59596057 Time:1729 1723 1733 17051623 1621 1634 1607 -- sprintf_flt(s,%e,1.2345) Flash: 3448 3398 3318 32903148 3110 3034 2992 Stack: 61616264 61616264 Time:2508 2501 2504 24882285 2282 2286 2269 -- sprintf_min(s,%d,12345) Flash: 1294 1276 1252 12281150 1136 1106 1096 Stack: 61616365 61616365 Time:6951 6936 6908 69396774 6761 6742 6784 -- sscanf(12345,%d,i) Flash: 1824 1816 1940 19061654 1646 1730 1704 Stack: 51515555 51515555 Time:1817 1838 1816 17961515 1536 1534 1519 -- sscanf_flt(1.2345,%e,x) Flash: 4164 4124 4220 41443818 3778 3824 3788 Stack:124 124 126 128 124 124 126 128 Time:3055 3054 3052 30722682 2682 2683 2704 -- sscanf_min(12345,%d,i) Flash: 1500 1498 1518 15161364 1364 1380 1382 Stack: 50505454 50505454 Time:1783 1774 1742 17401473 1469 1461 1459 -- strtod(1.2345,p) Flash: 1558 1544 1676 16361454 1442 1538 1514 Stack: 20202022 20202022 Time:1253 1251 1275 1277 991 990 1014 1018 -- strtol(12345,p,0) Flash:826 860 898 908 780 790 760 822 Stack: 20202021 20202121 Time: 988 1012 965 990 725 723 680 720 -- strtoul(12345,p,0) Flash:792 794 884 854 746 744 840 814 Stack: 20202525 20202525 Time: 976 976 1024 1008 713 704 771 757 Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
