Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
25 Mar 1996 21:51:22 -0500

          From comp.compilers

Related articles
[41 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? jfc@mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? chuck@aage.mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? preston@tera.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? pardo@cs.washington.edu (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? mgrice@iastate.edu (1996-03-27)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-03-31)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? nather@astro.as.utexas.edu (R. Edward Nather) (1996-04-02)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? ok@cs.rmit.edu.au (1996-04-02)
[2 later articles]
| List of all articles for this month |

From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
Newsgroups: comp.compilers
Date: 25 Mar 1996 21:51:22 -0500
Organization: Compilers Central
References: 96-03-006 96-03-091 96-03-106 96-03-136
Keywords: optimize





>> [Do people really not use const and static? -John]
cdg@nullstone.com (Christopher Glaeser) writes:
>
>2) static - Static can cause significant performance problems for many
>C compilers. In particular, few C compilers can keep static variables
>in registers over a region of code.


fjh@cs.mu.OZ.AU writes:
|> I think the original poster who suggested using `static' for optimization
|> purposes was suggesting it as an alternative to making variables
|> and functions global, not as an alternative to using auto variables.
|> When used for this purpose, I suspect it may have some effect. For
|> example, compilers may be more inclined to inline a static function.


On 80x86 architecture, making the functions static can be a
significant win, even without inlining. At least one compiler I have
used would always generate a near call for a static function, for
example. (More importantly, this also meant that static functions
always had a near return.)


Sort of the opposite effect, but I also know of a compiler which
systematically loaded the segment register for all accesses to global
variables, even those declared in the module being compiled (even
though it also took pains to set up DS for the data in the module
being compiled).


In practice, the choice between near and far could make an enormous
difference in protected mode, where loading a segment register
involved loading the entire segment descripter (5 words, if memory
serves me right).


--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.