Need AVR-GCC 4.4.1 Windows binary

Go To Last Post
36 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

Acknowledging this is a lazy-man request.. could someone for whom it's convenient build a Windows binary for AVR-GCC 4.4.1 and post it someplace I can get at? I'm on Windows and haven't yet ventured into building the toolchain.

I'm hitting the Flash memory ceiling on one of my projects and have been spending a fair bit of time the last couple days analyzing the assembler output of various C patterns. I'd like to throw GCC 4.4.x into the mix to see if there's any improvement. I'm new to the whole WinAVR/AVR-GCC scene (am migrating from Bascom), but it struck me that this might be a good opportunity for me to generate some feedback re http://www.mail-archive.com/avr-gcc-list@nongnu.org/msg06307.html.

Much thanks - hope I don't get razzed too much for this request!

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

I wouldn't put too much hope into any version, if you really hit the ceiling. How much FLASH spare do you expect, more than a couple of percents?

Meanwhile, you can try some of the older versions, which usually generate less code. This might sound surprising unless you realise the fact, that the mainstream gcc development concentrates on the big processors, where code size is the least of an issue nowadays.

You also might want to experiment more with various switches to gcc.

But still, if you are really at the edge, you should either consider switching to a different model of AVR, or switching to a completely different microcontroller which supports more internal or external code memory.

JW

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

Thanks for the quick response JW.

I should have clarified, but didn't want to ramble: I was hitting the ceiling in Bascom when my project was about 90% complete (d'oh!). That's why I switched to WinAVR. Since I was so close to being done, and since Bascom's compiler is not very advanced, I trust I'll be able to make it fit.

But rather than just rewrite everything and hope for the best, I'm porting the code over one chunk at a time and examining the output as I go. This way I can catch any issues early on and (hopefully) adopt some space-saving coding patterns from the get-go.

FYI I'm using an AT90S2343 which only has 2kb of Flash. AVR-GCC's init code alone takes up 3.4%. Hence why I'm so footprint-conscious. Not to mention, I like having some idea of what sort of instructions my high-level code is spitting out.

Interesting idea to go to an older version for smaller code. Thanks for the tips!

Still if anyone has a Windows binary of the new compiler I'd be interested in doing a quick compare-as-I-dare to see if there's a difference.

Last Edited: Sun. Aug 23, 2009 - 07:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 2kB code project should be fairly easily written in assembler...

JW

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

True.. but I figured it's a good opportunity to learn WinAVR/AVR-GCC.

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

OK, then I hope you have learned lesson #1: Always plan to migrate to the next bigger model of mcu, if you use C.

JW

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

You can try to use live Linux to compile your application. Currently I have gcc 4.3.3, and I don't even know if 4.4.x have been already ported to AVR.

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

Quote:

AVR-GCC's init code alone takes up 3.4%.

Then tell it you don't want it (-fnostartfiles/-nodefaultlib I think it is?) but in this case you'll need to provide your own stack setting, R1=0 and possibly .data and .bss loops

As for building GCC - why not do it yourself? Start by downloading Sun's VirtualBox and then install a copy of Ubuntu into it. Then use Bingo's scripts o build yourself an avr-gcc.

Now either continue to build your files in the Linux sandpit or configure to cross-compile for a Windows target (but this is decidedly non-trivial and I think Eric is one of the few people who knows how to cast the runes)

