avr-gcc: New Features?

Go To Last Post
87 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChaunceyGardiner wrote:
There is something to this, though - making double a 64-bit data type will most likely carry a performance penalty for some expressions, such as:
int i;
int j = i / 1.234;

No, it won't if it is properly implemented :-)

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
ChaunceyGardiner wrote:
There is something to this, though - making double a 64-bit data type will most likely carry a performance penalty for some expressions, such as:
int i;
int j = i / 1.234;

No, it won't if it is properly implemented :-)

Good grief.

Are you saying that a constant in the form N.N is not a double, or that the compiler will treat that expression as a float division even if the constant is a double?

How about this:

float f;
f = f / 1.234;

There must be a penalty somewhere in this neighborhood. Maybe it has to involve a constant that can't be properly dealt with as a float ?

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 32-bit doubles are hard-coded in avr.h and don't care for -fno-short-double. Therefore, double support would just

#define DOUBLE_TYPE_SIZE (flag_short_double ? 32 : 64)
#define LONG_DOUBLE_TYPE_SIZE (flag_short_double ? 32 : 64)

together with setting -fshort-double as the default.

64-bit doubles would be an ABI change and therefore the default for sizeof (double) should still be 4.

Users who need 64-bit would use -fno-short-double.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB,

You just confirmed that I am right about the performance penalty associated with 64-bit double, including expressions like one or two of those I posted above.

I am glad to see that 64-bit double will be optional. That was my main concern:

ChaunceyGardiner wrote:
Cliff suggested 64-bit double further up in this thread. I think it is a good idea if (and only if) it can be an option.

One problem with just implementing double as a 64-bit type is promotion rules and library interfaces.

One related question remains, and that is how the standard libraries will deal with this option.

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-fno-short-double must be promoted to a multilib option (just like -mmcu= or -msp8).

Headers might need adjustment per __SIZEOF_DOUBLE__ or builtin_types_compatible, and of course the standard libraries must adopt libgcc's multilib layout.

avr-libc does not automatically adopt multilib layout from gcc, and even if it will not help because the underlying routines (printf, sin, atanh, etc.) are missing.

