avr-gcc: New Features?

Go To Last Post
87 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What would be new, reasonable features for avr-gcc¹?

Features that

  1. Are useful and will actually be used
  2. Don't conflict with the standard
¹ When I write avr-gcc, I mean avr-gcc from gcc.gnu.org (and not avr-g++, Atmel Studio, avr-libc, ...)

avrfreaks does not support Opera. Profile inactive.

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

ahhh. not c++. I was going to raise the old point about vtables in flash....

I am sure that there are some improvements but I think it is extraordinarily good already.

regards
Greg

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

I don't thinks he asks for specific recommendations, if I understand correctly the question is basically if it is OK to implement useful new features that may conflict with the standard.

Alex

EDIT:
I have misinterpreted the question, he is asking for new features ideas that don't conflict with the standard and are useful.

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

Last Edited: Sun. Jan 20, 2013 - 01:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's for recommendations and "what's missing".

avrfreaks does not support Opera. Profile inactive.

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

More of Embedded C.
IIRC, avr-gcc 4.8 will (has) restore(d) fixed point; is that correct?
Atomic operations.

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

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

Perhaps the ability to squish up the vector table a little - an option to discard any sections of the vector table that aren't used so that normal program data can occupy them, which would reduce XMEGA application footprint. Or perhaps an option to use all unused entries in the vector table for normal data, so that you still save space even if you hook the first and last vector entries.

- Dean :twisted:

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

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

I would like to see a lot more warnings. We get away with way too much.

The simplest example I can think of is

int i;
char c = i;

Sid

Life... is a state of mind

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

64bit double perhaps?

I don't say this because it's a feature I'm desperate to use on an 8bit micro but simply because it's a tick in the box on the specification list and has previously been cited as a reason why avr-gcc isn't as good as some competing compilers.

The implementation wouldn't have to be that efficient (just accurate) because let's face it if you use float / double you probably aren't that fussed about efficiency. ;-)

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

Perhaps a mechanism for marking in-line assembly so that it will not be reordered with respect to volatile accesses.
Perhaps by putting volatile in the clobber list.
memory clobber is a bit of a bludgeon.

For that matter, it might be good to be able to "pass" a pointer into in-line assembly and tell the compiler that only its target might be clobbered.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

It would be wonderful if values of variables could be inspected during a debugging session. In my experience, this works less than half the time. I don't know whether AStudio's debugger or gcc's debug output is to blame, but from the fact that this situation didn't seem to improve going from AStudio4 to AStudio6, I tend to suspect that the compiler output files don't contain enough supplimental debugging information to let a debugger work.

And, yes, I'm talking about debugging optimized code (you know; the kind you MUST build if you want _delayXs() and perhaps other features to work). I know this is pretty arrogant of me, especially as I haven't the time to construct my own tools, but it seems to me that if *I* can figure out what's in the 16-bit variable gleemFleeble by "simply" opening a Disassembler window and reverse-engineering the code to deduce which register pair got assigned, then maybe the compiler that decided which registers to use should have mentioned that to the debugger.

I can imagine that better symbolic debug hints are probably hugely difficult to generate, but I think they'd be hugely appreciated, too.

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

clawson wrote:
64bit double perhaps?

My memory is a bit rusty, but... Isn't there some compiler and/or library stuff that uses double ? If so, there would be a performance penalty associated with expanding double to 64 bits.

Sid

Life... is a state of mind

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

If it hasn't been fixed already, I would like the ternary operator to generate the same code as if/else where applicable.

We had a long discussion about that a couple of months ago - one method turned out better than the other in all the cases mentioned in that discussion, but I have seen the opposite as well. So there is room for improvement of both.

I would also like to see improved nested inlining. I find myself duplicating code because nested inlining generates bigger code than doing the same thing in two inlined functions.

