AVR Freaks

Arduino IDE and AS7 use the same C compiler/Assembler (may be different versions, but whatever) so produce the same code.

The Arduino environment sets up some background stuff, like a timer (for millis) and the basic program loop (main()) for you, so there is some small overhead that would not be there in pure AS7, although you may need to provide your own setup and loop anyway.

There is very little you have to use in the Arduino way, you can write your own functions(), or assembler code, nothing says you have to use the built in functions.

Jim

Why? What are your assumptions underlying this thought?

I would have thought the opposite - the size of the executable from the Arduino seems a bit big. It's either about the Arduino framework doing things very inefficiently, or the Arduino sketch written to be very inefficient. OTOH, if we're talking about a "plain blinky", i.e. one LED (or eight on the same port, just on-off-on-off... with delays then 400 bytes for that executable seems awfully high. I would think more like well below 100 bytes (i.e. well below 50 assembler instructions.

Anyway, my ballpark estimate is that a reasonably written C or C++ program should come in at not more than 125% of the hand-written assembler in most cases.

Nota bene: What we're talking about here is the amount of flash that the final executable occupies. Sizes of e.g. the hex file (and of course the source sketch or assembler files) are not representative in any manner whatsoever. If you're looking at the size of the hex file, then stop that immediately - it is a meaningless activity.

EDIT: Saw El Tangas post above. Sorry, I forgot that you're using GNU Assembler (not Atmels assembler) and that it adds startup code and the like. Yes, that will add a "fixed base cost". But if I'm not mistaken, you can get rid of that with some options passed to the assembler.

I still believe that a plain blinky in assembler should come in at (much?) less than 50 instructions: A loop for turning LED on, call a delay subroutine, turn LED off, call a delay function... That's less than 10 instructions. The delay subroutine should be less than 20 instructions. No interrupts, so no flash occupied by vectors. Surely well under 50 instructions..

So, personal enjoyment aside, am I barking up the correct tree when I am learning ASM (as opposed to C) to make the smallest / most efficent / fastest code ?

There's a difference between writing efficient code, and writing code efficiently.

You can get very close to optimally fast/small code with C/C++.  Say, 90% there.  To get better, yes, arguably ASM is the way to go, but engineering isn't all about the final product.  It's also about the process.  If getting those last 10% takes you 700% greater investment in time and human resources, that's a waste of your time, and worse, you'll be late to market, or miss the market altogether.

Maybe not relevant for a pure hobbyist, but that's your call.  Were it me, I'd learn C/C++ and ASM at the same time.  Learn from the compiler.  It does a pretty good job of generating ASM.  Not always, mind you, but it's a good place to start.

You need to realise that it's not always necessary, or even good, to optimise every part of your code.  Many apps will have speed-critical section.  Focus on getting those fast.  If you need to resort to ASM to do so, so be it.  Use your time wisely.

You don't need "libraries" to code in C for your AVR - except for the avrlibc runtime library (as long as we're talking about the avr-gcc toolchain), which is well documented. (A substantial part of it is an implementation of parts of the Standard C Library, which is very well standardized and documented.)

With only avrlibc and the part-specific header files (for convenience) you can write "everything" yourself.

Having said that, we often recommend to use well tested and proven "libraries" for commonly recurring stuff - e.g. driving I2C communication or driving a LCD display.

I admit that I do a lot of tinkering myself - not relying on libraries - for the sake of learning and understanding. But when it comes to doing something that should end up as a usable "thing" I prefer the libraries of others a lot of the time. Just saves such a lot of time developing, testing etc.