Patch avrtest: add support for avr6

[Tristan Gingold-2]

Hi,

this little avrtest patch add support for EICALL/EIJMP.

Does it make sense to add a '-m arch' flag to select between AVR  
architectures ?
(Selecting behaviour according to program size is bogus)

Tristan.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Tristan Gingold
> Sent: Monday, May 26, 2008 7:57 AM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] Patch avrtest: add support for avr6
>
> Hi,
>
> this little avrtest patch add support for EICALL/EIJMP.
>
> Does it make sense to add a '-m arch' flag to select between AVR  
> architectures ?

If a flag is added, I would prefer that we keep the flag naming
consistent between all the tools when possible. AVR GCC uses the flag
-mmcu=<device>, where <device> can be a named AVR device in lowercase or
"architecture" like "avr6".

Upon review, I'd be ok with '-m arch' too.

I think that it would be good to add this switch as it would help with
testing different devices/architectures in the future. These differenct
architectures typically select different instruction sets. It would be
good to know if a specific architecture is broken wrt the gcc regression
tests.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On May 26, 2008, at 4:00 PM, Weddington, Eric wrote:
> If a flag is added, I would prefer that we keep the flag naming
> consistent between all the tools when possible. AVR GCC uses the flag
> -mmcu=<device>, where <device> can be a named AVR device in  
> lowercase or
> "architecture" like "avr6".
>
> Upon review, I'd be ok with '-m arch' too.

Why not -mmcu=<dev> or -m arch.
I don't think we should support AVR devices as we only support cores,  
not IOs.

> I think that it would be good to add this switch as it would help with
> testing different devices/architectures in the future. These  
> differenct
> architectures typically select different instruction sets. It would be
> good to know if a specific architecture is broken wrt the gcc  
> regression
> tests.

Ok.
Which architecture should we support ?
avr2/25/3/31/35/4/5/51/6 ?

Tristan.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From: Tristan Gingold [mailto:gingold@...]
> Sent: Monday, May 26, 2008 8:14 AM
> To: avr-gcc-list@...
> Cc: Weddington, Eric
> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6
>
>
> On May 26, 2008, at 4:00 PM, Weddington, Eric wrote:
> > If a flag is added, I would prefer that we keep the flag naming
> > consistent between all the tools when possible. AVR GCC
> uses the flag
> > -mmcu=<device>, where <device> can be a named AVR device in  
> > lowercase or
> > "architecture" like "avr6".
> >
> > Upon review, I'd be ok with '-m arch' too.
>
> Why not -mmcu=<dev> or -m arch.
> I don't think we should support AVR devices as we only
> support cores,  
> not IOs.

I agree that only archs need to be supported. I was originally thinking
that it would be nice if -mmcu=<dev> with a devicename could be
supported and then the device name would just be mapped into the
relevant architecture. The devicename could also be the arch name as
well, like it's done in avr-gcc. But I didn't want to take advantage of
your and Adacore's goodwill in helping to add support for all this. :-)
I'll leave it up to you as to the extent you want to provide.

>
> Ok.
> Which architecture should we support ?
> avr2/25/3/31/35/4/5/51/6 ?

Ideally, in the future, all archs. But I know that that will take some
time. The ATmega128 is the "canonical" AVR device that everyone seems to
do basic testing with, or compare results to. IIRC, it currently falls
under the avr51 architecture.

In the end, we all appreciate the help that you're doing in extending
the capabilities of this tool.

Eric


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

Hi,

it has been a while since I didn't update my patch.
Here is the new version.  It adds a new switch: -mmcu=X, where X can  
be avr51 (default) or avr6.

The switch selects an architecture which describes features of the  
processor.
The maximum memory size now depends on the architecture.

Tristan.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Paulo Marques]

Tristan Gingold wrote:
> Hi,

Hi, Tristan

> it has been a while since I didn't update my patch.
> Here is the new version.  It adds a new switch: -mmcu=X, where X can be
> avr51 (default) or avr6.

Nice :)

> The switch selects an architecture which describes features of the
> processor.
> The maximum memory size now depends on the architecture.

Overall it seems fine, but I have a few comments (see below)

