Redundant code generated for 8bit function return type?

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 687 View posts
Location: Amadora, Portugal
#1
Posted by Nuno: Fri. Jan 26, 2007 - 12:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

I though about it and searched the bug list in the links provided by the sticky posts, but I haven't yet understood why the code

uint8_t flag;

uint8_t function (void)
{
    return flag;
}

generates a 16 bit return value (snippet from the LST file):

(...)
uint8_t flag;

uint8_t function (void)
{
  4c:	80 91 60 00 	lds	r24, 0x0060
    return flag;
}
  50:	99 27       	eor	r25, r25
  52:	08 95       	ret
(...)

Isn't the "eor r25, r25" a "redundant" instruction?...
I'm compiling with "-g -Os". I updated my older (2005) WinAVR version to the most recent one (2007) and it still generates a 16bit return type.

P.S. By the way, great improvement from that old 2005 to the new 2007 version. The code size on the project I'm working on now was reduced by ~7.9% just by using the new version.

Edit: Added the attached files.

Attachment(s): 

Package icon Source file and Makefile for the "always" 16-bit function return type

Embedded Dreams
One day, knowledge will replace money.

Tags:

Tools, Compilers and General Programming
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Fri. Jan 26, 2007 - 12:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it's well known. The ABI stipulates that the function returns a word as a minimum, even if the return type is byte sized. That EOR is the same as CLR, so it's clearing the upper byte of the return word.

I wish the ABI was changed for AVR-GCC to prevent it, but so far it hasn't happened.

- Dean :twisted:

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

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 687 View posts
Location: Amadora, Portugal
Posted by Nuno: Fri. Jan 26, 2007 - 12:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's really a pitty. A few instructions could be shaved out by this.
Isn't the ABI platform dependant?

Embedded Dreams
One day, knowledge will replace money.

Top
brberie
brberie's picture
Level: Resident
Joined: Fri. Sep 12, 2003
Posts: 524 View posts
Location: XX century
Posted by brberie: Fri. Jan 26, 2007 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try to read about -mint8 option.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Fri. Jan 26, 2007 - 01:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Try to read about -mint8 option.

Bad idea. That option is largely unsupported by the AVRLibC library, and makes code very difficult to manage.

- Dean :twisted:

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

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 687 View posts
Location: Amadora, Portugal
Posted by Nuno: Fri. Jan 26, 2007 - 02:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I know that option, "consider 'int' as 8 bits.
It brings out all kinds of warnings, though.
Thanks!

Embedded Dreams
One day, knowledge will replace money.

Top
brberie
brberie's picture
Level: Resident
Joined: Fri. Sep 12, 2003
Posts: 524 View posts
Location: XX century
Posted by brberie: Sat. Jan 27, 2007 - 05:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should know the tool you are going to use. Therefore, I do manage very serious and quite big project, do not have any one warning even all warnings are allowed. It is especially useful when speed is critical

CFLAGS = -ggdb
#CFLAGS += -c
#preprocessor
#CFLAGS += -E
CFLAGS += -O3
CFLAGS += -mint8
CFLAGS += -pipe -funsigned-char -funsigned-bitfields -fshort-enums -fforce-mem -fforce-addr 
#-fno-inline 
#-fpack-struct 
CFLAGS += -funroll-loops
CFLAGS += -Wall -Wstrict-prototypes
CFLAGS += -Wa,-adhlns=$(<:.c=.lst)

My options for the fastest code I was able to get
Include and forget about int and long - use int16_t and int32_t instead.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Sat. Jan 27, 2007 - 05:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

brberie, if a single word increases your execution time by an unacceptable amount, you should re-code in GAS-ASM and link that to your C code.

Using the -mint8 option is a terrible, terrible, terrible idea. Not only does it make your code difficult to maintain, large portions of the AVRLibC library fail in spectacular and unexpected ways when it used with that option.

I believe you've heard all this before from people smarter than I, so I'll stop here. But I must warn the OP that using that option will just end up in a large amount of head-scratching and confusion.

- Dean :twisted:

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

Top
brberie
brberie's picture
Level: Resident
Joined: Fri. Sep 12, 2003
Posts: 524 View posts
Location: XX century
Posted by brberie: Sat. Jan 27, 2007 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser, coding in ASM

