Getting started with AVR and C

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I've heard of machines with 32-bit short, but not 64-bit. Note that
> while int32_t and int16_t could not be provided by <stdint.h> for such a
> compiler, int_least32_t and int_fast32_t (and similarly for 16) must be.

Trivia: I've used a machine (Cray T90) with 8-bit char and 64-bit short,
int, long, and long long.  It had no 16-bit or 32-bit integer types.

[...]

> That depends upon what you mean by 'normal'. The C99 standard
> distinguishes between standard and extended integer types. The standard
> integer types have names specified by the C standard; extended types are
> implementation-defined, and may have other names.

They *must* have other names.

Normally such names would be identifiers reserved to the
implementation, starting with an underscore and either another
underscore or an uppercase letter.  (Though I suppose an
implementation that supports other forms of identifiers as a
language extension could use them; for example some compiler permit
identifiers with '$' characters.)

-- 
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 Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

><snip>
>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.
><snip>

I believe that C was implemented on the PDP-10. I didn't use
it when I was programming the PDP-10 (I used assembly, then,
and some other languages... but not C, until I worked on Unix
v6 in '78.) But that was a 36-bit machine. And ASCII was
packed into 7 bits so that 5 chars fit in a word. No one used
8, so far as I recall. That was the standard method. So I'm
curious now what the C implementation did.

Of course, all that is prior to any standard. But it might be
another case to discuss, anyway.

Jon

On Thu, 29 Nov 2012 11:01:34 -0500, 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:

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

Using left/right shifts and AND and OR operations work just fine.
Works OK with different CHAR_BIT and different endianness platforms.
Do not try to use structs etc.

>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.

IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.

On the Unicode list, I even suggested packing three 21 characters into
a single 64 bit data word as UTF-64 :-)

On 11/29/2012 02:38 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> That depends upon what you mean by 'normal'. The C99 standard
>> distinguishes between standard and extended integer types. The standard
>> integer types have names specified by the C standard; extended types are
>> implementation-defined, and may have other names.
> 
> They *must* have other names.

Not if there aren't any. :-) I should have worded that differently.
They're not required to exist, but if they do, you're right - they must
have other names.
-- 
James Kuyper

upsidedown@downunder.com writes:
> On Thu, 29 Nov 2012 11:01:34 -0500, 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:
>
>>> ...  Trying to impliment
>>> any sort of communications protocol with that was fun.
>
> Using left/right shifts and AND and OR operations work just fine.
> Works OK with different CHAR_BIT and different endianness platforms.
> Do not try to use structs etc.
>
>>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.
>
> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range.
>
> On the Unicode list, I even suggested packing three 21 characters into
> a single 64 bit data word as UTF-64 :-)

I like it -- but it breaks as soon as they add U+200000 or higher, and
I'm not aware of any guarantee that they won't.

I've thought of UTF-24, encoding each character in 3 octets; that's
good for up to 16,777,216 distinct code points.

-- 
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 Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
<john@devereux.me.uk> wrote:

>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.

Except for self modifying code, why would one want data (program)
access into program space (unless you are writing a linker or
debugger) ??

While working with PDP-11's in the 1970's, the ability to use separate
I/D (Instruction/Data) space helped a lot to keep code/data in private
64 KiD address spaces.

 

In comp.lang.c Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper
> <jameskuyper@verizon.net> wrote:
 
>><snip>
>>Claims have frequently been made on
>>comp.lang.c that, while the C standard allows CHAR_BIT != 8, the

As I remember the stories, the CRAY-1 had 64 bit char.

>>existence of such implementations is a myth. I'm glad to have a specific
>>counter example to cite.
>><snip>
 