> Index: avrtest.c
> ===================================================================
> RCS file: /cvsroot/winavr/avrtest/avrtest.c,v
> retrieving revision 1.7
> diff -c -r1.7 avrtest.c
> *** avrtest.c 5 Jun 2008 04:07:27 -0000 1.7
> --- avrtest.c 17 Jun 2008 20:18:02 -0000
> ***************
> *** 29,38 ****
>   #include <stdint.h>
>  
>   // ---------------------------------------------------------------------------------
> ! //     configuration values
>  
>   #define MAX_RAM_SIZE 64 * 1024
> ! #define MAX_FLASH_SIZE  256 * 1024
>  
>   // ---------------------------------------------------------------------------------
>   //     register and port definitions
> --- 29,38 ----
>   #include <stdint.h>
>  
>   // ---------------------------------------------------------------------------------
> ! //     configuration values (in bytes).
>  
>   #define MAX_RAM_SIZE 64 * 1024
> ! #define MAX_FLASH_SIZE  256 * 1024 // Must be at least 128KB
>  
>   // ---------------------------------------------------------------------------------
>   //     register and port definitions
> ***************
> *** 63,68 ****
> --- 63,88 ----
>   #define FLAG_Z 0x02
>   #define FLAG_C 0x01
>  
> + struct arch_desc {
> + // Name of the architecture.
> + const char *name;
> + // True if PC is 3 bytes, false if only 2 bytes.
> + unsigned int pc_3bytes : 1;
> + // True if the architecture has EIND related insns (EICALL/EIJMP).
> + unsigned int has_eind : 1;
> + };

I don't know if it makes sense to use bit fields here, because there
might be a performance penalty in accessing them and "pc_3bytes" is
accessed a few times while executing avr code.

> + // List of supported archs with their features.
> + const struct arch_desc arch_descs[] =
> + {
> + { "avr51", 0, 0},
> + { "avr6", 1, 1},
> + { NULL, 0, 0}
> + };

It would probably bew easier to read these structures if they were
written like:

const struct arch_desc arch_descs[] = {
   {
     .name = "avr51",
     .pc_3_bytes = 0,
     .has_eind = 0,
   },
   {
     .name = "avr6",
     .pc_3_bytes = 1,
     .has_eind = 1,
   },
   { NULL, 0, 0}
};

I know its more verbose, but if we keep adding flags it will become
impossible to understand what { "avr51", 0, 0, 1, 0, 1, 1, 0 } means ;)

> + const struct arch_desc *arch = &arch_descs[0];
> +
> +

[...]

> --- 1576,1631 ----
>   {
>   int i;
>  
>   //max_instr_count = 1000000000;
>   max_instr_count = 0;
>  
>   // parse command line arguments
>   for (i = 1; i < argc; i++) {
> ! //  Use naive but very portable method to decode arguments.
> ! if (strcmp(argv[i], "-d") == 0) {
> ! flag_initialize_sram = 1;
> ! }
> ! else if (strcmp(argv[i], "-m") == 0) {
> ! i++;
> ! if (i >= argc)
> ! usage();
> ! max_instr_count = strtoul(argv[i], NULL, 0);
> ! }
> ! else if (strncmp(argv[i], "-mmcu=", 6) == 0) {
> ! const struct arch_desc *d;
> ! for (d = arch_descs; d->name; d++)
> ! if (strcmp(argv[i] + 6, d->name) == 0) {
> ! arch = d;
> ! break;
> ! }
> ! if (d->name == NULL)
>   usage();

You forgot to update usage() to reflect the new options, no?

>   }
>   else {
> ! if (program_name != NULL)
>   usage();
> + load_to_flash(argv[i]);
> + // Must be the last argument.
> + if (i + 1 != argc)
> + usage ();

I don't think we need to restrict the program name to be the last argument.

>   }
>   }
>  
> ! // setup default values
> ! flash_addr_mask = (arch->pc_3bytes ? MAX_FLASH_SIZE : (1 << 16)) - 1;

flash_addr_mask is in bytes, so to keep the previous default 128kB this
should be "(1 << 17) - 1", no?

 > [...]

Anyway, overall this seems like a nice simple structure to add more
architectures and features in the future.

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: [phone], Fax: [phone]
Web: www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On Jun 18, 2008, at 8:14 AM, Paulo Marques wrote:

Hi Paulo,

thank you for the quick review.

>
> I don't know if it makes sense to use bit fields here, because  
> there might be a performance penalty in accessing them and  
> "pc_3bytes" is accessed a few times while executing avr code.

Changed to unsigned char.

>
>> + // List of supported archs with their features.
>> + const struct arch_desc arch_descs[] =
>> + {
>> + { "avr51", 0, 0},
>> + { "avr6", 1, 1},
>> + { NULL, 0, 0}
>> + };
>
> It would probably bew easier to read these structures if they were  
> written like:
>
> const struct arch_desc arch_descs[] = {
>   {
>     .name = "avr51",
>     .pc_3_bytes = 0,
>     .has_eind = 0,
>   },
>   {
>     .name = "avr6",
>     .pc_3_bytes = 1,
>     .has_eind = 1,
>   },
>   { NULL, 0, 0}
> };
>
> I know its more verbose, but if we keep adding flags it will become  
> impossible to understand what { "avr51", 0, 0, 1, 0, 1, 1, 0 }  
> means ;)