Quote:
is a terrible, terrible, terrible idea. ...it make your code difficult to maintain
It is acceptable only if it is absolute necessity. The same rule applies to mint8 option. I'm telling it with over 20 years of experience behind, with dozens successful projects. Once again, you must know the tools you use and it saves you from
Quote:
fail in spectacular and unexpected way
.

Last Edited: Sat. Jan 27, 2007 - 01:17 PM
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Sat. Jan 27, 2007 - 01:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If maintained properly, short ASM modules which use documented ASM instructions are infinitely easier to manage by someone unfamiliar to a project than is obscure compile switches which enforce non-standards compliant behavior. With mint8, you just don't know what library functions will fail or exhibit subtle bugs.

However, as I have seen the code puzzles you've posted here, I'd wager you're none too concerned with making any of your code maintainable ;).

EDIT: Those more knowledgeable than I have gone over this before with you. Joerg gave some good mint8 comments to you in this thread.

- Dean :twisted:

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

Last Edited: Sat. Jan 27, 2007 - 01:22 PM
Top
brberie
brberie's picture
Level: Resident
Joined: Fri. Sep 12, 2003
Posts: 524 View posts
Location: XX century
Posted by brberie: Sat. Jan 27, 2007 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did achieve the goal I was seeking! Yes, it did cost some extra time and effort.

#if __USING_MINT8
    register byte sw = va_arg ( uk_arg, uint8_t );
    register byte n  = va_arg ( uk_arg, uint8_t );
#else
    register byte sw = va_arg ( uk_arg, int );
    register byte n  = va_arg ( uk_arg, int );
#endif

If you have the source code don't be afraid to look at it.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Sat. Jan 27, 2007 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brberie:

Out of curiosity I did a topic search for you name, I remember quite a few threads of yours full of cryptic code.

This thread dissolved into a flame war (with myself at the forefront, I might add) after you got cranky at people being unable to understand "one line of code". I consider myself quite good at C now, and I still think that code is ridiculous and undecipherable.

You achieved what you wanted in that thread, but at the cost of a severe loss of maintainability. Same thing applies to mint8 - I can only imagine the amount of confusion that would cause to someone else writing code for your project.

You yourself just posted that you found a workaround. Do you expect someone new to your project to realize the full ramifications and to code against them like you yourself did above?

Out of pure interest, are you self employed? If you code for others (or code with others), have any of them ever brought up the topic of the mint8 switch making your code even more difficult to read?

- Dean :twisted:

PS: I know I come across as being a real jerk in these posts, but I really do think I'm right here. Saving a couple of words in an application really isn't worth the mountain of problems the mint8 option brings. Age and experience is immaterial in this.

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

Top
brberie
brberie's picture
Level: Resident
Joined: Fri. Sep 12, 2003
Posts: 524 View posts
Location: XX century
Posted by brberie: Sat. Jan 27, 2007 - 02:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You achieved what you wanted

Quote:
I really do think I'm right here.

I'll let you stay with what you think...

Last Edited: Sat. Jan 27, 2007 - 04:04 PM
Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 687 View posts
Location: Amadora, Portugal
Posted by Nuno: Sat. Jan 27, 2007 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm actually coding for very small devices (2KB program flash) and I basically don't use the lib. For now I have only 4 or 5 redundant instructions in my code (~0.285%) so I'm not too much worried.

But if one day I see that these 0.285% are getting into my way, I could try the -mint8 option; but, since it brings all kinds of warnings into an already made C program and I code in ASM just as well as I do in C, I guess it would be easier to convert 1 or 2 routines to assembly than to add a bunch of casts and other tricks to the already working C code (this ASM convertion is actually pretty simple: just pick the code generated by GCC and remove the redundant instruction ;)).

However I don't agree that -mint8 should be removed from GCC, as it adds flexibility to anyone that knows what he's doing, although I agree that there should be a big, wide and flashing red warning and reasoning on why not to use it about that option in the documentation.

From the kind of redundant code I've been seing (in my code is basically almost everything extra "eor r25, r25"), I guess that a GCC with improved optimizations could remove it. Maybe in a future GCC version we'll see the extra code go away.

Thanks for all the replies!

Embedded Dreams
One day, knowledge will replace money.

Top