Instruction set compatibility question

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

Hello community!

 

If my project uses an ATmega chip, can I use a static library (.a) that was compiled for ATtiny device and vice versa?

Section 4, Instruction Set Summary, of the AVR instruction set manual says that "Machine code level of compatibility is intact for all CPU versions with a very few exceptions related to the Reduced Core (AVRrc), though not all instructions are included in the instructions set for all devices," but I am curious how an AVR core handles an instruction that is only included in a the instruction set for a bigger core.

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

Even if the instruction sets were 100% identical, which they aren't (some tinies miss instructions like mul, or even registers), I wouldn't be surprised if it failed, there are other architectural differences.

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

Yeah... there must be a reason why you need to specify the mcu model but the instruction set in the compiler option.

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

I think there are 17 or it could be 18 CPU architectures which is why AVR-LibC comes with 17 copies of libc.a, 17 copies of libm.a and so on. While it's true that you could maybe use the least common denominator for most things (the 16 not 32 register CPU with no MUL, no CALL, no JMP etc) it would be very sad to have a complex core such as atmega2560 and force it to use the subset. But you still face some issues like 16 versus 24 bit CALL and so on.
.
This is why almost no one using AVR ever uses static libraries. In fact I think libc.a, libm.a, libgcc.a in AVR-LibC may be the only common use.
.
Just share source and let the user build it for the right target.
.
I think if you encode something like an EICALL or even a MUL and feed it to a Tiny it'll probably just execute as a NOP (the simulator may help to explore this).

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

Thank you for your insight! I've been working on my company's software folder structure for couple weeks now, and honestly I think building the source for each project shouldn't really break it anyways.

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

Give an example of a meaningful AVR8 "library" that doesn't deal with any I/O registers (that includes I/O pins).  IME each design maty well be different with at least different pins.  Pure math stuff?  I'd think that would already be covered by the toolchain.

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

Yes, pure math stuff or simple variable manipulation. For example, I wrote .c and .h file for my I2C compass chip. The code has a definition of an extern struct that contains a few variables, and all the functions in the code do is to change the variables with the corresponding commands, so that the project that uses this code can call these functions.

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

But different AVR have their TWI registers at different addresses so you couldn't really precompile anyway unless you are suggesting dynamically passing register pointers into the support code?

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

At least in my case, the compass doesn't really need to know of the AVR register address, as the AVR chip always stays as the comm master. As long as the main project code has knowledge of the compass support code, the code should work.