I agree.

>
> You forgot to update usage() to reflect the new options, no?

Oops, you're right.

> I don't think we need to restrict the program name to be the last  
> argument.

Ok.

>
>>   }
>>   }
>>   ! // setup default values
>> ! flash_addr_mask = (arch->pc_3bytes ? MAX_FLASH_SIZE : (1 <<  
>> 16)) - 1;
>
> flash_addr_mask is in bytes, so to keep the previous default 128kB  
> this should be "(1 << 17) - 1", no?

Oops, you're right.  Thank you for catching this!

> Anyway, overall this seems like a nice simple structure to add more  
> architectures and features in the future.

Attached is the updated patch.

Thanks,
Tristan.

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

Hi Paulo,

do you agree on this new version of the patch ?

Tristan.

On Jun 18, 2008, at 9:59 AM, Tristan Gingold wrote:

>
> On Jun 18, 2008, at 8:14 AM, Paulo Marques wrote:
>
> Hi Paulo,
>
> thank you for the quick review.
>
>>
>> I don't know if it makes sense to use bit fields here, because  
>> there might be a performance penalty in accessing them and  
>> "pc_3bytes" is accessed a few times while executing avr code.
>
> Changed to unsigned char.
>
>>
>>> + // List of supported archs with their features.
>>> + const struct arch_desc arch_descs[] =
>>> + {
>>> + { "avr51", 0, 0},
>>> + { "avr6", 1, 1},
>>> + { NULL, 0, 0}
>>> + };
>>
>> It would probably bew easier to read these structures if they were  
>> written like:
>>
>> const struct arch_desc arch_descs[] = {
>>   {
>>     .name = "avr51",
>>     .pc_3_bytes = 0,
>>     .has_eind = 0,
>>   },
>>   {
>>     .name = "avr6",
>>     .pc_3_bytes = 1,
>>     .has_eind = 1,
>>   },
>>   { NULL, 0, 0}
>> };
>>
>> I know its more verbose, but if we keep adding flags it will  
>> become impossible to understand what { "avr51", 0, 0, 1, 0, 1, 1,  
>> 0 } means ;)
>
> I agree.
>
>>
>> You forgot to update usage() to reflect the new options, no?
>
> Oops, you're right.
>
>> I don't think we need to restrict the program name to be the last  
>> argument.
>
> Ok.
>
>>
>>>   }
>>>   }
>>>   ! // setup default values
>>> ! flash_addr_mask = (arch->pc_3bytes ? MAX_FLASH_SIZE : (1 <<  
>>> 16)) - 1;
>>
>> flash_addr_mask is in bytes, so to keep the previous default 128kB  
>> this should be "(1 << 17) - 1", no?
>
> Oops, you're right.  Thank you for catching this!
>
>> Anyway, overall this seems like a nice simple structure to add  
>> more architectures and features in the future.
>
> Attached is the updated patch.
>
> Thanks,
> Tristan.<avr6.diff>_______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Tristan Gingold
> Sent: Wednesday, June 25, 2008 1:32 AM
> To: Paulo Marques
> Cc: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6 (Ping)
>
> Hi Paulo,
>
> do you agree on this new version of the patch ?
>