An alternative is to do EXACTLY what Eric does and stcik to the Windows environment but download Cygwin and Msys and build within there - however this may actually be even MORE complex than doing it in a Linux sandpit (I'll bet if Eric had his time over he might consider doing it in a virtual Linux sandpit)

Cliff

PS Just noticed that Bingo's latest is 4.3.3 so you'd have to modify that yourself to do 4.4.1 - in which case the patches would not be valid = can of worms.

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

You do NOT want to move to any GCC 4.4.x version yet.

For the 4.4 series, a new Integrated Register Allocator (IRA) was added to GCC and all of the ports had to migrate to using IRA. While some testing has been done with the GCC Regression Test Suite, it is unknown how this version fares on generating code for real world AVR applications. It may be just fine. There may be new bugs lurking that have yet to be uncovered. Use at your own risk.

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

A better approach to your problem may be to work with the current compiler and post your problems as they come up. Depending on the next compiler version to magically fix your problems rarely works.

To help you out, here some some hints at building smaller code culled from other sources.

First off, avoid floating point calculations like the plague! All floating point math is done by software and the libraries are (for your application) huge.

---------------------

> On inspection I find that the compiler has 'in-lined' at least 3
> function calls that I had written as a function to achieve compactness.
> Is there any way I can stop this, or is this a bug?

There has been some discussions about this before. After trying many different optimization settings I concluded that

--param inline-call-cost=2

is -overall- the best setting for small projects. However, if you need to minimize just one app, further reduction might be possible.
For example with things like:

-fno-inline-small-functions
-fno-split-wide-types
-fno-tree-scev-cprop

Also, you can prohibit the compiler to inline on a function by function basis.

Just to be sure you have no dead code around, include:
-ffunction-sections -Wl,--gc-sections -Wl,--relax

Ruud Vlaming

---------------------

add "OS_main" attribute to main function,

and (for an ATTiny) use the compiler switch:

-mtiny-stack

Anatoly Sokolov

---------------------

Also you can use the gcc options:

-combine
-fwhole-program

To use the options, you must compile all of your source with one call to the compiler:

avr-gcc ... -combine -fwhole-program ... main.c foo.c grunge.c gort.c mylib.c ...

Stu Bell

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

FYI I'm using an AT90S2343 which only has 2kb of Flash.

Wow--that is a trip to the way-back machine. Why wouldn't you use a Tiny25? Have some in the goodie bag for a one-off? (that's an excellent reason!)

[side note: If a Tiny45 costs ~$2 then how much is your time worth changing toolchains in the middle of the project? Apparently only a few cents an hour.]

Quote:

AVR-GCC's init code alone takes up 3.4%

When talking about the size of a "null program", you must decide what features of the C standard prologue you want to do without. 3.4% of 2048 is 70 bytes. Certainly a factor in a tight app, but let's do a little poking at this "bloat".

Kind of vector-deprived model, but 3 vectors; total 6 bytes. Nearly 10%.
Add the catch loop for another 2 bytes.

Let's look at what the prologue might do to protect itself from arriving at the reset vector under arbitrary conditions:
-- CLI
-- clear EECR and MCUCR
-- turn off watchdog
another 14 bytes--20% of the bloat.

Set the stack pointer: 4 bytes.

Clear global variables per C spec: maybe 20 bytes.

Now, when I built I got 50 bytes for a null program (with a different toolchain). As I recall, GCC's null program is nice and small so 70 sounds a bit high. Do you have any global variables with initial values? That would account for the space for the values, and the loop to initialize them.

Nearly all of the above can be jiggered away. If you really don't care to protect yourself, and you never use interrupts, and never use the stack then you can roll your own prologue and make it smaller. Personally, I want those protections.

Quote:

OK, then I hope you have learned lesson #1: Always plan to migrate to the next bigger model of mcu, if you use C.

LOL -- here we go again...

Summary: Let's see your null program and the generated prologue.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I'm kind of wondering where the 3.4% figure comes from? If I build:

#include  

int main(void) 
{
	while(1) {
	}
}

using -Os for AT90S2343 I get:

AVR Memory Usage
----------------
Device: at90s2343

Program:      26 bytes (1.3% Full)
(.text + .data + .bootloader)

which consists of:

Disassembly of section .text:

00000000 <__vectors>:
   0:	02 c0       	rjmp	.+4      	; 0x6 <__ctors_end>
   2:	07 c0       	rjmp	.+14     	; 0x12 <__bad_interrupt>
   4:	06 c0       	rjmp	.+12     	; 0x12 <__bad_interrupt>

