Getting started with AVR and C

On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:

> Grant did not include all of the context, so you need to read back a bit.
>
> The original statement was that (a) int16_t * int16_t coughs up a 16-bit 
> result, unless (b) one of the int16_t numbers is cast to 32 bit.
>
> Then I pointed out that (c) there are some older, non-compliant compilers 
> where you have to cast _both_ 16-bit operands to 32 bits to get a 32 bit 
> result, and (d) that I trusted that the gcc compiler was ANSI C 
> compliant.  Statement (c) is important for the embedded space (which is 
> the group that I am replying from -- you must be from comp.lang.c) 
> because one does not always have the luxury of using a compliant tool 
> chain in embedded.

I misread part of your post as claiming that even without casts a
compliant compiler would promote both 16-bit operands to 32-bits.  I
was attempting to point out that isn't true if an "int" is 16-bits
(it's a not-uncommon misapprehension that gcc is only available with
32 or 64 bit ints).


> Then Grant came in, and if I'm correctly reading what he said, stated 
> that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16 
> bit integers.

Ah, that's not what I intended to write.  AFAICT, everybody agrees
with everybody else, we just aren't managing to express that clearly.

-- 
Grant Edwards               grant.b.edwards        Yow! People humiliating
                                  at               a salami!
                              gmail.com            

On 2012-11-29, Tim Wescott <tim@seemywebsite.please> wrote:
> On Wed, 28 Nov 2012 23:39:52 -0500, James Kuyper wrote:
>
>> On 11/28/2012 07:29 PM, Tim Wescott wrote:
>> ...
>>> Grant did not include all of the context, so you need to read back a
>>> bit.
>>> 
>>> The original statement was that (a) int16_t * int16_t coughs up a
>>> 16-bit result, unless (b) one of the int16_t numbers is cast to 32 bit.
>>> 
>>> Then I pointed out that (c) there are some older, non-compliant
>>> compilers where you have to cast _both_ 16-bit operands to 32 bits to
>>> get a 32 bit result, and (d) that I trusted that the gcc compiler was
>>> ANSI C compliant.  Statement (c) is important for the embedded space
>>> (which is the group that I am replying from -- you must be from
>>> comp.lang.c) because one does not always have the luxury of using a
>>> compliant tool chain in embedded.
>>> 
>>> Then Grant came in, and if I'm correctly reading what he said, stated
>>> that (e) the gnu-avr compiler is not ANSI-C compliant because it has 16
>>> bit integers.
>> 
>> Sort-of, but not quite. When he said "Nope", he wasn't referring to your
>> expectation that gcc-avr was ANSI compliant. He was referring to your
>> expectation that it would promote 16-bit integers to 32 bits. On a
>> conforming implementation of C with 16-bit ints, promotion of integer
>> types halts at 16 bits, and goes no further.
>
> How can you possibly know?  Do you read his mind?  Have an uncited 
> conversation with him?  Is he your sock-puppet?

That is indeed what I meant.

-- 
Grant Edwards               grant.b.edwards        Yow! Now KEN and BARBIE
                                  at               are PERMANENTLY ADDICTED to
                              gmail.com            MIND-ALTERING DRUGS ...

On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:

> Me, I just try to remember that x, y or z went wrong on some compiler 
> some time, so that if I see symptoms again those problems are on my short 
> list, and maybe even a fix or two.
>
> Like Texas Instrument's Code Composter for the TMS320F2812, which has a 
> 32-bit "double".  #$%@.

Or on the TMS320C40, where char, int, long, long long, float and
double are all 32 bits and all have a sizeof() 1.  Trying to impliment
any sort of communications protocol with that was fun.

-- 
Grant Edwards               grant.b.edwards        Yow! Is it NOUVELLE
                                  at               CUISINE when 3 olives are
                              gmail.com            struggling with a scallop
                                                   in a plate of SAUCE MORNAY?

On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:

> It's certainly what I would expect from gcc-avr.  There's no reason you 
> can't make a beautifully compliant, reasonably efficient compiler that 
> works well on the AVR.

avr-gcc does indeed work very nicely as long as you don't look at the
code generated when you use pointers.  You'll go blind -- especially
if you're used to something like the msp430.  It's easy to forget that
the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
16-bit pointers on the AVR requires a lot of overhead.

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I could
                                  at               ever get started in the
                              gmail.com            credit world?