I am willing to spend time on coming up with cases that demonstrate the problems I describe in this thread - but I would like to know that they are likely to be addressed if I do. (That is, I don't want to spend time on it if nobody is going to do anything about it anyway.)

Sid

Life... is a state of mind

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

I need better optimisation with LTO in next situation:

typedef struct
{
	struct
	{
		volatile uint8_t* const pUDR;          
		volatile uint8_t* const pUBRRL;        
		volatile uint8_t* const pUBRRH;        
		volatile uint8_t* const pUCSRA;        
		volatile uint8_t* const pUCSRB;
		volatile uint8_t* const pUCSRC;        
	} io;

	struct
	{
		uint8_t                 cbr;           
		uint8_t                 byte_len;      
		uint8_t                 parity;        
		uint8_t                 stop_bits;     
	} config;

	struct
	{
		fifo_t                  tx;
		fifo_t                  rx;
	} fifo;

	struct
	{
		on_txc_callback_t       on_txc;        
		on_rxc_callback_t       on_rxc;        
		on_udre_callback_t      on_udre;       
	} callback;
	
	owner_t                     owner;
	...
} rs485_handle_t;

//=====================================================
static void rs485_txc_isr(rs485_handle_t* const rs)
{
	rs485_txen_off(rs);

	*rs->io.pUCSRB &= (uint8_t)~( (1U<<TXEN)
	                             |(1U<<TXCIE)
	                             |(1U<<UDRIE));

	if (rs->callback.on_txc)  rs->callback.on_txc(rs->owner);
}

It would be nice to have full unroll struct_field reference. Often I have only one used USART in MCU... And I steel (avr-gcc-4.7.2 + all new optimizetion options) see ugly Z->SFR sentence after compilation...

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

It would be nice to have ENDIAN attribute:

uint32_t BIG_ENDIAN x;

uint32_t y = x; // swap bytes on the fly

x++; // perform right math 

if (x>y)  {...}

It would be nice to enable effect of pack and allign pragmas and attributes.

Solve situation with

const __flash char* const __flash names[] = {"AAA","BBB","CCC"};

and put all together in flash (like IAR do).

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

abcminiuser wrote:
Perhaps the ability to squish up the vector table a little
- Dean :twisted:

I had a hack for the linker that does something like that - time to dust it up and send it out to the mailing list, I guess. See https://www.avrfreaks.net/index.p...

Regards

Senthil

 

blog | website

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

Not sure what the standards say about this but here's an area that could be improved.

a.cpp:
int a_value;

b.cpp:
extern double a_value;
void atest()
{
	printf("percent-f\n",a_value);
}

This compiles without error despite the variable a_value having been defined with two different types. I presume then GCC C++ doesn't put type information in the object files and therefore the linker has no way of detecting the issue. I tested this on another popular (non-AVR) compiler and it refused to link.

C: i = "told you so";

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

This is a job for lint (or similar static source analysis). You can also try -fno-common or LTO (-flto). With LTO, you'll have global type information.

avrfreaks does not support Opera. Profile inactive.

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

Quote:
This is a job for lint
OK. FYI -fno-common appeared to have no effect. -flto caused:

cc1plus.exe: error: unrecognized command line option "-flto"

I have GNU C++ (WinAVR 20100110) version 4.3.3 (avr)

C: i = "told you so";

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

Try a current version of the compiler, for example 4.7.2. You can read the GCC release notes to see when what feature went in.

avrfreaks does not support Opera. Profile inactive.

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

Oooh - I've always, always wanted a pragma/attribute to unroll a loop that has a constant number of iterations. See the code here:

https://github.com/abcminiuser/l...

I have to duplicate the code, so that I don't incur the loop overhead. It would be nice to write this as:

for (uint8_t i = 0; i < 16; i++) __attribute__((unroll(1)))
    Dataflash_SendByte(Endpoint_Read_8());

And have it unroll into a smaller number of effectively copy-pasted version of the loop body, where the inner loop could be specified (for example "unroll these 64 loops into 32 loops of the body repeated twice").

This way the same code would also work on other compilers as a normal loop with reduced efficiency.

- Dean :twisted:

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

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

You have a test case?

avrfreaks does not support Opera. Profile inactive.

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

A #pragma or something to automatically unroll loops would be nice. E.g.

void foo(char i);

void bar()
{
    #pragma unroll
    for(char i = 0; i < 8; i++)
    {
        foo(i);
    }
}

would generate code similar to

void foo(char i);

void bar()
{
    foo(0);
    foo(1);
    foo(2);
    foo(3);
    foo(4);
    foo(5);
    foo(6);
    foo(7);
}

If the unrolling used compile-time constants it would be even better - that would allow iteration over different template classes in C++.

Sid

Life... is a state of mind

Last Edited: Mon. Jan 21, 2013 - 08:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Test case for what? Basically, I would want this:

void BodyFunction(void)
{
	volatile uint8_t* a = (volatile uint8_t*)0x1234;

	*a++;
}

void MyFunction
{
	// Unroll 64 loops into groups of 2
	for (uint8_t i = 0; i < 64; i++) __attribute__((unrolled(2)))
	{
		BodyFunction();
	}

	// Unroll 64 loops into groups of 4
	for (uint8_t j = 0; j < 64; j++) __attribute__((unrolled(4)))
	{
		BodyFunction();
	}

	// Unroll 64 loops into groups of 8
	for (uint8_t k = 0; k < 64; k++) __attribute__((unrolled(8)))
	{
		BodyFunction();
	}

	// Unroll 64 loops into groups of 10
	for (uint8_t l = 0; l < 64; l++) __attribute__((unrolled(10)))
	{
		BodyFunction();
	}
}

To transform into the equivalent of this:

void BodyFunction(void)
{
	volatile uint8_t* a = (volatile uint8_t*)0x1234;

	*a++;
}

void MyFunction
{
	// Unroll 64 loops into groups of 2
	for (uint8_t i = 0; i < 32; i++)
	{
		BodyFunction();
		BodyFunction();
	}

	// Unroll 64 loops into groups of 4
	for (uint8_t j = 0; j < 16; j++)
	{
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
	}

	// Unroll 64 loops into groups of 8
	for (uint8_t k = 0; k < 8; k++)
	{
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
	}

	// Unroll 64 loops into groups of 10
	for (uint8_t l = 0; l < 6; l++)
	{
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
		BodyFunction();
	}
	for (uint8_t m = 0; m < 4; m++)
	{
		BodyFunction();
	}
}

Note that the last test case can be tricky - but requiring that the unroll amount is an integer division of the loop count would be reasonable.

- Dean :twisted:

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

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

Dean,

I'll be damned. You posted that while I was working out my post - which includes a test case.

Sid

Life... is a state of mind

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

Snap! I got in before you, last post of the previous page :). Seems I'm not crazy, and this isn't such a bad idea after all.