00000006 <__ctors_end>:
   6:	11 24       	eor	r1, r1
   8:	1f be       	out	0x3f, r1	; 63
   a:	cf ed       	ldi	r28, 0xDF	; 223
   c:	cd bf       	out	0x3d, r28	; 61
   e:	02 d0       	rcall	.+4      	; 0x14 
10: 02 c0 rjmp .+4 ; 0x16 <_exit> 00000012 <__bad_interrupt>: 12: f6 cf rjmp .-20 ; 0x0 <__vectors> 00000014
: #include int main(void) { 14: ff cf rjmp .-2 ; 0x14
00000016 <_exit>: 16: f8 94 cli 00000018 <__stop_program>: 18: ff cf rjmp .-2 ; 0x18 <__stop_program>

where 6: puts a guaranteed 0 in R1, 8: puts this in SREG to ensure I is clear, A:/C: are setting SP. The rest, I hope, is obvious.

So whence cometh the 3.4% ?

Cliff

PS Just for the pig-iron I built it -O0 and got:

Program:      34 bytes (1.7% Full)

the "bloat" consisted of four completely pointless opcodes added in main:

int main(void) 
{
  14:	df 93       	push	r29
  16:	cf 93       	push	r28
  18:	cd b7       	in	r28, 0x3d	; 61
  1a:	de b7       	in	r29, 0x3e	; 62
  1c:	ff cf       	rjmp	.-2      	; 0x1c 

PPS The .data and .bss loops don't get added until I use some. -Os with one byte of .data and one of .bss I get:

Program:      76 bytes (3.7% Full)

00000006 <__ctors_end>:
   6:	11 24       	eor	r1, r1
   8:	1f be       	out	0x3f, r1	; 63
   a:	cf ed       	ldi	r28, 0xDF	; 223
   c:	cd bf       	out	0x3d, r28	; 61

0000000e <__do_copy_data>:
   e:	10 e0       	ldi	r17, 0x00	; 0
  10:	a0 e6       	ldi	r26, 0x60	; 96
  12:	b0 e0       	ldi	r27, 0x00	; 0
  14:	ea e4       	ldi	r30, 0x4A	; 74
  16:	f0 e0       	ldi	r31, 0x00	; 0
  18:	03 c0       	rjmp	.+6      	; 0x20 <.do_copy_data_start>

0000001a <.do_copy_data_loop>:
  1a:	c8 95       	lpm
  1c:	31 96       	adiw	r30, 0x01	; 1
  1e:	0d 92       	st	X+, r0

00000020 <.do_copy_data_start>:
  20:	a2 36       	cpi	r26, 0x62	; 98
  22:	b1 07       	cpc	r27, r17
  24:	d1 f7       	brne	.-12     	; 0x1a <.do_copy_data_loop>

00000026 <__do_clear_bss>:
  26:	10 e0       	ldi	r17, 0x00	; 0
  28:	a2 e6       	ldi	r26, 0x62	; 98
  2a:	b0 e0       	ldi	r27, 0x00	; 0
  2c:	01 c0       	rjmp	.+2      	; 0x30 <.do_clear_bss_start>

0000002e <.do_clear_bss_loop>:
  2e:	1d 92       	st	X+, r1

00000030 <.do_clear_bss_start>:
  30:	a3 36       	cpi	r26, 0x63	; 99
  32:	b1 07       	cpc	r27, r17
  34:	e1 f7       	brne	.-8      	; 0x2e <.do_clear_bss_loop>
  36:	02 d0       	rcall	.+4      	; 0x3c 
38: 06 c0 rjmp .+12 ; 0x46 <_exit>

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

And you didn't even build a null program. ;)

GCC's "classical" optimizer skips most of the categories of "protection" that I mentioned above. It does the CLI and SP but pays no attention to DATA or BSS--there ain't any. ;)

