used instructions

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

Are there an way to see how many times an instruction are used?
I can't remember where but here in the forum I have seen a list like that I think it was made by CV.

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

Quote:

I have seen a list like that I think it was made by CV.

Actually it's the Atmel assembler that does it but CV just invokes that assembler as the last step of compilation which is why you see it there too.

No, I don't believe there's such an option in the Atmel tools but it would be fairly easy to write one if one already had access to an AVR disassembler. avr-objdump obviously contains an AVR disassembler so that could presumably be "hacked" to have a mode where it disassembles (to null) and just counts the opcodes it's listing?

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

ok thanks
I would not spend time if it existed.
It will only solve half of my problem.

I was looking into if it made sense to compress data for a bootloader.
A simple zip test made the code go from about 19k to 7k5. but I would see what happen if just take the most used instructions (that always have the same opcode).

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

Quote:

but I would see what happen if just take the most used instructions (that always have the same opcode).

A Huffman compression might work well.

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

AVR program words tend to have both OPCODE and OPERAND in the same 16-bits. So a LDI r24,1 is a different word to LDI r24,2

If you are looking at the 16-bit words as 8-bit bytes, you will get a few more matches.

I doubt if you would gain much, but you could go through your projects and create .BIN instead of .HEX

Then use several compression algorithms and see the results.

You will probably find GCC, CV, ASM binaries will compress differently. And different authors will produce different results too.

Any decompression will add complexity to a bootloader. This may be worth the effort if you have already exceeded 256 words and have plenty of room in a 512 word boot section.

A HEX file or any ascii ASM file will compress very well with zip.
I doubt if a BIN file gets dramatic results.

David.

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

yes
but because GCC repeats the same instructions over and over again (like in and out from R25:R24), I wanted to see what happen if I just make something like 15 "instructions" and let the last combination just be the rest.
An other way could be bigger code combinations 4-8(or more) byte where some of the bit aren't fixed but more than 80% are.

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

To David my numbers is for binary, who would use anything different to a bootloader?

And there is a reason why this are in the GCC forum :)

add:
and I would write the bootloader in ASM, but load GCC code.

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

I would upload a HEX file via the bootloader.
HEX files are almost universal as microcontroller format.

Regarding opcode sequences. CV compresses the binary file by replacing sequences with subroutine calls.

What do you want to achieve?
1. small boot section
2. small size of object BIN on your hard disk
3. transmit BIN over phone or radio link
4. speed of upload via bootloader
5. speed of application
6. size of application.

CV with its compression can often fit a C app in a tiny2313, but you sacrifice speed.

The Optiboot bootloader on a UNO achieves a comfortable balance between application space and boot space.

David.

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

Quote:

I would upload a HEX file via the bootloader.

But then you need the complexity of an iHex decoder in the bootloader? The usual idea is to keep the bootloader as small as simple as possible. If you do include an iHex decoder then does it handle sparse files, out of order records, overlapping records, etc.

It's surely far better to use powerful tools on the PC to resolve the intricacies of iHex and just output a plain .bin image? All it lacks is a mechanism to embed the start address and length/end point but the bootloader protocol can send this separately.

Oh and on the subject of modifying avr-objdump. Looking at the source it appears the core of the AVR disassembler is here:

https://sourceware.org/git/gitwe...

with the opcode definitions coming from:

https://sourceware.org/git/gitwe...

I'd imagine it would be fairly possible to have it "count" the opcodes as it outputs them. In fact one could add a "count" field to this struct:

https://sourceware.org/git/gitwe...

Increment each time an entry is accessed and at the end print out a summary report of the insn's/counts.

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

Besides, a hex file is more than twice the size it needs to be. Use the computer that's best for the task and let that supercomputer you're looking at, you call it a "PC," deal with all this and simplify the file you need to send to the bootloader.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Torby:
Pleace read the thread :)

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

sparrow2 wrote:
ok thanks
I was looking into if it made sense to compress data for a bootloader.

If it is to reduce download time, you could go with a higher baud rate. With a soft UART you can get under 1% timing error at 230.4kbps (35 cycles/bit vs 34.72).

Beyond 230.4kbps there's diminishing returns, since the 8-9ms for page erase/write takes longer than the ~6ms to transfer a 128-byte page.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

My main problem is that I'm trying to make an easy way to update a existing system, where the communication is slow.