Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #28629 > unrolled thread
| Started by | Ivan Shmakov <oneingray@gmail.com> |
|---|---|
| First post | 2012-11-25 04:18 +0700 |
| Last post | 2012-11-27 10:21 +0100 |
| Articles | 7 on this page of 87 — 26 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 04:18 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-24 17:09 -0500
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-24 22:12 +0000
statement / expression contexts in C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 12:54 +0700
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 13:37 +0700
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-28 14:49 +0000
Re: Getting started with AVR and C Frank Miles <fpm@u.washington.edu> - 2012-11-28 17:53 +0000
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 18:05 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 12:56 -0600
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 21:45 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 15:55 -0600
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-29 01:35 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 01:47 +0100
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:24 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 01:18 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 20:07 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:23 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:01 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 19:19 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 14:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 11:44 -0800
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 21:23 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:15 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:17 +0200
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 12:36 -0800
Re: Getting started with AVR and C Stephen Sprunk <stephen@sprunk.org> - 2012-11-29 16:22 -0600
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:36 -0800
Re: Getting started with AVR and C "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-12-11 10:53 +0100
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-11 14:53 +0000
Unicode Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:25 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 14:30 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 12:24 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 18:02 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 15:45 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-16 22:55 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-16 23:20 -0800
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:27 +0200
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-17 11:17 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:07 +0000
Re: Getting started with AVR and C Nobody <nobody@nowhere.com> - 2012-12-16 03:28 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-16 10:40 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 02:31 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 03:36 +0000
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 03:55 +0000
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:37 +0100
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:31 +0000
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:44 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 13:22 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:32 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:28 -0800
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:20 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:07 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:17 -0500
Re: Getting started with AVR and C pete <pfiland@mindspring.com> - 2012-11-29 18:25 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 22:46 -0500
Re: Getting started with AVR and C lawrence.jones@siemens.com - 2012-11-30 11:47 -0500
Re: Getting started with AVR and C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 03:53 -0800
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:38 -0800
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 15:21 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 22:26 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 17:32 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 19:02 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 18:29 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:39 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-29 00:59 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 07:57 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-29 13:02 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:19 +0000
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-29 12:03 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:39 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 08:04 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:17 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:19 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:44 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 13:15 -0500
Re: Getting started with AVR and C Arlet Ottens <usenet+5@c-scape.nl> - 2012-11-28 19:17 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:30 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:29 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-29 16:36 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:40 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 13:55 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 22:06 +0000
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 14:22 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 21:59 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-30 08:29 +0000
Re: Getting started with AVR and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-25 05:41 -0800
Re: Getting started with AVR and C Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 10:21 +0100
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Jon Kirwan <jonk@infinitefactors.org> |
|---|---|
| Date | 2012-11-29 13:55 -0800 |
| Message-ID | <e1mfb89qt0pb7t9cohsqvu7ni69p4cl1pb@4ax.com> |
| In reply to | #28824 |
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
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 22:06 +0000 |
| Message-ID | <k98m8g$60d$2@reader1.panix.com> |
| In reply to | #28826 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jon Kirwan <jonk@infinitefactors.org> |
|---|---|
| Date | 2012-11-29 14:22 -0800 |
| Message-ID | <mqnfb8hp1tu0bbsv4tjq7u5ge2s21u36jg@4ax.com> |
| In reply to | #28828 |
On Thu, 29 Nov 2012 22:06:08 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote: >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. Sorry I didn't interpret things well. >The "data" that's put in code space is never modified (at least not >any any project I've ever seen). I've needed writable code space. Thunking is one such example. >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). While I agree with the "generally" I don't agree that this translates into 100%. >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. Indeed. Completely agreed. Jon >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.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-29 21:59 +0000 |
| Message-ID | <k98lsr$60d$1@reader1.panix.com> |
| In reply to | #28824 |
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!
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2012-11-30 08:29 +0000 |
| Message-ID | <87hao7h4t2.fsf@devereux.me.uk> |
| In reply to | #28827 |
Grant Edwards <invalid@invalid.invalid> writes: > 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. Yes, that is precisely it. The AVRs especially tended to have lots of flash but little RAM. Access to program memory is possible on the AVR, but you have to use special attribute modifiers everywhere and the resulting objects become incompatible with the standard libraries, so you have to write special versions of these... Another thing is that, being an 8 bit machine, int and short operations are not atomic. So you have to be very careful about protecting variables shared with interrupt handlers (or other tasks in a preemptive system). Good practice anyway of course but a modern CPU like Cortex M3 is a lot more forgiving since even 32 bit load/store operations are atomic. [...] -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-11-25 05:41 -0800 |
| Message-ID | <f9b9c570-6510-4388-9672-26b5a7f5c073@d17g2000vbv.googlegroups.com> |
| In reply to | #28629 |
On Nov 24, 9:18 pm, Ivan Shmakov <oneing...@gmail.com> wrote: > >>>>> Robert Roland <f...@ddress.no> writes: > > [Cross-posting to news:comp.lang.c, in the hope that someone > could provide more suggestions, or correct me on C.] > > [...] > > > 2. Where do I start learning C? Is there a good online tutorial > > somewhere? I'd also be willing to buy a book. Is there one that > > stands out as the best? > > Frankly, I don't quite understand how did I learn C myself. > FWIW, there were hardly any good book on that that I've read. K&R?
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2012-11-27 10:21 +0100 |
| Message-ID | <dg19b8thrbbvjqi2ghni0e64mrr3s4mljb@4ax.com> |
| In reply to | #28629 |
On Sun, 25 Nov 2012 04:18:32 +0700, Ivan Shmakov <oneingray@gmail.com>
wrote:
> int8_t i; /* not necessarily translated; may force
> the compiler to "allocate" a register
> (say, r7), or a memory cell */
> i = 3; /* ldi r7, 3 */
> i += 2; /* adi r7, 2 */
> i++; /* inc r7 */
> if (i < 9) { /* cpi r7, 9 ; brge else_a */
> int8_t j = 5; /* ldi r8, 5 */
> while (j >= 3) { /* while_a:
> cpi r8, 3
> brlt end_while_a */
> PORTB ^= 1; /* in r9, PORTB
> eoi r9, 1
> out PORTB, r9 */
> } /* jmp while_a
> end_while_a: */
> } /* else_a: */
for me
> i = 3; /* ldi r7, 3 */
> i += 2; /* adi r7, 2 */
> i++; /* inc r7 */
are the same
one call "r7", "i" and are the same
for the remain i possibly prefer my macroized
part of the right side
than in the right side one can controll better the stack...
>[1] http://www.nongnu.org/avr-libc/user-manual/
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web