Actually, I'm fairly certain other architectures would love to have this -- especially for architecture dependent speedups since you could adjust the unroll parameter based on the pipeline and branch cost of a particular target.

- Dean :twisted:

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

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

Sure you read about all the optimization options and --param GCC loop optimizers provide? You might get close to the code quality to want to achieve; without the need for language extensions or explicitly cluttering the source with directives. You may want to try the current development version (future 4.8). New optimizations won't go into stable bugfix-only releases like 4.7.

avrfreaks does not support Opera. Profile inactive.

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

> A #pragma or something to automatically unroll loops would be nice. E.g.

void foo(char i);

#pragma GCC push_options
#pragma GCC optimize "-O3"
void bar(void)
{
    for(char i = 0; i < 8; i++)
    {
        foo(i);
    }
}
#pragma GCC pop_options

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

SprinterSB wrote:
You might get close to the code quality to want to achieve; without the need for language extensions or explicitly cluttering the source with directives. You may want to try the current development version (future 4.8). New optimizations won't go into stable bugfix-only releases like 4.7.

I want to "clutter" the source with directives in this case. Preferably a single directive that applies to one loop only.

I want to use -Os for the whole project, but unroll some loops for speed. (And, in the case of C++ templates, this could make a source code loop possible.)

Sid

Life... is a state of mind

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

dl8dtl wrote:
> A #pragma or something to automatically unroll loops would be nice. E.g.

void foo(char i);

#pragma GCC push_options
#pragma GCC optimize "-O3"
void bar(void)
{
    for(char i = 0; i < 8; i++)
    {
        foo(i);
    }
}
#pragma GCC pop_options


I wasn't aware of those pragmas and they seem very useful.

For the case at hand it seems a bit heavy, though. Having the option to only unroll the loop would be better. Changing the optimisation level may have side effects.

Sid

Life... is a state of mind

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

You can use #pragma GCC reset_options to switch back. It's not actually like push / pop, but should be enough to imlement what you want.

avrfreaks does not support Opera. Profile inactive.

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

Quote:
I mean avr-gcc from gcc.gnu.org