A curious omission is the watchdog...

Anyway, I suspect the "null" program has BSS & DATA.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

And you didn't even build a null program.

I was possibly being a bit "naughty" with that one as I knew the program would get larger because:

int main(void) 
{
}

yields:

int main(void) 
{
}
  3c:	80 e0       	ldi	r24, 0x00	; 0
  3e:	90 e0       	ldi	r25, 0x00	; 0
  40:	08 95       	ret

In which the compiler is rather helpfully preparing an implied "return 0" for the function that returns an int - a completely pointless exercise considering where it's headed next ;-)

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

clawson wrote:
In which the compiler is rather helpfully preparing an implied "return 0" for the function that returns an int - a completely pointless exercise considering where it's headed next ;-)

This is why the noreturn attribute exists. It allows you then declare main to return void.

JW

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

Quote:

PPS The .data and .bss loops don't get added until I use some. -Os with one byte of .data and one of .bss I get:
Code:
Program: 76 bytes (3.7% Full)

which is real close to OP's number.

The summary to OP is to look elsewhere, or be prepared to roll-your-own prologue. IMO the standard prologues give the protection needed for an arbitrary program and an arbitrary arrival at location 0. If you care to skip those protections, it is up to you.

And as we've demonstrated, some of that bloat may be of your own doing. In all of my programs, I have few if any initializers on global [SRAM] data--let's say it is an exception and I might use it in 1 of 10 apps.

As for wek, if you are an ASM wizard that thinks in op codes you are going to beat me no matter what the language. But in general when I know my tool chain and write the app to be small and fast and tight, I'll go up against any "average" ASM programmer with my straight C.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Whoa guys, thanks for all the activity!

>>As for building GCC - why not do it yourself?<<
Cliff, I think the rest of your post answered that question. I haz no runes. And I'm already overstocked with cans of worms. ;-). But thanks anyhow for the leads. Maybe once I can tread water in the WinAVR toolchain, I'll swim a little deeper.

>>..work with the current compiler and post your problems as they come up<<
Stu, MUCH thanks for switches. I will try them out to see if there's an impact. There are a few minor optimization disappointments I've noticed and I'll start posting them with small sample programs.

>>Wow--that is a trip to the way-back machine. Why wouldn't you use a Tiny25?<<
Lee, you are correct this is a one-off from the spare parts bin. You have no idea what I'd give for a couple of GPIO regs and a PWM! Hah.. apparently not $2.. but really, working with limited resources is forcing me to pay more attention under the hood than I would otherwise.

I will likely write my own prologue. The default boilerplate isn't bad but it seems to me there's some room for improvement:

1) Suppress Vector Table (8 bytes)
When no interrupts are used, why not start program code at $0, and also knock out __bad_interrupt?

2) Eliminate Redundant SREG Initialization (2 bytes)
According to the datasheet for my part, SREG is already 0 on powerup, so do we really need to clear it in line 8? Do some mcu's not preinitialize it for you? Are there remnant effects I'm not seeing from the bootstrap code that we need to clear out?

3) Elastic Loop Counter For Prologue (4 bytes)
There's no need to check the high byte in line 22 or 32. I'm guessing the line is there because an int counter is used in __do_copy_data and __do_clear_bss. On parts with < 256 SRAM locations, why not use a byte counter instead?

4) Eliminate Redundant Register Loads (2 bytes)
No need to reinitialize R17 in line 26 as we already did this in line e and the register has not been changed. This is the sort of "statement merging" smarts I was *really* hoping to get out of GCC..

5) More Unwanted Boilerplating (6 bytes)
__exit, the jump to it, and __stop_program aren't neccessary if main() is an infinite loop.

Also.. when I start using deeper nesting and passing around more parameters, is there any stack-related prepwork I need to do when I write my own prologue? (Aside from initializing SPL?)

