Reply by Mark Borgerson●February 28, 20112011-02-28
In article <XfydnQtGCJmZpfTQnZ2dnUVZ_oqdnZ2d@supernews.com>,
yates@ieee.org says...
>
> On 02/22/2011 03:15 AM, David Brown wrote:
>
> > Other people find most commercial tools awkward and inconvenient
> > compared to the streamlined ease and consistency of gcc - they see
> > commercial IDEs as too much lipstick on a pig.
>
> Right on!
>
> --Other people
Other people, like myself, who use IAR Embedded Workbench and
(in the past) the Codewarrior IDE and tools may not feel the
same. I particularly like the ability to manage the linker
setup files in IAR. That was really helpful on an earlier
ARM project that had to load into Flash in one area, but
be transferred to RAM for execution. I suppose the GCC
toolset has similar capabilities, but they weren't as
apparent when I started working with the ARM about
8 years ago.
Mark Borgerson
Reply by Randy Yates●February 26, 20112011-02-26
On 02/22/2011 03:15 AM, David Brown wrote:
> Other people find most commercial tools awkward and inconvenient
> compared to the streamlined ease and consistency of gcc - they see
> commercial IDEs as too much lipstick on a pig.
Right on!
--Other people
--
Randy Yates Digital Signal Labs
919-577-9882 http://www.digitalsignallabs.com
yates@digitalsignallabs.com
Reply by Boudewijn Dijkstra●February 25, 20112011-02-25
Op Tue, 22 Feb 2011 21:12:12 +0100 schreef 42Bastian Schick
<bastian42@yahoo.com>:
> 3rd: Get the sprintf() out of the newlib sources and make a local copy
> where you remove the un-needed stuff.
Or use siprintf or build newlib with INTEGER_ONLY.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
Reply by Oliver Betz●February 25, 20112011-02-25
Tauno Voipio wrote:
(clobbered listing when the C sources contain asm instructions)
>>
>> is this really a _mixed_ (assembler / source) listing, as I would
>> expect from "-adhl"?
>
>You did not ask for it. The difference is whether the compiler
>has the debug switch (-g). The source is not in the assembler
>input if there is no reason to have it.
Correct, I was not clear (silently assumed debug output enabled when
asking for a mixed listing).
>> In the mixed listings I got from the Coldfire gcc, asm<->C was out of
>> sync when I used (a small number of) assembler instructions in the C
>> sources. Now I let objdump make a listing, but that doesn't resolve
>> all symbols.
>
>In a way, you're right. Actually, there are multiple copies of
>the source in the assembler input: one at the input location of
>the code, and anonther at the location of the generated code.
in my case it was much worse - assembler and source completely out of
sync. But it contained more C code and only few assembler instructions
as a "tpf" (my debugger considers the target stopped if it runs a loop
out of the queue).
[...]
>> Well, since gcc produces unreadable assembler code, anyway, it doesn't
>> matter that much (I doubt this massive re-ordering of code does
>> improve speed).
>
>It depends - on RISC computers you can have noticeable speedup,
>but assembly code on them is for masochists, anyway, even with
>46 years of assembly code experience.
sadly gcc makes also unreable output for the 68K / Coldfire.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply by Tauno Voipio●February 24, 20112011-02-24
On 24.2.11 9:07 , Oliver Betz wrote:
> Tauno Voipio wrote:
>>
>>> Do you also experience a clobbered listing when the C sources contain
>>> asm instructions?
>>
>> Is this messed up:
>>
>> /* Change processing priority, return old priority */
>>
>> uint32_t change_pri(uint32_t newpri)
>> {
>> uint32_t oldpri;
>>
>> __asm volatile (
>> "mrs %[r], basepri\n\t" /* get old priority */
>> "msr basepri, %[n]" /* update priority */
>>
>> : [r] "=&r" (oldpri)
>> : [n] "r" (newpri)
>> );
>>
>> return oldpri;
>> }
>>
>>
>> ----------------
>>
>> 427 .section .text.change_pri,"ax",%progbits
>> 428 .align 1
>> 429 .global change_pri
>> 430 .thumb
>> 431 .thumb_func
>> 433 change_pri:
>> 434 @ args = 0, pretend = 0, frame = 0
>> 435 @ frame_needed = 0, uses_anonymous_args = 0
>> 436 @ link register save eliminated.
>> 437 @ 63 "kernel.c" 1
>> 438 0000 EFF31183 mrs r3, basepri
>> 439 0004 80F31188 msr basepri, r0
>> 440 @ 0 "" 2
>> 441 .thumb
>> 442 0008 1846 mov r0, r3
>> 443 000a 7047 bx lr
>>
>> ----------------
>
> is this really a _mixed_ (assembler / source) listing, as I would
> expect from "-adhl"?
You did not ask for it. The difference is whether the compiler
has the debug switch (-g). The source is not in the assembler
input if there is no reason to have it.
> In the mixed listings I got from the Coldfire gcc, asm<->C was out of
> sync when I used (a small number of) assembler instructions in the C
> sources. Now I let objdump make a listing, but that doesn't resolve
> all symbols.
In a way, you're right. Actually, there are multiple copies of
the source in the assembler input: one at the input location of
the code, and anonther at the location of the generated code.
Here is the mixed listing of the above example with the
initial ghost copy included, but without the other code
between the copies (see line numbers):
----------------
57:kernel.c **** /* Change processing priority, return old
priority */
58:kernel.c ****
59:kernel.c **** uint32_t change_pri(uint32_t newpri)
60:kernel.c **** {
61:kernel.c **** uint32_t oldpri;
62:kernel.c ****
63:kernel.c **** __asm volatile (
64:kernel.c **** "mrs %[r], basepri\n\t" /* get old priority */
65:kernel.c **** "msr basepri, %[n]" /* update priority */
66:kernel.c ****
67:kernel.c **** : [r] "=&r" (oldpri)
68:kernel.c **** : [n] "r" (newpri)
69:kernel.c **** );
70:kernel.c ****
71:kernel.c **** return oldpri;
72:kernel.c **** }
73:kernel.c ****
74:kernel.c ****
-------
709 .align 1
710 .global change_pri
711 .thumb
712 .thumb_func
714 change_pri:
715 .LFB1:
60:kernel.c **** {
716 .loc 1 60 0
717 .cfi_startproc
718 @ args = 0, pretend = 0, frame = 0
719 @ frame_needed = 0, uses_anonymous_args = 0
720 @ link register save eliminated.
721 .LVL51:
63:kernel.c **** __asm volatile (
722 .loc 1 63 0
ARM GAS /tmp/ccUOybAh.s page 24
723 @ 63 "kernel.c" 1
724 0248 EFF31183 mrs r3, basepri
725 024c 80F31188 msr basepri, r0
726 @ 0 "" 2
727 .LVL52:
72:kernel.c **** }
728 .loc 1 72 0
729 .thumb
730 0250 1846 mov r0, r3
731 .LVL53:
732 0252 7047 bx lr
733 .cfi_endproc
----------------
The difference to the previous listing is an addition of the -g
switch to the compiler command line.
> Well, since gcc produces unreadable assembler code, anyway, it doesn't
> matter that much (I doubt this massive re-ordering of code does
> improve speed).
It depends - on RISC computers you can have noticeable speedup,
but assembly code on them is for masochists, anyway, even with
46 years of assembly code experience.
--
-Tauno
Reply by Anton Erasmus●February 24, 20112011-02-24
On Mon, 21 Feb 2011 18:17:38 -0800, Tim Wescott <tim@seemywebsite.com>
wrote:
>I'm shaking the box, trying to get the software to settle enough to fit
>into a 64kB memory space. This is made difficult by the fact that it's
>a human-interface rich environment with a bit of extra fat contributed
>by the fact that I'm writing in C++.
>
>This is for an application that worked just peachy-keen on a captive
>vendor's tool set, but which is too big using gnu tools. It's to be
>expected, I suppose.
>
>As soon as I saw all of the I/O junk in the map file I realized that
>maybe I shouldn't be using sprintf (even if it _did_ fit before). So I
>took it out, and rather than contort my code, I'm writing a replacement
>for just the formats that I'm using (yes, I know, bomb in the code).
>
>As I usually do, I started easy -- which, in my case, means locating the
>decimal point with log10, and moving it around using pow(10.0, n).
>
>'pow' is over 1kB!! And it pulls in something called __pow_754, which
>is HUGE -- like, 5kB or something! Eeek! I mean -- the code worked,
>but without much room in the end.
>
>So I'm un-powing my sprintf, shaking my head at the vicissitudes of free
>software, and (since it's a hobby project) thinking about processors
>with more memory space.
Try this printf function.
http://www.efgh.com/software/gprintf.htm
I have used it on quite small MCUs with success. Even with just 8K of
program space, one can still do useful things even when using this
printf routine.
Regards
Anton Erasmus
Reply by Oliver Betz●February 24, 20112011-02-24
Tauno Voipio wrote:
[...]
>>> The GNU tools are very flexible, but it needs some tuning to
>>> the make files to get the desired results. Here are my switches
>>> for GCC plain C compilation:
>>>
>>> CFLAGS = $(INCDIR) -g -Wall -Wstrict-prototypes
>>> CFLAGS += -Wa,-adhlms=$(@:.o=.lst)
>>
>> what is the "m" flag?
>
>It was a macro listing flag - seems to be dropped in current version
>of as.
>
>> Do you also experience a clobbered listing when the C sources contain
>> asm instructions?
>
>Is this messed up:
>
>/* Change processing priority, return old priority */
>
>uint32_t change_pri(uint32_t newpri)
> {
> uint32_t oldpri;
>
> __asm volatile (
> "mrs %[r], basepri\n\t" /* get old priority */
> "msr basepri, %[n]" /* update priority */
>
> : [r] "=&r" (oldpri)
> : [n] "r" (newpri)
> );
>
> return oldpri;
> }
>
>
>----------------
>
> 427 .section .text.change_pri,"ax",%progbits
> 428 .align 1
> 429 .global change_pri
> 430 .thumb
> 431 .thumb_func
> 433 change_pri:
> 434 @ args = 0, pretend = 0, frame = 0
> 435 @ frame_needed = 0, uses_anonymous_args = 0
> 436 @ link register save eliminated.
> 437 @ 63 "kernel.c" 1
> 438 0000 EFF31183 mrs r3, basepri
> 439 0004 80F31188 msr basepri, r0
> 440 @ 0 "" 2
> 441 .thumb
> 442 0008 1846 mov r0, r3
> 443 000a 7047 bx lr
>
>----------------
is this really a _mixed_ (assembler / source) listing, as I would
expect from "-adhl"?
In the mixed listings I got from the Coldfire gcc, asm<->C was out of
sync when I used (a small number of) assembler instructions in the C
sources. Now I let objdump make a listing, but that doesn't resolve
all symbols.
Well, since gcc produces unreadable assembler code, anyway, it doesn't
matter that much (I doubt this massive re-ordering of code does
improve speed).
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply by Tauno Voipio●February 24, 20112011-02-24
On 24.2.11 11:03 , Oliver Betz wrote:
> Tauno Voipio wrote:
>
> [...]
>
>> The GNU tools are very flexible, but it needs some tuning to
>> the make files to get the desired results. Here are my switches
>> for GCC plain C compilation:
>>
>> CFLAGS = $(INCDIR) -g -Wall -Wstrict-prototypes
>> CFLAGS += -Wa,-adhlms=$(@:.o=.lst)
>
> what is the "m" flag?
It was a macro listing flag - seems to be dropped in current version
of as.
> Do you also experience a clobbered listing when the C sources contain
> asm instructions?
>> CFLAGS += -ffreestanding -fno-guess-branch-probability
>
> -ffreestanding kills also builtins. Do you re-enable them?
-Os uses thos built-ins that are sensible in embedded code.
> Do you have any experience with -fno-guess-branch-probability ?
It limits the eagerness of the optimizer to re-order branches
in a non-obvious way, the effect is pretty small.
--
Tauno Voipio
Reply by David Brown●February 24, 20112011-02-24
On 23/02/2011 21:51, Tauno Voipio wrote:
> On 22.2.11 11:11 , Tim Wescott wrote:
>> On 02/22/2011 12:12 PM, 42Bastian Schick wrote:
>>
>>> 2nd: Check the map-file who pulls in malloc. If you use sprintf, there
>>> you are.
>>
>> I should know this -- how do I do that? I can see it in the symbol
>> table, but I don't know how, from the object file, I can see what ended
>> up pulling in malloc.
>
> I had some private correspondence with Tim, and I promised to
> post here the part about GNU toolkit switches for diagnostic
> output:
>
> --- clip clip ---
>
> The GNU tools are very flexible, but it needs some tuning to
> the make files to get the desired results. Here are my switches
> for GCC plain C compilation:
>
> CFLAGS = $(INCDIR) -g -Wall -Wstrict-prototypes
> CFLAGS += -Wa,-adhlms=$(@:.o=.lst)
> CFLAGS += -ffreestanding -fno-guess-branch-probability
> CFLAGS += -W -Wpointer-arith
>
The "-W" flag is for older gcc versions - newer versions deprecate it
replace it with "-Wextra". I can't remember off-hand which versions use
which flag, but for new projects it's best to call it "-Wextra".
I like to add a number of other warning flags - depending on your style
of coding, you may or may not find them useful.
There are some types of cast that are legal in C, but which I prefer to
write explicitly if I need them. These warnings help spot mistakes:
-Wbad-function-cast -Wcast-qual -Wcast-align -Wpointer-arith
I am very strict about prototypes for functions - in my code, a function
either has an "extern" declaration in the module's header file, or it is
declared "static" in the module itself. These warnings enforce that
policy :
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls
-Wnested-externs
I also like to be explicit about padding in structs: -Wpadded
Unreachable code is /mostly/ a sign of an error, but not always -
sometimes I use "-Wunreachable-code". Older versions of gcc can give a
lot of false positives here when inlining lets it remove extra code -
newer versions give more accurate warnings.
"-Wc++-compat" is good if you are mixing C and C++ code.
Each new version of gcc gets more warning flags - it's worth having a
little look in the manual for the version you are using.
Reply by David Brown●February 24, 20112011-02-24
On 24/02/2011 00:21, Tim Wescott wrote:
> On 02/23/2011 12:06 PM, David Brown wrote:
>> On 23/02/11 18:43, Tim Wescott wrote:
>>> On 02/23/2011 08:04 AM, David Brown wrote:
>>>> On 23/02/2011 16:47, Tim Wescott wrote:
>>>>> On 02/23/2011 12:20 AM, Andreas Huennebeck wrote:
>>>>>> Tim Wescott wrote:
>>>>>>
>>>>>>> If I could figure out how to keep C++ without using the heap, I'd
>>>>>>> be a
>>>>>>> happy camper.
>>>>>>
>>>>>> Don't use 'new'. Put your objects on the stack and let subroutines
>>>>>> use
>>>>>> them through references as function arguments, e.g.:
>>>>>>
>>>>>> static int foo(MyClass& c)
>>>>>> {
>>>>>> c.do_something();
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> int some_data;
>>>>>> ... some code ...
>>>>>> MyClass my_object(some_data);
>>>>>> ... some code ...
>>>>>> foo(my_object);
>>>>>> ... some code ...
>>>>>> }
>>>>>>
>>>>>>> I'm not even sure if malloc&c. are getting _called_, or
>>>>>>> just pulled in because C++ uses "new", which uses -- well, you get
>>>>>>> the
>>>>>>> idea.
>>>>>>
>>>>>> If your classes don't call new and your functions never call new and
>>>>>> if you
>>>>>> don't use classes from other libraries then malloc() should not be
>>>>>> linked in.
>>>>>> That's theory though :-(
>>>>>>
>>>>>>> For embedded I pretty much avoid dynamic deallocation like the
>>>>>>> plague*; while this is against the C++ desktop paradigm, it lets you
>>>>>>> use
>>>>>>> a very useful subset of the language without a whole 'heap' of
>>>>>>> trouble.
>>>>>>>
>>>>>>> * Meaning I'll "new" things at system startup but only if they're
>>>>>>> going
>>>>>>> to live until power-down. This gives one great flexibility in making
>>>>>>> portable libraries while still not fragmenting the heap through
>>>>>>> new-delete-new-delete-new sequences.
>>>>>>
>>>>>> For this approach (and placement new, see
>>>>>> http://en.wikipedia.org/wiki/Placement_syntax)
>>>>>> malloc is linked in.
>>>>>>
>>>>>> bye
>>>>>> Andreas
>>>>>
>>>>> void * malloc(size_t n)
>>>>> {
>>>>> assert(false);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> is pretty small -- maybe I'll use that.
>>>>>
>>>>
>>>> void * malloc(size_t n) {
>>>> return 0;
>>>> }
>>>>
>>>> is smaller. "assert" can bring in all sorts of junk, depending on
>>>> how it
>>>> is defined, and what flags you have enabled - if it tries to print
>>>> out a
>>>> message on stderr, then this may be the cause of some of your problems.
>>>
>>> Let me rephrase that for you: "assert" can bring in all sorts of junk,
>>> if you're dumb enough not to write your own. Honest libraries that are
>>> really intended for deep embedded use don't even _have_ an assert
>>> written, because they know that each development team is going to want
>>> its own (or is going to be too slow to use it). The rest need their
>>> assert function redefined.
>>>
>>> So you spelunk through the headers and find out what the 'assert()'
>>> macro points to, and you write your own. This one's teeny, and if your
>>> debugger lets you set a variable you can break out and see what code was
>>> running in the previous function*. Sometimes you can even break out of
>>> the assert and correct the problem in the calling function that once,
>>> check to see that it's doing the right thing, then go back and find out
>>> why the assert was popping off:
>>>
>>> static volatile int break_out = 0;
>>> void __assert_func(const char * this, int that, const char * the, const
>>> char * other)
>>> {
>>> while (break_out == 0)
>>> {
>>> }
>>> }
>>>
>>> I really do know what I'm doing, even if I'm not as familiar with gnu
>>> tools and newlib as I'd like to be (and am becoming).
>>>
>>
>> I have your book, though I haven't had time to read it yet, so I know
>> you know your stuff. But even experts make mistakes on unfamiliar
>> territory. And since you have been having issues with the libraries
>> already, it's possible that you've been unintentionally been getting
>> extra library code sneaking in here.
>
> I mostly chose gnu tools because I'm a cheap bastard, but I also chose
> them to force me to learn more about them. Half of the tool chains out
> there seem to be based on gnu tools, and with the ARM seemingly taking
> over the world, and being such a good fit for the tool chain, I see a
> lot of value in becoming the go-to guy for that tool chain.
>
I mostly choose gnu tools because I like them better, and I find they do
a better job than many commercial tools. The price is of course nice -
especially if I am doing stuff at home. Free tools means it is easy to
install them on my work PC, and my home PC, and a laptop, etc., without
ever having to think about whether it is cost-effective. It also means
there is no administrative overhead involved in "purchasing" the tools -
you don't need to fit them into budgets, arrange purchasing orders, etc.
I use a wide range of processors in my work - having gcc for almost all
of them makes life easier for me. I can use the same editors, and the
same procedures (and to a fair extent, the same makefile) for all the
projects.
I have used (and still use) a fair number of commercial tools over the
years. Details vary wildly, but gcc generates roughly as good code for
most 32-bit targets (and it's not too bad even for the 8-bit avr). I
also find some gcc enhancements and newer standard C features let me
write clearer source code and smaller or faster target code. It's
always annoying when I have to back to a commercial compiler that
doesn't support things like intermixing variable declarations and
executable code.