Hi Tristan,

Could you provide me a quick ChangLog entry for this patch?

I'll see about getting it committed.

Eric Weddington


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

Is this one OK ?

Tristan.

2008-06-26  Tristan Gingold  <gingold@...>

        * avrtest.c: Add support for multiple architecture.  Add command-line
        option -mmcu=ARCH to select the architecture.  Help updated.
        Add support for avr6 instructions: eijmp, eicall.



On Jun 25, 2008, at 11:34 AM, Weddington, Eric wrote:

>
>
>> -----Original Message-----
>> From:
>> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
>> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
>> org] On Behalf Of Tristan Gingold
>> Sent: Wednesday, June 25, 2008 1:32 AM
>> To: Paulo Marques
>> Cc: avr-gcc-list@...
>> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6  
>> (Ping)
>>
>> Hi Paulo,
>>
>> do you agree on this new version of the patch ?
>>
>
> Hi Tristan,
>
> Could you provide me a quick ChangLog entry for this patch?
>
> I'll see about getting it committed.
>
> Eric Weddington
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Paulo Marques]

Tristan Gingold wrote:
> Hi Paulo,

Hi, Tristan.

Sorry for the delay, but I've been on vacation this past week and I'm
just starting to catch up with my mail queue. I had ~6000 mails waiting
(not counting spam) :P

> do you agree on this new version of the patch ?

Yes, it seems fine. Thanks a lot for all your contributions :)

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: [phone], Fax: [phone]
Web: www.grupopie.com

"There cannot be a crisis today; my schedule is already full."


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On Jun 30, 2008, at 12:52 PM, Paulo Marques wrote:

> Tristan Gingold wrote:
>> Hi Paulo,
>
> Hi, Tristan.
>
> Sorry for the delay, but I've been on vacation this past week and  
> I'm just starting to catch up with my mail queue. I had ~6000 mails  
> waiting (not counting spam) :P

Hi,

no problems.  Maybe there are 6000 contributions pending :-)


>> do you agree on this new version of the patch ?
>
> Yes, it seems fine. Thanks a lot for all your contributions :)

You're welcome.  avrtest was really useful to us.

Tristan.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

Eric,

did you miss my previous mail ?  It seems this is not yet committed.

Thanks,
Tristan.

On Jun 26, 2008, at 1:50 PM, Tristan Gingold wrote:

> Is this one OK ?
>
> Tristan.
>
> 2008-06-26  Tristan Gingold  <gingold@...>
>
> * avrtest.c: Add support for multiple architecture.  Add command-line
> option -mmcu=ARCH to select the architecture.  Help updated.
> Add support for avr6 instructions: eijmp, eicall.
>
>
>
> On Jun 25, 2008, at 11:34 AM, Weddington, Eric wrote:
>
>>
>>
>>> -----Original Message-----
>>> From:
>>> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
>>> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
>>> org] On Behalf Of Tristan Gingold
>>> Sent: Wednesday, June 25, 2008 1:32 AM
>>> To: Paulo Marques
>>> Cc: avr-gcc-list@...
>>> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6  
>>> (Ping)
>>>
>>> Hi Paulo,
>>>
>>> do you agree on this new version of the patch ?
>>>
>>
>> Hi Tristan,
>>
>> Could you provide me a quick ChangLog entry for this patch?
>>
>> I'll see about getting it committed.
>>
>> Eric Weddington
>>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric-2]

My apologies!

I was on holiday for a couple of weeks and recently came back. Thanks for the ping!

Committed.

Eric Weddington