Does that actually include anything that anyone has mentioned so far? :-(

Shoot; I'm so far behind I don't even know what's IN the current version.

Is there any way to access the carry bit value? That's one of the things that I see relatively frequently in my asm vs C contemplations; asm can pretty much do 9-bit math, while C can only do 8bit. This is especially annoying when you try to do something that involves rotate (CRC-like calcs, for instance.)

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

@Jörg: ever tried the optimize function attribute?

avrfreaks does not support Opera. Profile inactive.

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

> @Jörg: ever tried the optimize function attribute?

No, but I didn't have much need for optimization switching inside
a compilation unit so far. What I did use though in the past was
to disable just a single warning for the next function (like,
"unused arguments") through similar pragmas.

The entire point of my posting above was to demonstrate that the
functionality that was requested is already available right now.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

FYI, can accomplish that also without attributes:

void f (char c)
{
    (void) c;
}

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define  unroll1(count, x)  if((count) & 1) { x }

#define  unroll3(count, x) unroll1((count) & 1, x)  unroll1((count)/2, x x)
#define  unroll7(count, x) unroll1((count) & 1, x)  unroll3((count)/2, x x)
#define  unrollF(count, x) unroll1((count) & 1, x)  unroll7((count)/2, x x)
#define unroll1F(count, x) unroll1((count) & 1, x)  unrollF((count)/2, x x)
#define unroll3F(count, x) unroll1((count) & 1, x) unroll1F((count)/2, x x)
#define unroll7F(count, x) unroll1((count) & 1, x) unroll3F((count)/2, x x)
#define unrollFF(count, x) unroll1((count) & 1, x) unroll7F((count)/2, x x)

#define   unroll2(count, x)   unroll1((count)/2, x x) unroll1((count & 1, x)
#define   unroll5(count, x)   unroll2((count)/2, x x)  unroll1((count) & 1, x)
#define  unroll10(count, x)   unroll5((count)/2, x x)  unroll1((count) & 1, x)
#define  unroll20(count, x)  unroll10((count)/2, x x)  unroll1((count) & 1, x)
#define  unroll50(count, x)  unroll10((count)/5, x x x x x)  \
                             unroll2((count) mod 5 / 2, x x)   \
                             unroll1((count) mod 5 mod 2, x)
#define unroll100(count, x)  unroll50((count)/2, x x)  unroll1((count) & 1, x)
#define unroll200(count, x) unroll100((count)/2, x x)  unroll1((count) & 1, x)
#define unroll255(count, x)  unrollFF(count, x)

The first parameter is the number of times the second will be executed.
The macros are named after the maximum allowed value of the first parameter.
One doesn't want too many extraneous copies of the second parameter.
Optimization should take care of the ifs.
Of course, optimization, especially -Os might turn them back into loops.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

Hmm. How about 64-bit floating point? Can I claim that that's gcc rather than avr-libc if I'm willing to settle for the standard gcc soft floating point code? (And just how bad IS that, on AVRs?) The tiny avr libm code is swell, but as AVR flash space gets bigger (including XMega), being limited to 32bit precision is getting a bit embarrassing.

If a 64bit FP library remains elusive, how about putting in the infrastructure and defining the ABIs at the avr-gcc level, so that it would be easier to experiment with partial libraries?

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

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. I assume that would require a lot of work.

One problem with just implementing double as a 64-bit type is promotion rules and library interfaces. Existing code will incur data size and performance penalties. Sometimes, you probably want that because of the improved accuracy, but other times probably not - if the code already works, why "improve" it ?

Sid

Life... is a state of mind

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

ChaunceyGardiner wrote:
One problem with just implementing double as a 64-bit type is promotion rules and library interfaces. Existing code will incur data size and performance penalties. Sometimes, you probably want that because of the improved accuracy, but other times probably not - if the code already works, why "improve" it ?
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

abcminiuser wrote:
Note that the last test case can be tricky - but requiring that the unroll amount is an integer division of the loop count would be reasonable.

#define justonce ...

for(unsigned char j=64/10; j; --j) { unroll10(10, justonce); }
unroll5(64 mod 10, justonce)

#define chunker(msize, mrem, count, size, x) \
    for(unsigned char j=(count)/(size); j; --j)  { msize(size, x); } \
    mrem((count) mod (size), x)

chunker(unroll10, unroll5, 64, 10, justonce)

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

But the promotion rules apply to expressions as well ?

Sid

Life... is a state of mind

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

Wouldn't' this loop-unrolling stuff be fairly easy to add as an m4 macro, by bringing back the ability to specify m4 pre-preprocessing (embarrassment in advance if the gcc script already takes an obscure flag for doing that)? All you need is a more powerful preprocessor that can do conditionals & loops...

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

skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.

Nope. Existing code *does* use "double", but they are limited to 32
bits. Still, it's completely OK for the code to use the default
(double) functions rather than their "f" counterparts.

If double is optionally implemented as 64 bits (something I'd also
like to see), it requires two sets of respective libraries which
have to be chosen by the compiler at link-time.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

ChaunceyGardiner wrote:
skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

But the promotion rules apply to expressions as well ?
In the OT days, but not now.
@Jörg: Note the emphasis on should.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

skeeve wrote:
ChaunceyGardiner wrote:
skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

But the promotion rules apply to expressions as well ?
In the OT days, but not now.

Are you saying that the following code will not use double ?
int i;
int j = i / 1.234f;

Sid

Life... is a state of mind

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

I'm not sure if this really belongs to this thread ... I tried IAR today for the first time. I tried an existing project, for which I normally use WinAVR. I ended up with a little bit smaller code. I looked at the code and noticed that in many cases several identical sequences of code get replaced with a subroutine and an rcall. In the past I used to use CodeVision, and I know that it does that too (well, at least v1 did). In the IAR case, for example, if there are several assignments to the same variable, which normally would get translated to a 4 byte STS, IAR would instead generate a subroutine with an STS, and several 2 byte RCALLs.

Does GCC do anything like? I see that there is a -ftree-tail-merge, but I guess that is only for "tails". Is there something for identical sequences in the "middle"? If not, can something like that be added?

Regarding new features in general - I'm really quite happy with avr-gcc the way it is. Better optimization for size is the only thing that I would want (so that we beat those other guys).

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

There is cfo-branch (code factoring optimization), abandoned several years ago and removed from mainline because it turned out not to work well. The command line option was -frtl-abstract-sequences

I think you are aware that this is work of several man-years (not counting the study of the theoretical background, testing, etc...)

avrfreaks does not support Opera. Profile inactive.

Last Edited: Thu. Jan 24, 2013 - 07:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compiler-generated functions seems like a very bad idea to me. At the very least, it would have to be off by default even when -Os is used.

Sid

Life... is a state of mind

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

Breaking out functions can reduce the code size a lot. But I don't think that well written programs will gain much code density.

This optimization can help with spaghetti code from auto-generators that are agnostic to the mess they produce. I saw parts of auto-generated C-code from a customer with functions with 96 (yes, close to 100) arguments!

I am not sure if it would work well as mini-optimization with load / stort: You'll have to fix the involved GPRs which may lead to additional MOVes to adjust the registers. It would work well if there is no sophisticated register allocation like in BASCOM, but with GCC you must be very very careful or the effect is completely detrimental.

Besides that, the complexity of such a work is far beyond anything I can do in my spare time.

avrfreaks does not support Opera. Profile inactive.

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

ezharkov wrote:
I'm really quite happy with avr-gcc the way it is. Better optimization for size is the only thing that I would want
+1

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

ChaunceyGardiner wrote:
skeeve wrote:
ChaunceyGardiner wrote:
skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

But the promotion rules apply to expressions as well ?
In the OT days, but not now.

Are you saying that the following code will not use double ?
int i;
int j = i / 1.234f;

Yes.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

skeeve wrote:
ChaunceyGardiner wrote:
skeeve wrote:
ChaunceyGardiner wrote:
skeeve wrote:
The standard math functions have float as well as double versions.
Existing code should have used them.
Functions that use variable arguments lists will have to deal with the promotion to double.

But the promotion rules apply to expressions as well ?
In the OT days, but not now.

Are you saying that the following code will not use double ?
int i;
int j = i / 1.234f;

Yes.

Thanks! I wasn't aware of that. I'll blame my confusion on the printf() family - in a format string %f means double, while in a constant the f suffix means "not double".

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;

Sid

Life... is a state of mind

Pages