work across platforms and
deliver consistent behaviour.
Ivan
On Fri, Apr 22, 2022 at 5:22 AM David Brown <mailto:david.br...@hesbynett.no>> wrote:
On 22/04/2022 02:18, Ivan Perez wrote:
> Hi,
>
> I'm trying to compile a program for arduino that relies on
On 22/04/2022 02:18, Ivan Perez wrote:
Hi,
I'm trying to compile a program for arduino that relies on tgmath.h to
pick the right version of a function based on the types (the code is
automatically generated by another tool).
It's failing to compile with avr because tgmath.h is missing.
I th
On 23/06/2021 10:37, BERTRAND Joël wrote:
> In bad.S, self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg) gives :
> a340: 68 01 movwr12, r16
> a342: ff e4 ldi r31, 0x4F ; 79
> a344: cf 1a sub r12, r31
> a346: fe ef ldi r31
On 22/06/2021 18:00, Ian Molton wrote:
> On 22/06/2021 12:59, BERTRAND Joël wrote:
>> Hello,
>>
>> I'm writing a firmware for a board that uses a ATMega 1284. Firmware
>> continuously restarts
>
> This is likely a branch through zero.
>
> Common causes on AVR are bad function pointers,
On 29/05/2021 18:45, BERTRAND Joël wrote:
> David Brown a écrit :
>> On 29/05/2021 14:37, BERTRAND Joël wrote:
>>> Nigel Winterbottom a écrit :
>>>> I took a quick look and attempted to compile your Crypto library in
>>>> Visual Studio.
>>>>
&g
On 29/05/2021 14:37, BERTRAND Joël wrote:
> Nigel Winterbottom a écrit :
>> I took a quick look and attempted to compile your Crypto library in
>> Visual Studio.
>>
>> I got nowhere: Probably for good reasons; Microsoft C doesn't allow
>> dynamic array size like this:
>>
>> bigint_word_t d_b[a->l
On 29/04/2021 21:43, Ian Molton wrote:
> Hi,
>
> I'm attempting to build my project, which does not use libc, or libm,
> but I do want to link with libgcc.
>
> additionally, I don't want any startup code to be linked - the project
> is intended to be fully standalone.
>
If you don't use any fun
On 12/04/2021 14:12, Klaus Rudolph via Gcc-help wrote:
> Am 12.04.21 um 13:53 schrieb Matthijs Kooijman:
- figure out, where the special handling of the __vector_10 seems to
happen, and why it is not happening in the class template case. This
might help diagnose if and where to fix i
On 12/04/2021 10:46, Klaus Rudolph wrote:
> Thank you all so much for wasting my thread!
>
> Please do NOT answer, you all produced enough spam! Would be nice if
> someone can help on *MY* topic!
>
> Thanks!
>
Sorry, but that is not the way mailing lists or other public discussion
mediums work.
off as to what the compiler does. At this point you have to have near
> complete trust the compiler is doing the right thing.
>
> If you do not trust the compiler to do the right thing, you are using
> the wrong compiler.
>
> Trampas
>
> On Sun, Apr 11, 2021 at 8:1
On 10/04/2021 22:11, Klaus via Gcc-help wrote:
> Hi,
>
>
>
> Am 10.04.21 um 17:26 schrieb Jonathan Wakely:
>
>>
>> Dummy<1> d1;
>>
>>
>> This doesn't cause the instantiation of the member function.
>>
>> Have you tried an explicit instantiation?
>>
>> template class Dummy<1>;
>
> Did not c
Well, if you want a flame war, then let me chime in - you are wrong,
Trampas is right.
You are /wrong/ to suggest that "commercial embedded systems ALWAYS
directly benefit from being small and fast". Some do - for many, it is
irrelevant as long as they are small enough and fast enough. Once you
rget to mention that *16/256 instead of >>4 does insert
> some code to add ((2^n) -1) on negative values (because /16 and >>4 is
> not the same).
>
> So a direct optimization on shr would be better.
>
> Kind regards, Jochen
>
>
> Am 30.12.20 um 12:19 schrieb
Hi,
As a general point, never use "char" like this - use either uint8_t or
int8_t depending on whether you want signed or unsigned. Usually if you
are doing shifts, it's uint8_t you want.
The AVR compiler has trouble with some of these kinds of expressions. I
think it has something to do with t
On 24/07/2019 23:53, Michael Kwasnicki wrote:
> Hello David. Thanks for the explanation. I intentionally reduced the
> code to not bother you with details that didn't help with pointing
> out my issue. So as a conclusion it was my misconception of how
> inline assembly works. In the full code I not
Hi,
Inputs to inline assembly are not exactly like references either,
because they don't have to come from variables already in registers.
They can be initialised by expressions, data in memory, etc. They
simply ask the compiler to ensure that it finds a suitable register (or
memory address,
On 24/07/2019 21:41, Michael Kwasnicki wrote:
So the inputs to inline assembly are by value and not by reference, as I
thought. Right?
Correct. The inputs are used to initialise the registers.
The correlation between my named registers and those C variables was
pure coincidence.
No, it is
On 16/01/18 12:50, georg chambert wrote:
> Hi Erik,
> I have a related question; is there any interrest for the avr dev
> community to find & corr buggs;
> since I could easily work around this, and leave it be.
The avr-gcc developers are always interested in people helping to find
and correct bug
On 09/11/17 17:49, Szikra Istvan wrote:
> Hi David,
>
> What is exactly wrong with my code?
>
> Thanks by the way for __get_PSP and all your help.
This is getting into ARM stuff, and is therefore off-topic for the
avr-gcc list (as you noted below). But the principles are fairly
cross-target.
On 09/11/17 04:57, Szikra Istvan wrote:
> Hi
>
> Thanks for the SP, I missed that.
> And apparently Atmel Studio also cannot find it, and underlines it with
> red error marker.
> It does compile, and I have found it in avr/common.h, it's probably a
> problem with __AVR_ARCH__ handling by AS...
>
On 08/11/17 10:21, Sergey A. Borshch wrote:
> On 08.11.2017 11:03, David Brown wrote:
>> (Also, if you are writing C rather
>> than C++, your function declaration is not correct.) The sensible way
>> to write this is:
>>
>> static inline uint16_t GetStackPointer(v
On 07/11/17 20:36, Szikra Istvan wrote:
> Hi all,
>
> I have this interesting test case for you guys, and girls.
>
>
> #include
>
> unsigned int GetStackPointer()
> {
> volatile unsigned int sp = (SPH << 8) | SPL;
> return sp;
> }
>
> int main(void)
> {
> while(1)
> {
>
On 17/03/17 17:02, Georg-Johann Lay wrote:
> On 16.03.2017 12:12, David Brown wrote:
>> It would be interesting to know if clang/llvm could generate better code
>> for the AVR. gcc has a few fundamental problems with the port. In
>> particular, gcc expects its targets to h
On 16/03/17 22:33, Dylan McKay wrote:
> Maintainer of the LLVM backend here.
>
>> gcc expects its targets to have registers capable of holding
>> an int - in this case, 16 bits. So the AVR port of gcc has to work with
>> register pairs r0:r1, r2:r3, r4:r5, etc., and then the backend peephole
>> p
On 16/03/17 11:22, Senthil Kumar Selvaraj wrote:
>
> David Brown writes:
>
>> It might be a little heretical to ask here, but has anyone tried out the
>> experimental AVR backend in the latest llvm/clang release? I have not
>> made much use of clang, but it's be
On 16/03/17 09:30, Erik Christiansen wrote:
> Reply-To: avr-gcc-list@nongnu.org
>
> On 16.03.17 08:54, David Brown wrote:
>> It might be a little heretical to ask here, but has anyone tried out the
>> experimental AVR backend in the latest llvm/clang release? I have not
>
It might be a little heretical to ask here, but has anyone tried out the
experimental AVR backend in the latest llvm/clang release? I have not
made much use of clang, but it's been good for gcc to have a bit of
friendly competition. I think it will be interesting to see how
clang/llvm differs fro
ssage
From: Stu Bell
Date: 10/02/2017 03:58 (GMT+01:00)
To: David Brown , Bob Paddock
, avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-libc-user-manual: "Problems with reordering
code"
I hate to stick my nose in this after years away from the list, but... David is
On 09/02/17 19:49, Bob Paddock wrote:
On Thu, Feb 9, 2017 at 1:13 PM, David Brown wrote:
Note also that it is only control
of the memory access that is needed for code correctness - moving
instruction execution affects timing, but not the results.
As I'm sure you are aware even i
09/02/17 18:35, Bob Paddock wrote:
Are the functions like macros in atomic.h correct?
They attempt to deal properly with critical sections/code motion etc,
in what this thread is discussing.
http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
On Thu, Feb 9, 2017 at 9:14 AM, Davi
/optimization_1optim_code_reorder.html
> . Is there anybody subscribed to this mailing list who can contact
> the authors/maintainers of the site in order to discuss correction of
> the content?
>
> Marcin Godlewski
>
> W dniu 2016-12-10 23:25:17 użytkownik Marcin Godlewski
>
On 08/12/16 21:46, Georg-Johann Lay wrote:
> Marcin Godlewski schrieb:
>> Dear all,
>>
>> Thanks for the reply to David. However I'm not trying to find a
>> solution for the described issue. What I'm trying to say in this
>> e-mail is that this part of Atmel documentation:
>> http://www.atmel.com/w
On 08/12/16 21:55, Marcin Godlewski wrote:
>
>
> W dniu 2016-12-08 21:46:40 użytkownik Georg-Johann Lay
> napisał:
>> Marcin Godlewski schrieb:
>>> Dear all,
>>>
>>> Thanks for the reply to David. However I'm not trying to find a solution
>>> for the described issue. What I'm trying to say in
On 07/12/16 00:42, Marcin Godlewski wrote:
> Dear all,
>
> I'm writing with reference to the following paragraph in avr libc manual:
> http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder
>
> It is stated there: "However, memory barrier works well in ensuring that
> a
On 30/11/16 23:08, Diogo Martins Silva wrote:
> Thanks, guys.
>
> I asked because I tried a code snippet, but was getting errors.
>
> I found later that the errors came from my IDE's code analysis, not the
> compiler. The code works fine.
>
> Thumbs up for the assembly examples!
>
Sometimes it
On 30/11/16 17:07, Georg-Johann Lay wrote:
> On 30.11.2016 15:32, Paul "LeoNerd" Evans wrote:
>> On Wed, 30 Nov 2016 18:18:11 +0530
>> Senthil Kumar Selvaraj wrote:
>>
>>> Diogo Martins Silva writes:
>>>
Hello all.
The avr-gcc wiki (https://gcc.gnu.org/wiki/avr-gcc) lists 24 bits
>>
On 13/08/16 03:40, Eric Tang wrote:
Hi avr-gcc mailing list,
I have a question about the asm generated for C code that sequentially
checks the bits of an integer in a loop. From what I can gather, during
each iteration of the loop, the integer is shifted right until the bit
to be checked becomes
On 08/11/14 21:42, Szikra István wrote:
> On 2014.11.08. 13:48, David Brown wrote:
>> On 08/11/14 01:32, Szikra István wrote:
>>> Hi everyone!
>>>
>>> My problem in sort: I’m getting
>>> inr24, 0x18
>>> ldir25, 0x00
>>&g
On 08/11/14 01:32, Szikra István wrote:
Hi everyone!
My problem in sort: I’m getting
inr24, 0x18
ldir25, 0x00
andir24, 0xEF
out0x18, r24
instead of
cbi0x18, 4
.
I’m trying to write efficient modern C/C++ code for multiple platforms
including AVR 8 bi
On 26/09/14 10:44, Richard Weickelt wrote:
> Hi,
>
>>> Is it fair to conclude that the ~
>>> operator, applied to an unsigned char, does produce an int as output
>>> instead of the input type?
>>
>> Yes, this is exactly what the C standard promotion rules require.
>>
>> Well, to be exact, they *re
On 25/09/14 19:50, Christian Schmidt wrote:
> Hi again,
>
> I did some more testing and found that using
>
> int main (void) {
> uint8_t reg;
> do {
> reg = PINx(I2C_PORT); // macro translates to PIND
> 6a: 80 b3 in r24, 0x10 ; 16
> } while (((uint8_t
Hi,
I haven't studied the generated code fully, but this is actually
perfectly reasonable behaviour from the compiler's viewpoint. The logic
is as follows:
Since ptr1 is never assigned, the loop involving it is undefined
behaviour. It could therefore do /anything/, including making daemons
On 12/12/13 13:56, dfx wrote:
> I would like to use Netbeans to develop AVR-GCC but I had just started a
> small problem.
>
> I created a new Netbeans project using source code for atmega324pa
> already successfully developed previously.
> The editor of Netbeans correctly recognize all symbols exc
On 02/10/13 09:34, Oleksandr Redchuk wrote:
> 2013/10/2 Georg-Johann Lay mailto:a...@gjlay.de>>
>
> David Brown schrieb:
>
> In general, it would be a good thing to delay the zeroing of r1,
> and it
> is worth searching the issue datab
On 01/10/13 09:41, Simon Kirby wrote:
> Hello!
>
> How difficult would it be to convince avr-gcc to not re-zero r1 instantly
> after mul, but delay it until a zero is actually needed? For example,
> see this actual avr-gcc output:
>
> Vneutral = (uint16_t)Vbus * t >> 8;
> ->
> lds
On 22/11/2012 11:04, Georg-Johann Lay wrote:
David Brown wrote:
Georg-Johann Lay wrote:
Thomas, George schrieb:
I checked the patches of the fix in PR53448
Even when the requested alignment in greater than the
BIGGEST_ALIGNMENT (considering it to be 2 for Xmega and 1 for other
devices), we
On 21/11/2012 21:36, Georg-Johann Lay wrote:
Hi, would you avoid TOFU style in the lists? Thanks.
Otherwise we will soon lose track of a conversation.
Thomas, George schrieb:
Hi,
I checked the patches of the fix in PR53448
Even when the requested alignment in greater than the
BIGGEST_ALIGNME
On 16/10/2012 14:28, Weddington, Eric wrote:
-Original Message- From:
avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of Joerg Wunsch Sent: Tuesday, October 16, 2012 12:17 AM
To: avr-gcc-list@nongnu.
On 10/10/2012 23:13, Erik Walthinsen wrote:
On 10/10/2012 01:43 PM, Georg-Johann Lay wrote:
> Such a bug has never been reported to the GCC bug tracker.
Well then, I guess I need to file one. I just have no idea how to
actually fix it, and no time to do so at this point ;-(
If nobody found it
On 26/08/12 17:33, Georg-Johann Lay wrote:
David Brown wrote:
Georg-Johann Lay wrote:
for historical reasons, AVR-Libc implements functions that
GCC expects to live in libgcc, namely float functions like
__fixsfsi.
Would it not be a better idea to move the functions from AVR-Libc
into
On 26/08/12 12:09, Georg-Johann Lay wrote:
Hi,
for historical reasons, AVR-Libc implements functions that
GCC expects to live in libgcc, namely float functions like
__fixsfsi.
Would it not be a better idea to move the functions from AVR-Libc into
libgcc? Or are there complicating issues, su
On 21/08/2012 10:38, Juergen Harms wrote:
On 08/20/2012 10:10 PM, David Brown wrote:
Almost certainly, there is something wrong in your code, or in the way
you have declared your external data - the "-Wuninitialized" flag should
not give false positives as you describe. (It can
On 20/08/12 16:18, Juergen Harms wrote:
I am presently switching from a rather obsolete version of avr-gcc
(1.6.1, downloaded as a tarball) to a much newer one (4.6.2, available
in an rpm package on my Mageia distribution),
I am having a lot of small-fry but work-intensive problems (risk of
edit
On 20/08/12 19:36, Georg-Johann Lay wrote:
Juergen Harms schrieb:
I am presently switching from a rather obsolete version of avr-gcc
(1.6.1, downloaded as a tarball) to a much newer one (4.6.2, available
in an rpm package on my Mageia distribution),
avr-gcc started around 2011, with GCC versi
On 12/08/2012 02:28, Volker Kuhlmann wrote:
On Mon 30 Jul 2012 19:23:25 NZST +1200, David Brown wrote:
Also note that code size is not the only measure of how good a
compiler (or option) is. While it is clearly an important measure
(especially on small systems), sometimes speed is more
On 09/08/12 18:32, Weddington, Eric wrote:
-Original Message- From:
avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr- gcc-list-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of David Brown Sent: Thursday, August 09, 2012 8:06 AM
To: dva...@internode.on.net
On 09/08/12 19:05, David Kelly wrote:
On Aug 9, 2012, at 11:18 AM, Erik Christiansen wrote:
You should be highly sceptical about using integrated SVN clients
in other programs. It is important that you don't mix major
version numbers of the svn clients on a machine - you'll end up
corrupting
On 09/08/12 18:35, Vidya Praveen wrote:
Hi
Since the thread has grown anyway, I'm taking the liberty to reply to this
post.
On 8/8/2012 11:11 PM, Graham Davies wrote:
This is an informative post, I'm pretty certain of my results and I don't
really have a question.
AVR Studio 4.19 does not wor
On 09/08/2012 17:20, Erik Christiansen wrote:
On 09.08.12 16:05, David Brown wrote:
For what it's worth, I too dislike the newer AVR Studio - partly
because I do most of my development work with Linux, and partly
because even on Windows it is a bloated mess. I can't figure out why
th
On 09/08/2012 16:42, David Kelly wrote:
I think its time to start a new thread leveraged off another:
On Aug 9, 2012, at 9:05 AM, David Brown wrote:
For what it's worth, I too dislike the newer AVR Studio - partly
because I do most of my development work with Linux, and partly
because ev
On 09/08/2012 15:32, Erik Christiansen wrote:
On 09.08.12 12:36, Weddington, Eric wrote:
Hi Erik,
What OS and email client do you use?
Hi Eric,
It's Ubuntu 10.04.1 LTS, and Mutt 1.5.20.
And since Georg-Johann appears to use Thunderbird, it's not unreasonable
to suspect that something in Gr
On 30/07/2012 23:25, Georg-Johann Lay wrote:
David Brown schrieb:
What we really need is not an "optimise for size" switch, but an
"optimise for the fastest possible code within the specific limit of X
KB". Is that on the things-to-do list? :-)
Just add it to your GCC to
Hi,
Also note that code size is not the only measure of how good a compiler
(or option) is. While it is clearly an important measure (especially on
small systems), sometimes speed is more important. Maybe the code has
ended up a little bigger but noticeably faster - indicating an issue
with
On 03/05/2012 15:29, Gabriel Dos Reis wrote:
On Thu, May 3, 2012 at 3:33 AM, Georg-Johann Lay wrote:
Gabriel Dos Reis schrieb:
Georg-Johann Lay wrote:
Gabriel Dos Reis wrote:
I guess I would need to get my feet wet with
1. minimal free-standing C++ implementations without exceptions
2.
On 02/05/2012 18:16, Gabriel Dos Reis wrote:
On Wed, May 2, 2012 at 10:18 AM, David Brown wrote:
I agree with what you are saying. I'm just trying to suggest that getting
Haskell to work on the AVR is more akin to getting Linux to work on the AVR
- while perhaps Lua, OCAML, more C+
On 02/05/2012 17:03, Weddington, Eric wrote:
-Original Message- From:
avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr- gcc-list-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of David Brown Sent: Wednesday, May 02, 2012 8:29 AM To:
Gabriel Dos Reis Cc
On 01/05/2012 17:18, Gabriel Dos Reis wrote:
My recent interests in AVR grew out of educational and research
activities -- as I explained in a relatively recent post on libstdc++. I am
still learning AVR and its toolsets but I can definitely help with the C++ part.
We are in the situation where
On 01/05/2012 15:04, Georg-Johann Lay wrote:
Gabriel Dos Reis schrieb:
Georg-Johann Lay wrote:
Kövesdi György schrieb:
I am using avr-g++ for building my projects for avr and i am
happy with it. :-)
But i would need exception support, and could not find how to
get it work. I found some mails
On 01/05/2012 21:34, Bob Paddock wrote:
a subgroup
of students (under my direction) has set up to write a
compiler for a subset
of Haskell targetting AVR. This is quite an exciting research project.
There is the Atom subset of Haskell meant for embedding, if you are
not aware o
On 13/01/12 20:17, Weddington, Eric wrote:
-Original Message-
From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On
Behalf Of David Brown
Sent: Friday, January 13, 2012 10:45 AM
To: avr-gcc-list@nongnu.org
On 13/01/2012 14:37, Ruud Vlaming wrote:
On Thursday 12 January 2012, Weddington, Eric wrote:
The problem that I have with -mint8 is:
- it doesn't follow the standard
- it breaks avr-libc (or rather, avr-libc isn't adapted to it)
- people use it, because the backend hasn't been taught how to do
On 13/01/2012 18:24, Weddington, Eric wrote:
IMNSHO, Code space trumps all other concerns.
Eric
I don't agree with that. It's seldom that I run out of code space on
AVR's - it's more often that I want more effective code (which means
slower clocks, less power, etc.).
Experiences vary, a
On 13/01/2012 12:56, Georg-Johann Lay wrote:
David Brown wrote:
Why not say -mint8 is dead? [...]
Then "-mint8" can be marked "deprecated" in gcc 4.7, and removed in the
future.
I think the -mint8 can be removed immediately without deprecating it
beforehand. -mint8 i
On 12/01/2012 21:09, Weddington, Eric wrote:
-Original Message-
From: Georg-Johann Lay
Sent: Thursday, January 12, 2012 10:55 AM
To: Weddington, Eric
Cc: Joerg Wunsch; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs
areincorrect
sizeof(doubl
On 11/01/2012 08:21, Joerg Wunsch wrote:
"Paul McClean" wrote:
Can anyone explain why the GCC instructions are used in place of the
typical definition?
Because the mode names are GCC's equivalent for specifying a
particular number of bits.
Could it be expressed as:
unsigned long __attribut
Hi,
You are trying to use file IO calls that are dependent on an operating
system, such as Linux. While it is certainly /possible/ to implement
them on an AVR, it is very unlikely to make sense.
If you want to do insertion sorts on a text file, use a PC. If you want
to program an AVR, writ
On 30/08/2011 14:03, Bob Paddock wrote:
Refinements of the concept left as an exercise for the reader. Regards,
Does that mean I am not allowed to post my refinements?
No. Please post. Extra points for using __FILE__ __FUNCITON__ and
__LINE__ to give meaningful error message.
The error
On 29/08/2011 22:03, Dave Hansen wrote:
> From: graceindustr...@gmail.com
[...]
> So that explains the difference. Seems like there could be a better
> error message for this case, 'don't use enum here', alas "The
> preprocessor does not know anything about types in the language"...
Here's
On 07/06/11 19:27, Celio Guimaraes wrote:
uint32_t t1;
int main(){
t1=0xf << (12);// t1 gets f000 instead of f000
}
Others have pointed out your mistake, and given clear explanations.
For the future, please don't make claims about bugs in avr-gcc unless
you are entirely sur
On 15/03/11 22:30, Weddington, Eric wrote:
-Original Message- From:
avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of David Brown Sent: Tuesday, March 15, 2011 2:47 PM To:
avr-gcc-list@nongnu.org
On 15/03/11 15:25, Weddington, Eric wrote:
-Original Message- From:
avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of Administrator Sent: Tuesday, March 15, 2011 12:43 AM
To: avr-gcc-list@nongnu.org
On 13/03/11 19:01, John Myers wrote:
Hi Ray,
It sounds like what you want is to create another address space.
There is the TR 18037 draft called "Programming Languages - C -
Extensions to support embedded processors". GCC has some support for
it: http://gcc.gnu.org/onlinedocs/gccint/Named-Addre
On 04/03/11 23:23, johnea wrote:
On 03/04/2011 02:03 PM, Trevor Woerner wrote:
On Fri, Mar 4, 2011 at 4:56 PM, johnea wrote:
Another vote for VirtualBox...
Which version? Before or after 4?
About a year old version: virtualbox_bin 3.1.6-1
It's the "VirtualBox Personal Use and Evaluation L
On 04/03/11 20:53, Graham Davies wrote:
I wrote:
Since you can have only one version of AVR Studio installed at a time
and
AVR Studio does not uninstall reliably, this means that I have to
re-install
the operating system to switch versions.
and then Trevor Woerner wrote:
Wow, that's crazy!
On 04/03/2011 14:37, Graham Davies wrote:
David Brown wrote:
(This is going to sound like an "I want" rant - which I suppose it is ...
I am a professional developer ... You don't change toolchains in a
project without very good reason ...
So I have a range of WinAVR compiler
S are Eclipse-based.
mvh.,
David
- Gjermund
On Fri, Mar 4, 2011 at 1:42 PM, David Brown mailto:da...@westcontrol.com>> wrote:
On 04/03/2011 05:23, Weddington, Eric wrote:
Hi Stu,
Hope you're doing well. :-)
WinAVR is the Windows packaging of t
On 04/03/2011 05:23, Weddington, Eric wrote:
Hi Stu,
Hope you're doing well. :-)
WinAVR is the Windows packaging of the AVR-GCC stuff, along with
the avr-libc library.
Along with some other stuff, too. ;-)
(In addition, WinAVR is about to be deprecated in favor of a
toolset integrated int
On 04/03/2011 06:20, Trevor Woerner wrote:
On Thu, Mar 3, 2011 at 11:38 PM, Omar Choudary wrote:
Trevor, your idea seems nice, although I would be even more
enthusiastic to put all the patches into the mainstream gcc and then
just do a normal cross-build for the tools.
Yes, ideally this would
On 23/09/2010 15:57, Paulo Marques wrote:
Weddington, Eric wrote:
Hi Johannes,
Hi, Eric
My best guess is that this is a missed optimization. The compiler is
probably selecting different patterns based on the different code. It
recognizes the redundant adding of zero in the operations below w
On 23/06/2010 09:31, samkelo tyatyantsi wrote:
Hi David,
> I know this is a little off-topic, but perhaps it's of interest to
> others in this thread - what do you use for serial terminals, since you
> mentioned them? I've only used minicom so far. It works, but it's like
> a step back to th
On 23/06/2010 04:11, matt.vandewer...@csiro.au wrote:
Ubuntu 10.04 has avr-gcc and avr-libc to the same patch level as
winavr, AFAIK. Apart from that, better editors, better shell, better
serial terminal support, makes for a better avr experience IMO. The
only downside is that you have to write
(Posted on behalf of Jan Waclawek)
The compiler /does/ know when variables are used or not. But the usual
way to allocate frame space is to allocate the maximum needed space on
function entry, and free it on function exit.
That's OK as long as it works.
Consider this simple example:
vola
On 09/06/2010 15:26, Dale wrote:
Hi Eric,>@2010.06.09_15:16:08_+0200
You need to use the "noinline" function attribute on the initialise() function.
Sure, that's one solution. Another is to simply remove static from
initialise(). Its easy if you know which functions are affected.
No, tha
On 02/06/2010 09:11, Leiu wrote:
Thank Joerg Wunsch very much! I've solved my problem!
It's good to hear that your problem is solved.
Don't forget to post the details of your solution here - perhaps it will
be of help to others. This mailing list is for spreading knowledge and
helping every
Lars Noschinski wrote:
Hello!
I'm trying to debug a strange problem, which depends on whether a
function is inlined (then it's broken) or not (then it's ok). Can
someone tell me if the following code snippet violates the C aliasing
rules for b1 (declared as uint8_t*, written as uint32_t* by
xtea
On 06/05/2010 20:34, Graham Davies wrote:
I've spent over an hour looking for this information on the Web and in
the WinAVR documentation but I can't find it so I'm asking for some
pointers.
I'm using WinAVR-20081205 with AVRStudio 4.15, letting the GCC plug-in
do all the heavy lifting (I'm not
vid
Also calling a function like this:
static inline void t_BWd(char bit)
{
bit_write(PORTA,bit,0);
}
only generates a 'cbi' but no 'in' instruction.
So something is not right either way.
On Sat, Mar 27, 2010 at 10:02 PM, David Brown wrote:
Joerg Wunsch wrote:
David
Szikra Istvan wrote:
/**
Category: miss optimization
affects: avr-gcc 4.3.3
Size optimization inline check generates bigger code
I get this warning: "inlining failed in call to 'extIntSetEnable':
optimizing for size and code size would grow"
NO! It would not!
Is this a known bug, or something t
Joerg Wunsch wrote:
David Brown wrote:
Evaluating the result of "p |= BIT(b)" means carrying out the
or-assign, then reading the value of p and returning it.
You're right, I stand corrected.
That's certainly how /I/ interpret the way volatile works in such cases.
Szikra Istvan wrote:
/**
Category: optimization miss
affects: avr-gcc 4.x.x
'?:' operator bit write generates unnecessary 'in' instruction in
inline functions.
I had a problem with my bit set macro and inline functions (among
other things). Though I found a workaround, I thought I'll share my
ex
1 - 100 of 313 matches
Mail list logo