3.4% vs 1.7%
For those interested.. the reason Cliff and I had different results on our null programs was because I was one version behind on WinAVR, and GCC was not optimizing out __do_copy_data and __do_clear_bss the way it did for him. Mine generated a couple of loops amounting to "for (X = 0x60; X < 0x60; X++) {...}" and I was beating myself up trying to figure out why the compiler wasn't eliminating them, until a few days ago I came across a post (https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=75952#549755) where Eric mentions these two functions were moved from "avr-libc" to "gcc" in GCC 4.4 / avr-libc 1.8 so the compiler can hack at them. In fact this was one (small) benefit I was hoping to get in 4.4. But after upgrading to the latest WinAVR release (GCC 4.3.2 / avr-libc 1.6.6) they now get eliminated and my results are consistent with his. Was Eric mistaken about when this patch was applied, or am I interpreting version numbers incorrectly?

Incidentally, does that mean this bug from 2004 can be closed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145

IRA
One last (probably very stupid) question.. when it is eventually introduced to AVR, will IRA improve the situation for those wishing to reserve registers and put global data in them? Or is the only reliable way to do this still to "recompile the lib"? I sort of wish the compiler would automatically stuff some of my more-often used globals into any leftover registers not used in the rest of my program or its invoked library calls. That'd be slick.

Last Edited: Tue. Aug 25, 2009 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
According to the datasheet for my part, SREG is already 0 on powerup, so do we really need to clear it in line 8?

It's probably there for restarts that do not go through powerup. In those cases sreg might not be 0.

Regards,
Steve A.

The Board helps those that help themselves.

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

rkagerer wrote:

There are a few minor optimization disappointments I've noticed and I'll start posting them with small sample programs.

Please note that most of those that you encounter are very probably already known. FYI, here's a list of known AVR toolchain bugs:
http://www.nongnu.org/avr-libc/b...

rkagerer wrote:

1) Suppress Vector Table (8 bytes)
When no interrupts are used, why not start program code at $0, and also knock out __bad_interrupt?

Known issue. There's a bug report/enhancement request around somewhere for this. Either that or it's on my internal todo list (and should make it to a public list sometime).

rkagerer wrote:

4) Eliminate Redundant Register Loads (2 bytes)
No need to reinitialize R17 in line 26 as we already did this in line e and the register has not been changed. This is the sort of "statement merging" smarts I was *really* hoping to get out of GCC..

I haven't looked into the details, but your description sounds like known optimization issues I've seen before.

rkagerer wrote:

5) More Unwanted Boilerplating (6 bytes)
__exit, the jump to it, and __stop_program aren't neccessary if main() is an infinite loop.

Also known issue.

rkagerer wrote:

IRA
One last (probably very stupid) question.. when it is eventually introduced to AVR, will IRA improve the situation for those wishing to reserve registers and put global data in them?

Unfortunately, doubtful. Currently I'm just hoping that IRA doesn't generate any wrong code.

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

rkagerer wrote:
and I was beating myself up trying to figure out why the compiler wasn't eliminating them, until a few days ago I came across a post where Eric mentions these two functions were moved from "avr-libc" to "gcc" in GCC 4.4 / avr-libc 1.8 so the compiler can hack at them. In fact this was one (small) benefit I was hoping to get in 4.4. But after upgrading to the latest WinAVR release (GCC 4.3.2 / avr-libc 1.6.6) they now get eliminated and my results are consistent with his. Was Eric mistaken about when this patch was applied, or am I interpreting version numbers incorrectly?

Maybe. WinAVR usually has patches to tools which are already committed upstream, but are also applied to earlier versions. It could be that. It could be I had my versions wrong. After I do a release I start working with later versions, so sometimes I get mixed up what the latest and greatest is out in the wild. :wink:

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

EW - thanks for clarifying, and HUGE thanks to you and all the AVR-GCC folks for all your hard work!

Just curious, any comment on #3?
(I know.. 2 bytes is pretty insignificant in the grand scheme of things)

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