> I believe that C was implemented on the PDP-10. I didn't use
> it when I was programming the PDP-10 (I used assembly, then,
> and some other languages... but not C, until I worked on Unix
> v6 in '78.) But that was a 36-bit machine. And ASCII was
> packed into 7 bits so that 5 chars fit in a word. No one used
> 8, so far as I recall. That was the standard method. So I'm
> curious now what the C implementation did.

Yes the TOPS-10 file format stores ASCII as 5 characters
to the word, but C can't do that. In a discussion some time
ago about actual implementations, 9 and 18 bit char were
discussed. The PDP-10 has instructions for operating on
halfwords, which could be used, possibly with execute (XCT)
to select the appropriate instruction, or for loops an 
unrolled loop. Or 9 bit chars using the byte instructions.
 
> Of course, all that is prior to any standard. But it might be
> another case to discuss, anyway.

I keep wondering about a C compiler for the 7090, one of the
last sign magnitude machines, and also 36 bits. It was usual
to store six 6 bit BCDIC (more often called just BCD) characters
per word. Also, 6 bit characters on 7  track magnetic tape.

The card reader on the 704, and I will guess also the 7090, 
reads one card row into two 36 bit words, ignoring the last
eight columns. Software had to convert that into 12 
characters in two words.

-- glen

On Thu, 29 Nov 2012 22:40:41 +0200, upsidedown@downunder.com
wrote:

>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
><john@devereux.me.uk> wrote:
>
>>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.
>
>Except for self modifying code, why would one want data (program)
>access into program space (unless you are writing a linker or
>debugger) ??
>
>While working with PDP-11's in the 1970's, the ability to use separate
>I/D (Instruction/Data) space helped a lot to keep code/data in private
>64 KiD address spaces.

There are good reasons for self-modifying code space. The
first and most obvious would be an operating system loading a
program into memory. While the O/S does this, the memory is
treated as data. A more meaningful example for small embedded
applications, perhaps, is the ability to modify interrupt
vectors pointing at code. If the processor refers to I space
only for interrupt vectors, it may not be possible. And there
are times when you have externally available code (large
external serial-access memory (low pin count), for example,
used to store code blocks infrequently needed and where the
internally supplied flash just isn't big enough.)

In embedded, there are reasons. For operating systems, there
are also reasons. And I am tapping only what is on the tip of
my tongue and using no imagination, right now.

Jon

On 2012-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
><john@devereux.me.uk> wrote:
>
>>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.
>
> Except for self modifying code, why would one want data (program)
> access into program space (unless you are writing a linker or
> debugger) ??

The "program" space was flash (non-volatile).  The "data" space was
registers and RAM (volatile).  All non-volatile data (strings, screen
templates, lookup tables, menu structures, and so) has to be in flash
memory (IOW "program space").  It makes a _lot_ of sense to just use
directly from flash instead of copying it all to RAM when RAM is so
scarce.

> While working with PDP-11's in the 1970's, the ability to use separate
> I/D (Instruction/Data) space helped a lot to keep code/data in private
> 64 KiD address spaces.

But in a PDP11, Data space was plentiful, and constant data didn't
also have to reside in Instruction space (because that's the only
non-volatile storage you have).

On some parts there is some erasable non-volatile storage in data
space. But, it's always scarce, and putting stuff there that is never
to be altered is both wasteful and dangerous.

-- 
Grant Edwards               grant.b.edwards        Yow! I didn't order any
                                  at               WOO-WOO ... Maybe a YUBBA
                              gmail.com            ... But no WOO-WOO!

On 2012-11-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Thu, 29 Nov 2012 22:40:41 +0200, upsidedown@downunder.com
> wrote:
>
>>On Thu, 29 Nov 2012 16:36:34 +0000, John Devereux
>><john@devereux.me.uk> wrote:
>>
>>>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.
>>
>>Except for self modifying code, why would one want data (program)
>>access into program space (unless you are writing a linker or
>>debugger) ??
>>
>>While working with PDP-11's in the 1970's, the ability to use separate
>>I/D (Instruction/Data) space helped a lot to keep code/data in private
>>64 KiD address spaces.
>
> There are good reasons for self-modifying code space.

Nobody said anything about modifying code space.

The "data" that's put in code space is never modified (at least not
any any project I've ever seen).

It's not _modifying_ the progam space that's the issue (that is
generally only done for firmware updates, where the entire flash is
erased and reprogrammed).

Simply _reading_ program space _as_data_ is problematic.  If you've
got a lot of string constants or constant tables, you want to just
leave them in flash (program space) rather than copy them all to
(scarce) RAM on startup.

Now you need three-byte pointers/addresses to differentiate between
data at 0xABCD in data space and the data at 0xABCD in program space.
Three byte pointers is how some compilers solve that problem -- but I
don't think avr-gcc does that.

-- 
Grant Edwards               grant.b.edwards        Yow! I think my career
                                  at               is ruined!
                              gmail.com