Compiled binary needs more flash with newer avr-gcc

Go To Last Post
67 posts / 0 new

Pages

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

clawson wrote:
But if the real "issue" here is you have an 8K chip but 8K+a_bit to fit into it then while examining navel fluff to understand the minutiae of what has changed might help really I'd just be looking to see if there's anything been done in the code "inefficiently" simply so you can save "a_bit" bytes and bring it back under 8K.

 

In this case this was not the "real issue".
I simply discovered that the same source compiled under Debian 8 did not fit in the flash when compiled under Debian 10.

This point is cleared now.

 

When the source gets to big of course i search for inefficient programming and/or features that are not so important.

 

 

clawson wrote:
Now just using Kdiff/meld/BeyondCompare/diff/whatever to compare the two LSS is not necessarily easy as the code will have addresses, opcodes (hex) and also labelled call/jump destinations all of which will likely be different. But it is the "core" of the code - the LDIs and OUTs and CMPs and ADDs and whatever else. You need to look for chunks where one is obviously larger than the other then try to determine why that may have come about.

 

Yes - this will be a good method.

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

N.Winterbottom wrote:
As you can see - As newer compiler versions were released the generated code size fell.

 

That's an extented and interesting overwiew - thank you.

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

Diffing .lss files is likely a nogo,

but I suspect diffing the assembly files would work.

Moderation in all things. -- ancient proverb

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

skeeve wrote:
I suspect diffing the assembly files would work.

 

How a plain assembly file can be generated with the gcc-avr toolset?

 

Or is another tool like avrdisas needed ?

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

Just use -save-temps. For each main.c, uart.c, adc.c or whatever that is built you will find the build directory (often "Debug" or "Release") then contains for each main.i, main.s, uart.i, uart.s, adc.i, adc.s. The .i files are the source after pre-processing and the .s files are Asm sources after code generation.

 

As I note in one of my github projects here:

 

https://github.com/wrightflyer/a...

 

The asm that is generated can be quite difficult to read. That's because (without -save-temps) it's usually a "private" thing between the compiler and the assembler. No one expects humans to read it so it's not necessarily formatted that well for human use. As my example on github shows:

int main(void) {
    DDRB= 0xFF;
    while(1) {
        PORTB ^= 0xFF;
        _delay_ms(100);
    }
}

becomes:

.global    main
    .type    main, @function
main:
.LFB6:
    .file 1 ".././ledblink.c"
    .loc 1 4 0
    .cfi_startproc
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
    .loc 1 5 0
    ldi r24,lo8(-1)     ;  tmp46,
    out 0x17,r24     ;  MEM(volatile uint8_t *)55B?, tmp46
.L2:
    .loc 1 7 0 discriminator 1
    in r24,0x18     ;  D.1487, MEM(volatile uint8_t *)56B?
    com r24     ;  D.1487
    out 0x18,r24     ;  MEM(volatile uint8_t *)56B?, D.1487
.LVL0:
.LBB4:
.LBB5:
    .file 2 "c:\\program files\\atmel\\atmel toolchain\\avr8 gcc\\native\\3.4.2.876\\avr8-gnu-toolchain\\bin\\../lib/gcc/avr/4.7.2/../../../../avr/include/util/delay.h"
    .loc 2 164 0 discriminator 1
    ldi r24,lo8(24999)     ; ,
    ldi r25,hi8(24999)     ; ,
    1: sbiw r24,1     ;
    brne 1b
    rjmp .
    nop
    rjmp .L2     ;
.LBE5:
.LBE4:
    .cfi_endproc
.LFE6:
    .size    main, .-main

where even something simple like:

    DDRB= 0xFF;

has become:

    ldi r24,lo8(-1)     ;  tmp46,
    out 0x17,r24     ;  MEM(volatile uint8_t *)55B?, tmp46

Now lo8(-1) might well be the same thing as 0xFF but some of this stuff is not obvious. My avr-source program tries to help a bit by parsing the debug info in the file and using it to put source code back in so at least this becomes:

//==>     DDRB= 0xFF;
    ldi r24,lo8(-1)     ;  tmp46,
    out 0x17,r24     ;  MEM(volatile uint8_t *)55B?, tmp46

