avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: [avr-gcc-list] ATTiny2313 GCC Support? (fwd)


From: Bob Paddock
Subject: Re: [avr-libc-dev] Re: [avr-gcc-list] ATTiny2313 GCC Support? (fwd)
Date: Sun, 30 Jan 2005 18:35:56 -0500
User-agent: KMail/1.7.2

On Sunday 30 January 2005 04:46 pm, Joerg Wunsch wrote:
> As Bob Paddock wrote:
> > Thank you.  Looks like I need to make a patch for the patches?
>
> If at all, then redo the patch, and submit it as a followup item to
> the (closed) patch tracker.

Ok.  I have attached it for others to look it over.  
binutils-2.15.92.0.2 needs a different patch than binutils-2.15,
I do not know what happened between those two versions, as
to when the tiny2313 stuff was put in.   Isn't there some-kind of paper
work issue about submitting patches to binutils and gcc?

> You have to dig into GCC for this.  If I were you, I'd try to use the
> existing code as a template for this.

I have been doing that this afternoon.  I figured I could copy AVR4
to AVR6 then cut out the multiply instruction.

So far I'm a bit stymied by the function in gas/bfd/cpu-avr.c,
I have not traced down where these two different arch's are
being input from, because this supposition "So far all newer AVR architecture 
cores are supersets of previous cores" is no longer true.

 Also have not figure out how to cut out the multiply instruction.
There must be some generic instruction on how to add a new target
to gas and GCC "out there"?

/* This routine is provided two arch_infos and works out which AVR
   machine which would be compatible with both and returns a pointer
   to its info structure.  */

static const bfd_arch_info_type *
compatible (a,b)
     const bfd_arch_info_type * a;
     const bfd_arch_info_type * b;
{
  /* If a & b are for different architectures we can do nothing.  */
  if (a->arch != b->arch)
    return NULL;

  /* Special case for ATmega[16]03 (avr:3) and ATmega83 (avr:4).  */
  if ((a->mach == bfd_mach_avr3 && b->mach == bfd_mach_avr4)
      || (a->mach == bfd_mach_avr4 && b->mach == bfd_mach_avr3))
    return NULL;

  /* So far all newer AVR architecture cores are supersets of previous
     cores.  */
  if (a->mach <= b->mach)
    return b;

  if (a->mach >= b->mach)
    return a;

  /* Never reached!  */
  return NULL;
}

>
> > avr1 Simple CPU core, only assembler support
> > avr2 "Classic" CPU core, up to 8 KB of ROM
> > avr3 "Classic" CPU core, more than 8 KB of ROM
> > avr4 "Enhanced" CPU core, up to 8 KB of ROM
> > avr5 "Enhanced" CPU core, more than 8 KB of ROM
>
> While you are at it, consider the ATmega256 as well (more than 64
> KWords of instruction ROM). ;-)

I have the ATmega256(0) datasheet at hand.   That will have to be
AVR7 because of the seventeen bit PC and stack? 

There is a lot of code that is going to break  because of the assumption that
unsigned short and unsigned short * are of the same length (something that the 
first K&R book told us not to do a couple of decades ago, do we ever learn?). 
How is avr-libc in that area?


-- 
                          http://www.softwaresafety.net/
 http://www.unusualresearch.com/ http://www.bpaddock.com/

Attachment: gcc-3_4_0-avr-tiny2313-fix.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]