-
Using -fno-split-wide-types is not a complete solution, for two reasons. One is that the default for optimised code is -fsplit-wide-types, and the other is that for some code the splitting is helpful (that's why it's the default for optimised code). If the conclusion is that split-wide-types harms more than it helps, and it is not possible or practical to fix code sequences such as this while...
2009-11-24 14:37:37 UTC by davidbrown
-
This problem is solved when using -fno-split-wide-types.
2009-11-24 11:57:29 UTC by wutje
-
arcanum changed the public information on the WinAVR project.
2009-11-23 23:07:18 UTC by arcanum
-
Functions that do arithmetic on an expression, then return a 16-bit value, use an extra register pair r18:r19 for the arithmetic instead of using r24:r25 directly. This leads to extra register moves, and limits other optimisations (such as disallowing the use of adiw and similar instructions). This is a regression since gcc 4.2.2 in earlier WinAVR releases, and applies to gcc 4.3.x in various...
2009-11-23 22:11:56 UTC by davidbrown
-
arcanum committed patchset 32 of module Mfile to the WinAVR CVS repository, changing 1 files.
2009-11-17 03:25:52 UTC by arcanum
-
In AVR-LibC, PRTIM0 is defined as 2 for the Attiny13A and PRSPI is defined as 1, but according to the Atmel documentation, PRTIM0 is 1 and there's no PRSPI for that chip.
The values may be incorrect for other processors as well, but I haven't checked.
2009-11-16 22:46:34 UTC by adammil
-
arcanum committed patchset 31 of module Mfile to the WinAVR CVS repository, changing 1 files.
2009-11-16 13:37:23 UTC by arcanum
-
In avr-as, the modifiers like lo8(), hi8(), etc. provide an 8-bit value representing a portion of a relocatable expression. While these work correctly when used as an operand for an immediate mode instruction like ldi r24, lo8(foo), using them in a .byte directive results in an error indicating "Error: illegal relocation size: 1".
.section .text
.byte pm_lo8(bar), 0
ldi r24...
2009-11-13 00:56:37 UTC by dkinzer
-
The include file for the atmega16m1, atmega32m1, and atmega64m1 devices is missing a bit in the definition for the DACON register. In Win-AVR version 20090313, the iom[16,32,64]m1.h includes have this register definition:
#define DACON _SFR_MEM8(0x90)
#define DAEN 0
#define DALA 2
#define DATS0 4
#define DATS1 5
#define DATS2 6
#define DAATE 7
The correct definition is this (DAOE...
2009-11-09 21:38:06 UTC by ckthorp
-
Its the definition of the actual IOs themselves for setting an output bin high or low (ie NOT the data direction, and NOT the PINs)
On the ATMega8, ATMega168, ATMega32, ATMega640 the individual bits for port B are defined as PB0, PB1, PB2 etc.
But on the ATMega32P they are defined as: PORTB0, PORTB1, PORTB2 etc.
2009-11-02 14:48:19 UTC by clivewebster