Conclusion is that you use newlib as the LibC of your choice. newlib supports -fshort-double as multilib option and the headers contain proper prototypes (avr-libc contains stuff like #define sinf sin).

The primary focus is not performance, it's ABI compliance and stability.

The performance, however, will be so bad that nobody will use it.

If people really need higher precision a wayout would have been long long accum (1 sign, 16 integral bis and 47 fractional bits). But as I just learned, nobody will use fixed-point either (the long long accum is a GCC extension and not even mentioned in the non-standard TR18037).

Next conclusion is to switch to a reasonable platform for your project: ARM, PowerPC VLE, Renesas V850, Infineon XC2000, TI MSP430, Atmel AVR32, Infineon TriCore, Microchip PIC32, embedded MIPS, National CompactRISC, Renesas H8, ...

There are so much choices that are so much more reasonable if double is inevitable in your design...

Back to AVR. Even if only some lines have to be changes in avr-gcc this won't go into 4.8. It's too intrusive for the current stage.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Skimming the proposals, I get the following summary:

Issues that are too com(P)lex for me, (N)ot AVR-specific, realm of Lib(C) / (C)rt0 / (B)inutils, or are already e(X)isting, or (Q)estionable, or not (F)easible, or conflict with the (S)tandard and need GCC-extension that is non-compliant

  • Vtables in flash (N, P)
  • Inline asm + volatile (N, X)
  • Better warnings (N, X)
  • Squish up the vector table (B, C, X as patch)
  • 64bit double (Q)
  • Better debugging Info (N, X)
  • Ternary operator generate the same code as if/else (N, P, Q)
  • Better control of loop unrolling (N, X, P)
  • Endian attribute (F), you can use __builtin_bswap32
  • Put string literals in flash (S: TR18037 says literals are in generic space) for code like follows:
      const __flash char* const __flash names[] = { "A", B" };
  • Linker-level type checking (N, P, X (LTO), realm of lint or similar static source analyzers)
  • Access carry from C (F, Q), GCC supports rotate if you mean that.
  • Code factoring / reverse inlining (N, P)

Some remarks on the above list:

From time to time I am contributing to the AVR backend of GCC in my spare time. The AVR back is a vanishing small part of the GCC code base (currently 32000 LOC in 37 files) which is far less than 1% of GCC's code base. Almost any part of GCC is complex, highly non-trivial, mined with technical debts and legacy structures, etc.

Therefore, I focus on the AVR part which has no impact or side effects on other architectures, the front ends the optimization passes, general structure of GCC, etc. And I am focusing on avr-gcc (not Binutils, not AVR-Libc, not avr-g++).

This limits the number and complexity of features I am considering as appropriate to be handled in my spare time. And what to add to the compiler is also a matter of preference and personal interest. (Anyone who is unhappy with these preferences can contribute to the project and put more emphasis on his / her personal preferences.)

The eXisting marker above means that the feature, or very similar feature, is already present in GCC.

For example, adding a #pragma to force / inhibit a particular transformation, has almost zero chance to go into GCC: It would result in hundreds of #pragma for every imaginable optimization / transformation.

GCC's approach is to keep the code clean and provide command line switches and paramaters to fine-tune the optimizers. Yor really read and tried all the command options and params GCC provides for the unroll tuning you are trying to achieve? You won't find your exact requirement, but very likely you find one that's very close.

For features like warnings, where you think they can be improved, I'd propose that you file a problem report in GCC's bugzilla or ask in the gcc-help@ mailing lists. If your are really interested in the feature, there is no way around getting in touch with the GCC developers. Maybe you found a bug or shortcoming, maybe you misunderstood something, maybe it is for historical reasons, maybe it is too complex or nobody has his / her focus on the matter.

In any case, make a proper problem report: Say what compiler version you are using, what command switches, what source code, and what diagnostics it produces or is intended (not) to produce. Stuff like "AVR Studio" means nothing to the general GCC developer, so does #include , PORTB or #include "lcd.h". Make your report self-contained, don't write "please read to following threads here and there to find code and understand the problem". Provide the technical information and read the bug reporting instructions. You can also speed up te matter by trying to find a small test case.

Make sure you are using a supported version of GCC (at least 4.6, in 1 or 2 months it will be at least 4.7). In the case it is not AVR-specific, you can try to reproduce it on a primary (very important) platform like x86, PowerPC or ARM. Problems with ternary (what the fuck is...?) platforms like AVR are automatically low priority and get less attention.

Attitudes like

    "I will only report if there is guarantee that it will be fixed."
calling others morons or
    "I won't waste more than 2 minutes on filing a report."
won't help. If that's your intention, don't report the problem at all. It will just be noise and frustrating for both sides.

Coming back to the feature list, the following points are remaining:

Fixed-point Support

    Said to be useless, too exotic. Makes me really wonder because I see frequently complaints about code consumption for the (assembler-optimized) float routines.

    I see the point that it is non-standard. Most applications that need fixed-points have their own, home-brew, more flexible, standard-compliant fixed-points implementatios.

    At least a single user would find it helpful, but nobody uses fixed points which are available in wide-spread avr-gcc 4.6 from Atmel Studio.

    So either remove the scrap and clean up the compiler, or bring it to a reasonable implementation. You made me really unsure...

#pragma GCC push_options / push_options
    Actually not AVR-specific, but the general GCC machinery is already there. Just some AVR hooks have to be implemented. I will have a look. Meanwhile you can use option pragma and attribute.
64-Bit double
    Some ansers and thoughts are above. I see the "Standard C" point and the precision argument. But I cannot imagine anybody will really use this. Will this really be preferred over a pixed-point implementation? Who will provide a reasonable implementation of the base arithmetic?

    The open coded C arithmetic in libgcc will have a bloat factor of (estimated) 3 to 10, compared to an assembler implementation maybe even higher.

    Will AVR-LibC implement double? Or will you use newlib?

Better code size
    It's obvious how good code looks like, but that does not mean suboptimal code is easy to fix.

    Try a current version of the compiler, maybe it's already fixed. Some known code size problems are hard to fix. If the problem is not already reported, file a report (see above) so that the issue is known to the developers, won't be forgotten and there is a test case that can produce the artifact. Set "target" to "avr".

    For some base arithmetic like shifts I thought about a fster implementation even at -Os, but that might code some more instructions per shift. Shift loops are very slow, but shifts are very basic in programming and not uncommon.

    I don't know if it is wide to be more catholic than the pope with code size vs. speed at -Os. If one or two instruction more cost you several hundreds of cycles, what should be done? Be overly strict or use a reasonable implementation at the expense of 1 or 2 instructions more?

    This is also hard because there are no benchmarks — neither for code size nor for speed — for avr-gcc. Official banchmarks like Autobench, Coremark, Spec2000 etc. oviously make absolutely no sense. Same for the programs in the GCC test suite.

Finally, I am ashonished about some missing points like "more device support". So it turned out that the current compiler covers a reasonable subset (~180 or so) of the hundreds of AVR derivates.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The AVR back is a vanishing small part of the GCC code base (currently 32000 LOC in 37 files)

Ah. Would you be willing to explain, in a way that might be understandable to someone who flunked their compiler class 30+ years ago, what kind of functionality is located in the "back end" and how it is interfaced to?

Quote:
"more device support"

I wouldn't mind seeing a more "modular" method of specifying a target; sort of like the 68000 series where you dig out appropriate values for -mno-bit-fields and similar instead of having a separate name for every possible chip. It's a bit silly for avr-gcc to have separate switches for m168, m168p, m328, m328p, AT THE COMPILER LEVEL when they're pretty much the same except for memory size, isn't it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
64-Bit double
    Some ansers and thoughts are above. I see the "Standard C" point and the precision argument. But I cannot imagine anybody will really use this. Will this really be preferred over a pixed-point implementation? Who will provide a reasonable implementation of the base arithmetic?

    The open coded C arithmetic in libgcc will have a bloat factor of (estimated) 3 to 10, compared to an assembler implementation maybe even higher.

    Will AVR-LibC implement double? Or will you use newlib?

It seems to me that fp could be speeded up if avr-gcc used base 0x100.
Standard C compliance would require at least a 5 byte float.
Double would only require 8 bytes for standard C compliance.
Would that be too big a change?
Is there something in gcc that requires sizeof(double) be a multiple of sizeof(float)?
Would the reduced precision on doubles be a nuisance?
Would a 9 or 10 byte double be better with base 0x100.
In any case, a major rewriting of libraries would be required.

On processors without hardware multiply, one might as well use 4 and 8 bytes.
Using base 0x100 won't offer much, if any, speed up.
Would that distinction cause a problem?

Iluvatar is the better part of Valar.

Last Edited: Sun. Jan 27, 2013 - 12:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Ah. Would you be willing to explain, in a way that might be understandable to someone who flunked their compiler class 30+ years ago, what kind of functionality is located in the "back end" and how it is interfaced to?
IIRC there are in principle, several representations of the code:
source
preprocessor output, much like source
one or more intermediate representations that are supposed to be source- and target-language agnostic
one or more intermediate representations for the target
target assembly

I think the back end refers to the last two.
Others can be more specific about the "one or more"s.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
The AVR back is a vanishing small part of the GCC code base (currently 32000 LOC in 37 files)
Ah. Would you be willing to explain, in a way that might be understandable to someone who flunked their compiler class 30+ years ago, what kind of functionality is located in the "back end" and how it is interfaced to?
Technically, the avr BE is located in 2 subdirectories that describe GCC and libgcc parts:

• gcc/config/avr/
• libgcc/config/avr/

There are few more parts (not mentioned above) that deal with making the avr BE known to configure, e.g. add configure --target=avr support, documentation, AVR-specific tests.

Compiling a program like

    int main() { return 0; }
the first what the compiler proper sees and reads is the preprocessed i-File. The syntax of the sample code is C, thus it does not matter at all for which architecture this is compiled.

The first, important intermediate representation (IR) is tree-SSA. It's target independent but the optimizers may take into account --param parameters and -f or -O command options to scale the passes that deal with tree-SSA.

The first ~150 of ~230 passes deal with this IR. After that, the code is lowered to RTL (register transfer language) which is basically an algebraic, lisp-like representation of target instructions.

The remaining ~80 passes deal with RTL. When the IR has to be lowered to RTL, the program has to be represented by the given building blocks: The insns written in RTL. This step is the analogon to an assembler programmer who has to construct his algorithm out of a given set of building blocks (the assembler instructions).

The smaller the pass number is, the more will the code look like the original C code (i-file). And the higher the pass number is, the more will it look like the produced assembler code (s-file).

GCC is a retargetable compiler and you can write a new backend to support your favorite architecture. You can support your own FPGA instruction set design if you like and have all of GCC's option passing and optimization and library framework available.

The target specific bits are described in the BE:

  • ABI bits like: sizeof (int), sizeof (void*), endianess, register and frame layout, parameter passing convention, exception handling, object format (ELF), section capabilities (common, weak, switchable, ...), data alignments, bitfield layout, signedness of char, debugging format, ...
  • target-specific additions: attributes like progmem and signal, pragmas (none), address spaces like __flash and __memx, constraints like "e", "a" and "Ynn", builtins like __builtin_avr_sei, builtin macros like __AVR_ARCH__, inline asm print modifiers like %a, %i, %r, %A, %~, ...
  • valid options (-m and -mno-), option transformations performed by the compiler driver
  • target-specific instructions and supported addressing modes
  • optimizations: instruction combining, instruction scheduling, splitting of complex instructions, peephole optimizations, ... and costs for specific RTL constructs used by other optimization passes.
  • target-specific support code in libgcc that is too complex to emit it inline
  • makefile snippets to support --target=avr-rtems, --with-avrlibc, building special avr-gcc or libgcc objects, scripts to generate makefiles or documentation (too keep in sync the insanely high number of derivatives), configure parts, generic makefile parts, ...
  • target specific tests in the test suite
  • many things I forgot or just don't know or remember
  • And of course, printing the insns as assembler code
The starting point of the backend that defines many of the ABI parts is avr.h. A minimal backend would consist of 5 files or so.

An example for a simple instruction in the avr.md machine description is 16-bit subtraction. The RTL optimizers just use the meta informations and RTL representation. The instruction output for 16-bit subtract is irrelevant and effectively an agnostic printf to the s-file. It might take advantage of mini-optimizations, of course.

This structure makes it easy to add a new target architecture to GCC: For a first, sketchy implementation for an architecture an experienced GCC guy would need around 2-3 month. The "easy" is compared to writing a complete compiler and from scratch.

However, this structure also limits what a backend can achive. Leaving the backend's sandbox, changes are no more target specific and will affect all other backends, too.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow.

SprinterSB wrote:
However, this structure also limits what a backend can achive. Leaving the backend's sandbox, changes are no more target specific and will affect all other backends, too.
Maybe one of the reasons for the existence of LLVM.
There's some talk about avr-llvm moving to Atmel Spaces.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With LLVM it's the same: If you change the inline machinery (not only costs or heuristics), any target is affected. Similar for the C front etc. YOu are limited to hooks or methods you can override. Correct me if I'am wrong.

It's also possible in GCC to write complete, target-specific passes. But it is constly w.r.t to maintenance and development. Nobody has done this so far.

Yet another way to hook in is plugins like DragonEgg. You don't even need to change the compiler sources for that.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
"more device support"
I wouldn't mind seeing a more "modular" method of specifying a target; sort of like the 68000 series where you dig out appropriate values for -mno-bit-fields and similar instead of having a separate name for every possible chip. It's a bit silly for avr-gcc to have separate switches for m168, m168p, m328, m328p, AT THE COMPILER LEVEL when they're pretty much the same except for memory size, isn't it?
100% ACK from my side.

But I was told that the "68000 approch" is too complicated for our users, that they won't understand it, won't use it, and only 1-click solutions will be used.

Nonetheless I wrote some lines in the Wiki and filed 2 extension requests.

The "modular" approach means that Binutils have to learn the instruction set: PR15043

PR15043 wrote:
The avr tools currently support around 200 devices and there are more, unsupported devices.

It makes hardly any sense to add a -mmcu=device switch for each and every target: For binutils, it's enough to know the instruction set architecture (ISA) to assemble for.

Thus, command line switches like -mdes and -matomic could greatly reduce the time until new devices are supported, because the compiler need not to wait until respective support in binutils is available:

The compiler could just call avr-as with -mmcu=core -mdes if it knows that the device supports the DES instruction and with -mmcu=core -mno-des, otherwise.

The options shall work as follows:

With -mdes, the assembler will accept and assemble the DES instruction. With -mno-des, the assembler will issue an "unknown instruction" error.

If a device is specified with -mmcu= then the assembler knows the right setting for -m[no-]des and uses it, provided it is not explicitly overridden by -m[no-]des. Alternatively, -m[no-]des could be ignored in that case.

If a core like avr4 definitely does not support DES instruction, the option is ignored and the behavior the same as it would be with -mno-des.

Similar for -m[no-]atomics and the instructions XCH, LAC, LAS, LAT.


This means that
  1. avr-gcc must wait until binutils support -mdes and -matomic or whatever if it wants to use these options with subtools.
  2. The information is currently hidden deep inside Atmel (I won#T downloat and read hundreds of data sheets, sorry) and it still applies what I wrote in avr-gcc Features: Atomic operations.
  3. A framework has to be designed that uses the device information. It's obvious that the information must be provided outside the compiler — if it was inside, there was nothing to do...

    There was the proposal to supply an external file that GCC would read and evaluate. This is a bad idea, IMO, because all what the compiler driver (avr-gcc) would to is to call the tools with specific options: compiler proper, assembler, linker.

    Conclusion is to call the compiler with these options, e.g. provode a Makefile snip and is $(MY_MMCU) instead of -mmcu=my_mmcu.

  4. The user will need avr/io.h and crtmydevice.o from gcrt1.S This is the job of AVR-LibC, filed as #38125
    #38125 wrote:
    The assembler source code of the startup code ./crt1/gcrt1.S could be added to the installation.

    This makes it easier for the user to adjust the startup code and / or compiler it for devices that are not yet supported by avr-gcc as lined out in avr-gcc Wiki: Supporting "unsupported" Devices.

    The onyl dependency should be #include .

    Other dependencies like macros.inc and sectionname.h can easily be avoided altogether, which makes using gcrt1.S more straigh forward.

The notes in Supporting "unsupported" Devices explain in detail how to get support for the device of your choice.
Supporting "unsupported" Devices wrote:
avr-gcc and avr-as support the -mmcu=device command line option to generate code for a specific device. Currently (2012), there are more than 200 known AVR devices and the hardware vendor keeps releasing new devices. If you need support for such a device and don't want to rebuild the tools, you can
  1. Sit and wait until support for your -mmcu=device is added to the tools.
  2. Use appropriate command line options to compile for your favorite device.
Approach 1 is comfortable but slow. Lazy developers that don't care for time-to-market will use it.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ideas:
Add __eeprom keyword similar to __flash, or ideally release ability to add custom sections with user-defined functions read and write. For example __eeprom_i2c or __flash_at45 sections.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

demiurg_spb wrote:
Add __eeprom keyword similar to __flash, or ideally release ability to add custom sections with user-defined functions read and write. For example __eeprom_i2c or __flash_at45 sections.
A __flash qualifier seems reasonable.

Embedded C knows two different kinds of address space qualifiers:

  1. Intrinsic named address spaces like __flash.
  2. Application-defined address spaces that work entirely on application level and define (inline) functions to read / write one byte that are used when a byte is to be read / written from such a space.
GCC currently provides the framework for the intrinsic address spaces. It does not support application-defined spaces.

The way how the eeprom must be read / written is too complicated to be appropriate for an intrinsic space. There is too much hardware and SFR stuff involved that I would not integrate into the compiler.

I already decided that I'll give the fixed-point support a roundup. It makes no sense to remove it because it might not be used frequently. It makes the backend more complicated, but if it would destabilize the backend in an unappropriate way, I would not have added / ported it in the first place.

Almost all of the features mentioned in this thread are far beyond anything I will consider. Rounding up fixed-point is one reasonable feature (for its complexity and my time frame, AVR-specific, not already implemented or inappropriate, ...)

This forum was a really bad place to ask; next time I will use the mailing lists.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The way how the eeprom must be read / written is too complicated to be appropriate for an intrinsic space. There is too much hardware and SFR stuff involved that I would not integrate into the compiler.

Though this is exactly what competing compilers like CodeVision do. You can say:

eeprom int foo = 37;
int bar;

bar = foo;

and it does indeed generate EEAR/EEDR code to read foo.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anybody who feels inclined to add this to GCC is invited to propose a working patch. I won't, it's insane to hack more than 500 SFR definitions into the compiler.

Anybody who wants to implement application-defined address spaces into the compiler can do if he likes. I won't; I beyond my time frame.

Besides that, such a feature is diametral to getting the tools more independent and provide easier device support as outlined by Bill in https://www.avrfreaks.net/index.p...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Anybody who feels inclined to add this to GCC is invited to propose a working patch. I won't, it's insane to hack more than 500 SFR definitions into the compiler.

No doubt I'm oversimplifying things, but couldn't this just map the reads and writes to a known function name that avr-libc could then map to? The EEPROM code is already in avr-libc, it just needs to be automatically wired up.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read eeprom.h to see why this cannot work.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How is it with Joergs patches now ?
Are they needed now ?
Could they be built in so no patching ?
What did they do anyway ?

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are "Jörg's patches"?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What are "Jörg's patches"?

They hang out around here.

http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/avr-gcc/files/

Bingos scripts, the sticky at the top of this section, explain how to use them.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These patches are for 4.5.x and completely outdated.

If you need them for 4.8, you'll have to throw them away and reimplement them.

Some stuff like PR46779 and PR18145 are my work and already integrated, for example Jörg backported PR46779 to 4.5 before it was upstrem to 4.5.

Fixed-point support is based on Sean's work but quite different now w.r.t its details.

Nobody ever proposed Tiny10 support, and IMO makes no sense for 4.8 which will be released before very long (~ 1-2 months or so). Typical approach is that work is dublicated, i.e. added to Atmel port and then reimplmented again for official support.

The device support is a mess. I lost track over the > 200 devices, I gave up on that.

OS_main and OS_task are upsteam since 4.7, after I found a documentation.

NVM attribute is not supported because there is no documentation. Adding undocumented stuff is pointless.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another future request:
Add warning or error in case of:

extern const char* p;
extern const char __flash* pf;
extern const char x;
extern const char __flash xf;

p  = pf;  // error
pf = p;   // error
pf = &x;  // error
p  = &xf; // error

like IAR does.
I think, this is very useful...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

demiurg_spb wrote:

extern const char* p;
extern const char __flash* pf;
extern const char x;
extern const char __flash xf;

p  = pf;  // error
pf = p;   // error
pf = &x;  // error
p  = &xf; // error


That throws plenty or errors and warnings...
 p  = pf;  // error 
 ^
:6:1: warning: type defaults to 'int' in declaration of 'p' [enabled by default]
:6:1: error: conflicting types for 'p'
:1:20: note: previous declaration of 'p' was here
 extern const char* p; 
                    ^
:6:5: warning: initialization makes integer from pointer without a cast [enabled by default]
 p  = pf;  // error 
     ^
:6:1: error: initializer element is not constant
 p  = pf;  // error 
 ^
:7:1: warning: data definition has no type or storage class [enabled by default]
 pf = p;   // error 
 ^
:7:1: warning: type defaults to 'int' in declaration of 'pf' [enabled by default]
:7:1: error: conflicting types for 'pf'
:2:28: note: previous declaration of 'pf' was here
 extern const char __flash* pf; 
                            ^
:7:1: error: initializer element is not constant
 pf = p;   // error 
 ^
:8:1: warning: data definition has no type or storage class [enabled by default]
 pf = &x;  // error 
 ^
:8:1: warning: type defaults to 'int' in declaration of 'pf' [enabled by default]
:8:1: error: conflicting types for 'pf'
:2:28: note: previous declaration of 'pf' was here
 extern const char __flash* pf; 
                            ^
:8:6: warning: initialization makes integer from pointer without a cast [enabled by default]
 pf = &x;  // error 
      ^
:9:1: warning: data definition has no type or storage class [enabled by default]
 p  = &xf; // error
 ^
:9:1: warning: type defaults to 'int' in declaration of 'p' [enabled by default]
:9:1: error: conflicting types for 'p'
:1:20: note: previous declaration of 'p' was here
 extern const char* p; 
                    ^
:9:5: warning: initialization makes integer from pointer without a cast [enabled by default]
 p  = &xf; // error

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
That throws plenty or errors and warnings...

Sorry, it was incorrect example..
That's right:

int main(void)
{
	static const char __flash strf[] = "const flash str";
	static const char         str[]  = "const ram str";

	const char*         p = strf;  // error
	const char __flash* pf = str;  // error

	p = pf;                        // error
	pf = p;                        // error

	return 0;
}

avr-gcc-4.7.2 -S -mmcu=atmega8 -Os -pedantic -Wall -Wextra -std=gnu99 main.c

And we have no warnings and no errors...

http://gcc.gnu.org/bugzilla/show...
Thx to Georg-Johann Lay!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another future request based on http://gcc.gnu.org/ml/gcc-help/2007-07/msg00342.html:
Add file like in avr32 and arm toolchains.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see need for a header like because endian.h is not a standardized name.

__FOO, however, starts with __ and is thus matter of the implementation, not of the application. This means avr-gcc may implemenet __BIG_ENDIAN, __PDP_ENDIAN, __IEEE_BIG_ENDIAN ans similar to whatever is likes.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank You for your answer!
I know that is not standardized unit.
And I see all endian-related gcc symbols...

echo "" | avr-gcc -E -dM -x c - | sort

#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__    4321
#define __ORDER_PDP_ENDIAN__    3412
#define __BYTE_ORDER__          __ORDER_LITTLE_ENDIAN__

But it is annoying to handle all this stuff for big number of compilers. (gcc armcc iar keil intel ...).
IMHO It's time to standardize ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, then just propose patches to all these great compilers. Posting here is pointless as you know...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my project which uses 160kB flash, >128kB of code and >30kB program data I suffer from two things which should belong to gcc I think.

1. possibility to get return address or even better collect call trace
- this is important for tracing rare errors, e.g. at runtime I can realize in function that some sporadic internal error happend but I am imposible to check call chain, only can check debug logs but offten there is no information need for specific scenario or are not enough verbose at this momemnt..

2. posibility to somehow initialize far pointer at load time, e.g.:

const char pstr_can[] __attribute__((__section__(".progmem_far"))) = "Txt";
uint_farptr_t name = (uint_farptr_t)pstr_can;  

throw error: error: initializer element is not constant

regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can use avr-gcc 4.7, binutils 2.23 and the 24-bit pointers from the __memx address space.

You can get the return address from __builtin_return_address(0). 0 is the obly supported level. Higher levels would require ABI change and a new frame layout.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Sat. Jun 1, 2013 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

About __memx, I updated to binutils 2.23 (gcc was 4.7.2) and initialization seems to works now but not sure if this is usable for me because by default __memx variables are placed into .progmem.data which is located at beginning of flash.
Moving .progmem.data to end of flash is not a case bcs will move others variables.
Code below is not working correctly I think:

const __memx char pstr_tst[] __attribute__((__section__("._progmem_far"))) = "Tst";

attribute progmem_far is ignored and variable is placed at .progmem.data, is this ok or bug ?

Is it possible somehow to change __memx object placement from progmem.data to something different ?

or distinguish __memx objects at linker script ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can use 4.7.3. __memx is allocated to .progmemx.data. This section can be picked up in the linker script. See GCC feature PR55897.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

About 64-bit floating point.

What about to make 32-bit float, 32-bit double and 64-bit long double?
This will not change an existing code, as of promotion rule for functions with variable number of arguments is from float to double.
But it will make possible to use 64-bit floating point when it is really necessary.
In internet there are some 64-bit floating point libraries, so as people wrote them they was necessary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I am writing in the wrong topic, but I hope that Joerg read this message.

With the advent of 24-bit integer data-types, it would be logical implemented in the library stdlib:
type div24_t
and functions div24 (similar div and ldiv).
Thx!

Pages