theusch wrote:
As for wek, if you are an ASM wizard that thinks in op codes you are going to beat me no matter what the language. But in general when I know my tool chain and write the app to be small and fast and tight, I'll go up against any "average" ASM programmer with my straight C.

Lee,

if you are a C wizard that thinks in the ways how the toolchain works, you are going to beat the "average" ASM programmer. But in general, "average" C programs are inevitably bigger than "average" asm programs.

But that's not the point. The point is, once you start writing in C, you should stop be worried about precise code size and execution speed. That's not under your control anymore. It might be relevant or it might not; but the likelihood it will is way bigger in a 2k device than in a 16k+. On the other hand, rewriting a 2k application in asm, or designing in a bigger devices are both very viable options, so what's the benefit of the C propaganda here?

Jan

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

Quote:

I was one version behind on WinAVR

My GCC is:

C:\>avr-gcc --version
avr-gcc (WinAVR 20090313) 4.3.2

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

Quote:

The point is, once you start writing in C, you should stop be worried about precise code size and execution speed. That's not under your control anymore.

I don't totally agree. Just as you might "review" your ASM app after the initial draft, and say "if I hold this address of an array elemet throught the transaction, I won't have to recalculate it every time and it will save me code space and cycles", or "I'm using the heck out of this value; I'll make it a register variable and gain size and speed" you use exactly the same mindset when writing your C.

Quote:

It might be relevant or it might not; but the likelihood it will is way bigger in a 2k device than in a 16k+. On the other hand, rewriting a 2k application in asm, or designing in a bigger devices are both very viable options, so what's the benefit of the C propaganda here?

??? Are you spouting apples and oranges here? Why do I need to re-write my 2k app in ASM, when if you can fit it with ASM I can fit it with C?

There are exceptions, and I've listed them before. If you write your whole app with 24-bit (say) arithmetic and there is a lot of it, then yes you win--C has no concept of that. If your app uses true rotate and/or carry to great advantage in size/speed, then C has no concept of those and you win. In general, though, it is an 8-bit micro and you are talking about a small one, so nearly all apps are going to be dealing with small numbers--timing, A/D and the like.

Regarding the choices: That depends largely on production quantity in the real world. If I'm doing a 1-off test fixture then I'm going to grab a model that I know is going to contain the app nicely--even a few hours of squeezing time dwarfs the cost of the next bigger model. If I'm doing the controller for 6 million microwave ovens than each penny counts, so squeezing time is justified.

[we still haven't seen OP's "bloated" null program]

Back when I was your age ;) I had a squeezed AT90S4433 app in ASM. It was a pressure controller with a 4x 7-seg display. Pressure/setpoints were shown in various units and ranges. I had a very elaborate normalization/scaling/assumed decimal point system to do A/D <=> pressure. It took about a millisecond to do the conversion/display. This app was so squeezed I used unused vector entries for constants. ;)

Then I re-wrote it in C 'cause we wanted more features on the next version, and the mega8 came out at a lower price than the '4433. When I got to this area of the code for units and display, it would have made some quite elaborate coding. On a whim I did it in the straightforward way: take the A/D value, normalize it, and multiply by a floating point constant, and then tore apart the FP result (using code from the User Projects of this site) to get my four significant digits and the decimal point position.

The result was smaller and faster than my elaborate ASM version. Now, maybe tha's 'cause I'm an "average" ASM programmer?

It is the compiler writer that has to be smart--the ASM programmer has no more op codes or other magic that the compiler writer does. (Just as the RTOS writer has no magic that you or I do, in ASM or C or FORTRAN.)

Nothing like a C vs. ASM to get the juices flowing on a summer morning.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
The result was smaller and faster than my elaborate ASM version. Now, maybe tha's 'cause I'm an "average" ASM programmer?

Inferior ASM programmer, then. :-P

theusch wrote:
Nothing like a C vs. ASM to get the juices flowing on a summer morning.

