| Author |
Message |
|
|
 Posted: Jan 13, 2012 - 02:25 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
gkarlsson wrote:
The caveat is that the second instruction needs to occur within 4 clock cycles.
In this particular case, it's quite unreasonable not to write asm.
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 03:26 PM |
|
Joined: Jul 18, 2005
Posts: 62236
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
In this particular case, it's quite unreasonable not to write asm.
Which is how AVR-LibC manages to guarantee most of the 4 cycle sequences. If there's an error here then it's probably actually that AVR-LibC should have code added to cater for this particular sequence. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 03:33 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
| Anybody cares to add a feature request to avr-libc's tracker? |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 03:43 PM |
|
Joined: Dec 21, 2011
Posts: 15
Location: Jupiter, FL
|
|
| I don’t think the issue is just this one sequence. As I pointed out it appears as if every assignment of a register in I/O space is done with a store indirect instead of using an out. Point me in the right direction and I will write up the feature request. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 04:40 PM |
|
Joined: Dec 08, 2004
Posts: 4719
Location: Nova Scotia, Canada
|
|
When you're talking about an explicit I/O register assignment in vanilla C code, the correct bug tracker would be for the compiler, GCC. Bug: GCC is using sub-optimal rules for code generation.
When you're talking about special timed sequences that are encapsulated within an existing avr-libc hardware abstraction API, then the correct bug tracker would be for avr-libc. Bug: The hardware abstraction API shouldn't depend upon compiler optimization, and therefore should have been written in assembly to begin with, not plain vanilla C.
My crystal ball tells me that in this case, there was no appropriate abstraction API available in avr-libc, so the OP was writing the code directly in vanilla C. So, in all likelihood we're probably dealing with the former case, not the latter. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 04:53 PM |
|
Joined: Jul 18, 2005
Posts: 62236
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
My crystal ball tells me that in this case, there was no appropriate abstraction API available in avr-libc, so the OP was writing the code directly in vanilla C. So, in all likelihood we're probably dealing with the former case, not the latter.
Luke,
I think it's two layered. Yes there may be a code generation fault in the C compiler and if so it deserves to reported/fixed but if the sequence being attempted was something that many users using that chip would like to be doing on a regular basis then it also deserves a hand crafted piece of Asm in AVR-LibC too that then saves the same wheel being reinvented N thousand times and all the associated issues of folks attempting it at -O0 even if the code generation fault is eventually fixed as it still probably could be made to work at -O0. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 05:13 PM |
|
Joined: Jun 19, 2002
Posts: 950
Location: SF Bay area
|
|
|
gkarlsson wrote:
The compiler never generates an 'out' instruction, everything moved to a register memory position uses the z register and st.
Um, that's not true:
Code:
void setup() {
// initialize the digital pin as an output.
// Pin 13 has an LED connected on most Arduino boards:
PORTB = 0;
12a: 15 b8 out 0x05, r1 ; 5
pinMode(13, OUTPUT);
12c: 8d e0 ldi r24, 0x0D ; 13
12e: 61 e0 ldi r22, 0x01 ; 1
130: 0e 94 79 01 call 0x2f2 ; 0x2f2 <pinMode>
PORTB = 0x12;
134: 82 e1 ldi r24, 0x12 ; 18
136: 85 b9 out 0x05, r24 ; 5
}
138: 08 95 ret
I'm not sure what you need to do to get C to recognize that some things are usable via the OUT instruction, and certainly inline assembler is a better way to be SURE that things are done with the required cycle. I suspect that your construct:
Code:
*((char*)0x40)=0x16;
was NOT what the compiler would have wanted. (though it does still generate an OUT instruction in the same atmega328 environment as the above example...)
This can probably be chalked up to "half-Tiny" chips support is a bit shaky still." |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 05:59 PM |
|
Joined: Dec 21, 2011
Posts: 15
Location: Jupiter, FL
|
|
|
Quote:
This can probably be chalked up to "half-Tiny" chips support is a bit shaky still."
I agree, I was only referring to the code being generated for the ATTiny 4 thru 10.
As I have not used any of the other processors yet I cannot make any comments about code being generated for them. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 06:38 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
I'd say, if lds/sts generates wrong binary, the assembler needs to be fixed first (i.e. it's a binutils bug and should go to binutils's (binutils' ?) tracker).
If I understand it correctly, the compiler deliberately does not generate lds/sts to avoid this bug; so that's the second to be fixed. That should go to gcc's tracker, but there's little point to do that until the first gets fixed.
Then there's an additional issue, as Cliff said, the library should provide prechewed asm code for the critical sequences; however, it also depends on the fixed assembler (OK it may use .byte/.word, but that's crude). That then should go to avr-libc's tracker.
And then there's Atmel's internal tracker, where you already "got a ticket" - except that we don't know for what exactly.
Welcome to the wonderfully organized world of GNU AVR tools.
JW
PS. IIRC Eric Weddington used to maintain one more list of bugs...  see sticky at top of this forum |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 07:43 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
gkarlsson wrote:
I don’t think the issue is just this one sequence. As I pointed out it appears as if every assignment of a register in I/O space is done with a store indirect instead of using an out. Point me in the right direction and I will write up the feature request.
You mean This? http://gcc.gnu.org/PR50448 |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 07:51 PM |
|
Joined: Dec 21, 2011
Posts: 15
Location: Jupiter, FL
|
|
|
Quote:
Not Really - that code would use a STS which would also need to be fixed. I did try the 4.7 version and it did not resolve the sts issue, I did not check it against the other issues. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 10:15 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
gkarlsson wrote:
Quote:
Not Really - that code would use a STS which would also need to be fixed. I did try the 4.7 version and it did not resolve the sts issue, I did not check it against the other issues.
So why is STS wrong (with respect to compiler proper) when accessing RAM?
What is the sample code where compiler proper genenrates wrong code? |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 10:18 PM |
|
Joined: Dec 21, 2011
Posts: 15
Location: Jupiter, FL
|
|
|
Quote:
So why is STS wrong (with respect to compiler proper) when accessing RAM?
Because the STS it is generating is 32bit not 16 bit. ATtiny 4-10 can only use a 16 bit STS. I was answering in relation to the thread not in general. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 10:28 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
gkarlsson wrote:
Quote:
So why is STS wrong (with respect to compiler proper) when accessing RAM?
Because the STS it is generating is 32bit not 16 bit. ATtiny 4-10 can only use a 16 bit STS. I was answering in relation to the thread not in general.
So it's not a compiler issue, it's issue of binutils and thus of supplier of the distribution (Atmel?)
AFAIK this is a well known error in Atmel fork of GNU AVR tools.
The issue is straight forward to fix for anyone familiar with binutils, so I wonder why Atmel did not supply a fixed version up to now. Or did they? |
|
|
| |
|
|
|
|
|
|
Posted: Jan 16, 2012 - 01:24 PM |
|
Joined: Dec 08, 2004
Posts: 4719
Location: Nova Scotia, Canada
|
|
|
SprinterSB wrote:
gkarlsson wrote:
Quote:
So why is STS wrong (with respect to compiler proper) when accessing RAM?
Because the STS it is generating is 32bit not 16 bit. ATtiny 4-10 can only use a 16 bit STS. I was answering in relation to the thread not in general.
So it's not a compiler issue, it's issue of binutils and thus of supplier of the distribution (Atmel?)
AFAIK this is a well known error in Atmel fork of GNU AVR tools.
... Keep in mind, though, that there is no solution to this problem at the head of the source tree for the official GNU version of binutils either. In fact, the GNU version of binutils simply doesn't acknowledge the existence of the reduced AVR CPU core in the ATtiny4/5/9/10 and ATtiny20/40 families at all.
Judging by the current state of the latest avr-bintutils patches from the FreeBSD ports system, I would venture to guess that it knows about the ATtiny10 (and its brethren), but it does not correctly implement LDS/STS for those devices either. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 16, 2012 - 04:13 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
lfmorrison wrote:
SprinterSB wrote:
gkarlsson wrote:
Because the STS it is generating is 32bit not 16 bit. ATtiny 4-10 can only use a 16 bit STS.
[...] it's issue of binutils and thus of supplier of the distribution (Atmel?)
AFAIK this is a well known error in Atmel fork of GNU AVR tools.
... Keep in mind, though, that there is no solution to this problem at the head of the source tree for the official GNU version of binutils either.
Why should there be a solution in binutils? There is not even support of Tiny, so how is anyone supposed to fix bugs that do never occur?
Tiny is implemented in Atmel's private port, so it's up to them to make bug fixes and release tools of reasonable quality. Atmel is independent of binutils or GCC's release cycles and can provide an upgrad at any time; they don't even need to have changes approved by someone else. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 18, 2012 - 06:33 AM |
|
Joined: Feb 18, 2012
Posts: 2
|
|
|
|
|
|
|
|
Posted: Feb 18, 2012 - 10:41 AM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
theusch wrote:
Perhaps dig into the new 4.7
This is obviously a binutils bug and not a compiler bug. Moreover, neither avr-gcc 4.7 nor binutils 2.23 have support for Tiny. It's all fun of Atmel's private port. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
