.zero vs reality

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

I compiled

char fred __attribute__((section(".noinit")));

and got

        .file   "noinit.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.global fred
        .section        .noinit,"aw",@nobits
        .type   fred, @object
        .size   fred, 1
fred:
        .zero   1
        .ident  "GCC: (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0"

.

Given the purpose of the .noinit section,

clearly no zeros will be headed fred's way.

Given the way data is initialized on AVRs,

I'm not surprised it works.

'Tain't obvious that combining @nobits and .zero is valid.

 

I've been looking for a convenient way to specify

"empty" flash sections that will not add to the .hex file.

Should something similar work?

I'm thinking of something like this:

.global greg
        .section sectionstarttarget,"a",@nobits
        .type   greg, @object
        .size   greg, 2560
greg:
        .zero   2560
        .section code, "ax",@progbits
        ldi r16, 0

The "empty" sections will be targets of SPM instructions.

I want the sections to ensure that if I mess up locating them,

the linker will tell me about section overlaps.

They will also serve somewhat as documentation.

 

Experiment suggests that the above will do what I want,

even though it's telling the toolchain to put zeros in a place with no bits.

 

Is it a fluke?

Is it something that should be relied on to work in the future?

 

So far, I've not found an explicit statement that combining

@nobits and data-generating instructions is even valid.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

skeeve wrote:
Given the way data is initialized on AVRs,

.zero vs reality

Let's indeed have a reality check here -- I think you meant "given the way that the infinite-value toolchain that supports AVR targets carries out C prologue operations" or similar.  Anything else would be ... imaginary.

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'd create the "empty" (I assume that really means 0xFF) sections "after the fact" by post processing the HEX with SRecord.

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

I would simply omit exporting that sections into the Hex file during the Elf-to-Hex step.

Stefan Ernst

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

Actually Stefan is (of course ;-) right. As programming presumably starts with a chip erase then anything that simply isn't programmed is "empty".

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

sternst wrote:
I would simply omit exporting that sections into the Hex file during the Elf-to-Hex step.
Good suggestion.

Doesn't answer my questions,

but 'tis useful for my purpose.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Isn't .noinit explicitly for RAM?  Variables treated like .data, that you want neither zeroed nor copied from flash at startup...

I don't know if you can apply it at the same time as putting the variables in flash; using a named subsection of .progmem and not exporting it sounds much more applicable.