On 11/29/2012 10:23 AM, Grant Edwards wrote:
> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
>> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:
> 
>> Me, I just try to remember that x, y or z went wrong on some compiler 
>> some time, so that if I see symptoms again those problems are on my short 
>> list, and maybe even a fix or two.
>>
>> Like Texas Instrument's Code Composter for the TMS320F2812, which has a 
>> 32-bit "double".  #$%@.
> 
> Or on the TMS320C40, where char, int, long, long long, float and
> double are all 32 bits and all have a sizeof() 1. ...

There's a key difference there. The implementation you describe could be
fully conforming. The one he described could not; you can't meet the
standard's precision and range requirements for double with a 32-bit
data type.

> ...  Trying to impliment
> any sort of communications protocol with that was fun.

Thanks for that information. Claims have frequently been made on
comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
existence of such implementations is a myth. I'm glad to have a specific
counter example to cite.
There's something I've wondered about such machines: when data from
other machines containing data types smaller than 32 bits (for instance,
ASCII text files) is transferred to the TMS320C40,  how is this usually
handled? I could imagine three main possibilities:

a) Four 8-bit bytes of data are packed into each 32-bit byte
b) Each field value stored in a data type smaller than 32 bits is
converted to a 32-bit type, and stored as such. For instance, a file
containing 45,678 8-bit bytes of text gets converted into a file
containing 45,678 32-bit bytes of text.
c) Different methods are used in different contexts, leading to constant
headaches. This strikes me as the most likely possibility.
-- 
James Kuyper

Grant Edwards <invalid@invalid.invalid> writes:

> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
>
>> It's certainly what I would expect from gcc-avr.  There's no reason you 
>> can't make a beautifully compliant, reasonably efficient compiler that 
>> works well on the AVR.
>
> avr-gcc does indeed work very nicely as long as you don't look at the
> code generated when you use pointers.  You'll go blind -- especially
> if you're used to something like the msp430.  It's easy to forget that
> the AVR is an 8-bit CPU not a 16-bit CPU like the '430, and use of
> 16-bit pointers on the AVR requires a lot of overhead.

Other problem with it is the separate program and data memory
spaces. Fine for small deeply embedded things but started to show strain
when I wanted a LCD display, menus etc. I would not use it for a new
project unless there was a very good reason, ultra-low power
perhaps. Cortex M3 is much nicer but the chips are much more complicated
of course.


-- 

John Devereux

On Thu, 29 Nov 2012 07:57:48 -0500, James Kuyper wrote:

> On 11/29/2012 01:59 AM, Tim Wescott wrote:
>> On Wed, 28 Nov 2012 23:39:52 -0500, James Kuyper wrote:
>> 
>>> On 11/28/2012 07:29 PM, Tim Wescott wrote:
> ...
>>> Sort-of, but not quite. When he said "Nope", he wasn't referring to
>>> your expectation that gcc-avr was ANSI compliant. He was referring to
>>> your expectation that it would promote 16-bit integers to 32 bits. On
>>> a conforming implementation of C with 16-bit ints, promotion of
>>> integer types halts at 16 bits, and goes no further.
>> 
>> How can you possibly know?  Do you read his mind?  Have an uncited
>> conversation with him?  Is he your sock-puppet?
> 
> I can read and understand English, and in particular, the specialized
> dialect of it which is sometimes called "standardese". I understood
> precisely what he was talking about. In particular, I understand what
> "promotion" means in the context of the C standard, and know that you
> used the term incorrectly, something which you still do not seem to have
> understood - nothing in your comments indicates any awareness that this
> is the issue we're both talking about.

Well, I thought we were talking useful people writing good code using C.  
Useful people who want to write good code using C don't always use 
correct "standardese", but they do know how to read all the pertinent 
documentation.

Had you gone back and read said pertinent documentation you would have 
done a "useful people" sort of thing, and realized what _my_ point was 
about, regardless of any misuse of terminology on my part.

But hey -- I'm just a guy who designs embedded systems that actually make 
money for my customers.  One of the skills that requires is listening to 
people and not trying to slam them for violating some trivial rule of 
terminology when they're getting the gist of their statements right.

>>> It was that first quote from you that I'm correcting. Not any other
>>> statement. Specifically:
>>>
>>>> I would expect that gcc would be ANSI compliant, and would therefore
>>>> promote both 16-bit integers to 32-bit before doing the multiply.
>> 
>> Oh Christ.  READ THE CONTEXT.  That statement was made in reply to a
>> question asking about what would happen if you cast one of the operands
>> to 32 bit!  And you're replying to a post that told you that it was
>> misleading without its context, and again taking it out of context.
> 
> A conforming implementation of C will promote integer values to 32 bits
> only if 'int' is exactly 32-bits. Do you believe that the context I've
> missed changed 'int' to a 32-bit type? If not, your use of "promote" to
> describe that conversion is incorrect, though your expectation that
> there would be such a conversion is accurate.