> -----Original Message-----
> From: Tristan Gingold [mailto:gingold@...]
> Sent: Tuesday, July 22, 2008 7:10 AM
> To: Weddington, Eric
> Cc: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6 (Ping)
>
> Eric,
>
> did you miss my previous mail ?  It seems this is not yet committed.
>
> Thanks,
> Tristan.
>
> On Jun 26, 2008, at 1:50 PM, Tristan Gingold wrote:
>
> > Is this one OK ?
> >
> > Tristan.
> >
> > 2008-06-26  Tristan Gingold  <gingold@...>
> >
> > * avrtest.c: Add support for multiple architecture.  
> Add command-line
> > option -mmcu=ARCH to select the architecture.  Help updated.
> > Add support for avr6 instructions: eijmp, eicall.
> >
> >
> >
> > On Jun 25, 2008, at 11:34 AM, Weddington, Eric wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From:
> >>> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
> >>> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
> >>> org] On Behalf Of Tristan Gingold
> >>> Sent: Wednesday, June 25, 2008 1:32 AM
> >>> To: Paulo Marques
> >>> Cc: avr-gcc-list@...
> >>> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6  
> >>> (Ping)
> >>>
> >>> Hi Paulo,
> >>>
> >>> do you agree on this new version of the patch ?
> >>>
> >>
> >> Hi Tristan,
> >>
> >> Could you provide me a quick ChangLog entry for this patch?
> >>
> >> I'll see about getting it committed.
> >>
> >> Eric Weddington
> >>
> >
> >
> >
> > _______________________________________________
> > AVR-GCC-list mailing list
> > AVR-GCC-list@...
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> >
>
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On Jul 22, 2008, at 3:21 PM, Weddington, Eric wrote:

>
> My apologies!
>
> I was on holiday for a couple of weeks and recently came back.  
> Thanks for the ping!
>
> Committed.

Thanks!

Tristan.

>
> Eric Weddington
>
>> -----Original Message-----
>> From: Tristan Gingold [mailto:gingold@...]
>> Sent: Tuesday, July 22, 2008 7:10 AM
>> To: Weddington, Eric
>> Cc: avr-gcc-list@...
>> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6  
>> (Ping)
>>
>> Eric,
>>
>> did you miss my previous mail ?  It seems this is not yet committed.
>>
>> Thanks,
>> Tristan.
>>
>> On Jun 26, 2008, at 1:50 PM, Tristan Gingold wrote:
>>
>>> Is this one OK ?
>>>
>>> Tristan.
>>>
>>> 2008-06-26  Tristan Gingold  <gingold@...>
>>>
>>> * avrtest.c: Add support for multiple architecture.
>> Add command-line
>>> option -mmcu=ARCH to select the architecture.  Help updated.
>>> Add support for avr6 instructions: eijmp, eicall.
>>>
>>>
>>>
>>> On Jun 25, 2008, at 11:34 AM, Weddington, Eric wrote:
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From:
>>>>> avr-gcc-list-bounces+eweddington=cso.atmel.com@...
>>>>> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com@nongnu.
>>>>> org] On Behalf Of Tristan Gingold
>>>>> Sent: Wednesday, June 25, 2008 1:32 AM
>>>>> To: Paulo Marques
>>>>> Cc: avr-gcc-list@...
>>>>> Subject: Re: [avr-gcc-list] Patch avrtest: add support for avr6
>>>>> (Ping)
>>>>>
>>>>> Hi Paulo,
>>>>>
>>>>> do you agree on this new version of the patch ?
>>>>>
>>>>
>>>> Hi Tristan,
>>>>
>>>> Could you provide me a quick ChangLog entry for this patch?
>>>>
>>>> I'll see about getting it committed.
>>>>
>>>> Eric Weddington
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AVR-GCC-list mailing list
>>> AVR-GCC-list@...
>>> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>>>
>>
>>
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[hanward]

Hello,all.we are a PCB manufacturer.Material:FR-4,aluminium,FPC.Layer: 1-10,thickness:0.4-4.2mm,min.Line/Space:0.1mm,min.hole:0.1mm,inculding burried/blind hole.Both prototype and mass production are welcome.Details pls send me email by [e-mail] or contact me at:
Contacting:Hanward Jiang

Marketing Dept.Manager
Cirket Electronics Company
22A,Block B,Nanhai Bldg,Nanshan Rd,
Shenzhen,P.R.China
Tel:[phone]
Fax:[phone]
MSN:[e-mail]
Skype: hanward
Website:www.szckt.cn

Wish we can support you.

Tristan Gingold-2 wrote:

Hi,

this little avrtest patch add support for EICALL/EIJMP.

Does it make sense to add a '-m arch' flag to select between AVR  
architectures ?
(Selecting behaviour according to program size is bogus)

Tristan.


 
_______________________________________________
AVR-GCC-list mailing list
[e-mail]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list