Sure. That's why you omitted the context in which I spoke out for ASM.

But, you've said, "Why do I need to re-write my 2k app in ASM, when if you can fit it with ASM I can fit it with C? ".

Fancy a competition? Your pure C application just to fit to 2k FLASH with gcc 4.3, handed over
to me for some optimisation?

Jan

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

rkagerer wrote:

Just curious, any comment on #3?
(I know.. 2 bytes is pretty insignificant in the grand scheme of things)

I don't know offhand (that's why I didn't comment on it), someone should probably look into it deeper. If it turns out to be the case, then perhaps a bug report on avr-libc would be warranted, so we can get that fixed.

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

wek wrote:

Fancy a competition? Your pure C application just to fit to 2k FLASH with gcc 4.3, handed over
to me for some optimisation?

C'mon don't hijack the thread. Take your language wars elsewhere to a different thread, that way I can duly ignore them. ;)

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

Quote:

Your pure C application just to fit to 2k FLASH with gcc 4.3, handed over
to me for some optimisation?

Ouch--now I'm going to be crippled via use of a specified toolchain?!? Now I know why EW wants out.

One of my profs has a saying: "Any program can be made one cell shorter." Micro-optimization can always be done, even by the most "average", or "inferior", ;) of programmers.

Quote:

Your pure C application just to fit to 2k FLASH

That's a bogus test--my apps never come >>near<< to filling the allotted space...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
That's a bogus test--my apps never come >>near<< to filling the allotted space...

Yeah, but that was the original premise. Remember? A BASCOM program flowing over the 2k, and a desperate attempt to port it to C. 2k seems to be a limit for some reason. What I say is, write it in asm - 2k is easy - and if it fits, it fits; if it won't, it won't in C either.

Now I can say, also, "look, do it as Lee does, take the +1 size chip straight away". ;-)

Jan

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

Quote:
Fancy a competition? Your pure C application just to fit to 2k FLASH with gcc 4.3, handed over to me for some optimisation?

The reverse would also be necessary to prove anything.

Regards,
Steve A.

The Board helps those that help themselves.

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

EW wrote:
wek wrote:

Fancy a competition? Your pure C application just to fit to 2k FLASH with gcc 4.3, handed over
to me for some optimisation?

C'mon don't hijack the thread. Take your language wars elsewhere to a different thread, that way I can duly ignore them. ;)


What? Are duels to be fought outside the city walls only, in the shade of the dark?

I promise nobody will be killed. Two STK500-s handed out by the seconds, loaded by the 2k of code, and then we shoot optimisations on each other alternatively. To first blood only... :-D

JW

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

"near" is relative. Maybe for >>you<< it means "the next bigger chip was used". For me that means 90%-99% full--plenty of room for another feature.

[Yeah, EW, I know...it was fun though. I've got the app in mind for wek in the suggested new thread sometime...]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

EW wrote:
You do NOT want to move to any GCC 4.4.x version yet.

For the 4.4 series, a new Integrated Register Allocator (IRA) was added to GCC and all of the ports had to migrate to using IRA. While some testing has been done with the GCC Regression Test Suite, it is unknown how this version fares on generating code for real world AVR applications. It may be just fine. There may be new bugs lurking that have yet to be uncovered. Use at your own risk.

Thats why I think that WinAVR (GCC + avr-libc, at least) should have something like nightly builds, so other people can test it.

Felipe Maimon

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

Quote:

Thats why I think that WinAVR (GCC + avr-libc, at least) should have something like nightly builds, so other people can test it.

All that requires is someone to volunteer to set up the infrastructure to do it ;-)

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

clawson wrote:
All that requires is someone to volunteer to set up the infrastructure to do it ;-)

It's already there in Sourceforge. All it's needed is EW to generate a new installer with the test build, maybe once a week or two.

Felipe Maimon

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

Good idea. It'll take some time to implement anything like that. Currently I have some issues just building gcc 4.4.1, but those are related to my tools.