I believe that you need to spend some time with engineers who actually 
design product.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On 2012-11-29, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/29/2012 10:23 AM, Grant Edwards wrote:
>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
>>> On Thu, 29 Nov 2012 01:18:42 +0000, Ben Bacarisse wrote:
>> 
>>> Me, I just try to remember that x, y or z went wrong on some compiler 
>>> some time, so that if I see symptoms again those problems are on my short 
>>> list, and maybe even a fix or two.
>>>
>>> Like Texas Instrument's Code Composter for the TMS320F2812, which has a 
>>> 32-bit "double".  #$%@.
>> 
>> Or on the TMS320C40, where char, int, long, long long, float and
>> double are all 32 bits and all have a sizeof() 1. ...
>
> There's a key difference there. The implementation you describe could
> be fully conforming. The one he described could not; you can't meet
> the standard's precision and range requirements for double with a
> 32-bit data type.

Well, the case I cited had 32-bit doubles. Other than that, I think it
was conforming.  When trying to reuse source modules, it's shocking
how many assumptions I make that aren't implied by the C standard.

>> ...  Trying to impliment any sort of communications protocol with
>> that was fun.
>
> Thanks for that information. Claims have frequently been made on
> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the
> existence of such implementations is a myth. I'm glad to have a
> specific counter example to cite.

If you look at some other DSPs, I think you'll find similar examples
where everything is 16 bits (they tend not to support FP at all).

> There's something I've wondered about such machines: when data from
> other machines containing data types smaller than 32 bits (for
> instance, ASCII text files) is transferred to the TMS320C40, how is
> this usually handled? I could imagine three main possibilities:

A TMS320 is a DSP, and I doubt there are any that have actual
filesystems.  OTOH, high-speed serial interfaces are common, and
filling in things like protocol headers involves a lot of
shifting/masking/anding/oring.

> a) Four 8-bit bytes of data are packed into each 32-bit byte

That's pretty common for data being sent to/from "normal" CPUs.

> b) Each field value stored in a data type smaller than 32 bits is
>    converted to a 32-bit type, and stored as such. For instance, a
>    file containing 45,678 8-bit bytes of text gets converted into a
>    file containing 45,678 32-bit bytes of text.

If you need to do any sort of string manipulation (which you try to
avoid like the plague), that's what you end up doing.

> c) Different methods are used in different contexts, leading to
>    constant headaches. This strikes me as the most likely possibility.

Exactly.

And the icing on the cake is that the 32-bit FP represention isn't
IEEE-784, so you also get to convert between external and internal FP
representations also.  Fun!

-- 
Grant Edwards               grant.b.edwards        Yow! My NOSE is NUMB!
                                  at               
                              gmail.com            

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Hans-Bernhard Br&ouml;ker <HBBroeker@t-online.de> writes:
> <snip>
>> Since we were nit-picking anyway: not quite.  As of C99 the standard
>> explicitly foresees the possible need to have more than the usual 10
>> different integer types ({signed|unsigned} {char|short|int|long|long
>> long}) in a target.
>
> These may be the usual ones, but there are 11 "standard integer types"
> because they include _Bool.  (Well, you did say we are nit-picking!)

And plain char *isn't* one of the "standard integer types", even
though it's a standard type, and it's an integer type, and its
characteristics (range, representation, and behavior) are identical
either to those of signed char or to those of unsigned char, both
of which are "standard integer types".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 11/29/2012 02:19 PM, Grant Edwards wrote:
> On 2012-11-29, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/29/2012 10:23 AM, Grant Edwards wrote:
>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote:
...
>>>> Like Texas Instrument's Code Composter for the TMS320F2812, which has a 
>>>> 32-bit "double".  #$%@.
>>>
>>> Or on the TMS320C40, where char, int, long, long long, float and
>>> double are all 32 bits and all have a sizeof() 1. ...
>>
>> There's a key difference there. The implementation you describe could
>> be fully conforming. The one he described could not; you can't meet
>> the standard's precision and range requirements for double with a
>> 32-bit data type.
> 
> Well, the case I cited had 32-bit doubles.

Oops - I missed that. OK - a more accurate statement would have been
that  your example had no additional conformance issues that weren't
present in his example.
-- 
James Kuyper