but I don't try to "repair" things like a lo8(-1) to 0xFF translation. But anyway at least the two compilers are going to be generating code in a "similar" fashion which might make diffing the .s a bit easier.

 

BTW is your project "secret" or could you simply share the code so we can all take a look and see if we can help y7ou to understand why one code generation is different from the other?

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

My advice would be:   ZIP up the AS7.0 project and attach the ZIP.

If it is a Makefile project on Linux.   You can still ZIP it up.

 

I suspect that there are opportunities to reduce the code size.    Just with regular C.  No tricks.

Let's face it.   An 8kB program is not very big.

 

I would only go down the ASM rabbit hole if performance or inventory costs are overwhelming.

 

David.

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

clawson wrote:
Just use -save-temps.

 

Thanks for the tip and your explanations.

It gives an overview and understanding what's happening in the background.

 

It seems that avrdisas gives a better opportunity to understand the result of the assembler, then the "machine readable" output of the compiler.

At this time i don't want to do a diff of the output and to understand what's happening in the assembler output - this is really like acting as a machine.

Last Edited: Tue. Feb 16, 2021 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

lsmodavr wrote:
this is really like acting as a machine.
Or a professional software engineer ;-)

 

(actually I guess those of us touching 60 or above who've been in this game 40/50/60 years probably did the first 20/30/40 years in Asm alone so we do tend to look at things in terms of the generated Asm - it's  a tricky habit to break!)

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

clawson wrote:

Or a professional software engineer ;-)

 

Well - it's better when you say this. wink

 

I did assemble my first code by hand for an Z80 ...

(and the machine was an ZX81 designed in Essex when i remember correct)

Last Edited: Tue. Feb 16, 2021 - 06:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sometimes you have to do that, or operate a verified compiler, or do applied formal methods (theory learned by studying abstract machines or Turing machines)

 

Tracing requirements through to object-code verification - Embedded.com

CompCert - Main page

 

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

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

You went further than me (TRS-80 Model 1 operator though via the assembler and BASIC)

The TRS-80 Model I

 

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

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

gchapman wrote:
Sometimes you have to do that

 

Yes - but only as informatic guy.

I am only an electronic guy that is programming a little bit.

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

gchapman wrote:
The TRS-80 Model I

 

Oh yes - such a model we did have at school.

And we used such an HP-calculator to learn what is programming - that's before BASIC https://en.wikipedia.org/wiki/HP-65

 

The ZX81 was the first computer that was cheap enough to buy it as grown up.

Now an AtMega8 is an equivalent with RAM and flash and more performance for about $1.

Of course i first used BASCOM for it. https://www.mcselec.com/index.ph...

It's an really bad compiler in comparison to the avr-gcc.

 

 

Maybe you will have fun with this project: https://www.mikrocontroller.net/... ?

Here in english: https://github.com/abelykh0/stm3...

Last Edited: Tue. Feb 16, 2021 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(actually I guess those of us touching 60 or above who've been in this game 40/50/60 years probably did the first 20/30/40 years in Asm alone so we do tend to look at things in terms of the generated Asm - it's  a tricky habit to break!)

 

Us are now officially old :(

 

A chap I used to mentor at work had his 28th birthday today. It'll be another five years before he's half my age!!!

 

Neil

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

So the conclusion is that assembler is for oldies. wink

 

Or seen in a positive way - we are the last understanding what's really going on in a machine. smiley

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


 

lsmodavr wrote:
(and the machine was an ZX81 designed in Essex
One county over - Sinclair Research where just opposite Kings in Cambridge high street I remember. I thin kthey later moved out to the Cambridge Science Park. In fact 6 Kings Parade where they started is the cream coloured shop in the middle here:

 

 

If you swing the view around to the other side of the street:

 

 

then that is a pretty inspiring view when you are sat designing your first Z80 computers !!

 

Building to the right is King's Chapel where the famous carol concert that is broadcast at 3pm each Christmas Eve is recorded. This is the other side of that building viewed from the River Cam:

 

 

Last Edited: Wed. Feb 17, 2021 - 10:22 AM

Pages