From: Walter Banks on


Jon Kirwan wrote:

> the idea of replacing bubble sort code with
> stocked versions of quick sort, though, within the context of
> the c language.

It has been pointed out that recognizing and replacing a bubble
sort with a quick sort may not always be in the best interest
of a given application. I don't agree that C compilers have the
right to argue with the application developer over their choice
implementation algorithm.

The C language as defined by its standards gives compilers
a reasonable amount of freedom to translate applications
as written to the executable machine code. To give a
compiler the additional flexibility to select appropriate
application implementation algorithm at the function level
requires a language designed to describe application
objectives rather than implementation.

To illustrate this point. Your exact timing example is not a
C compiler limitation but a language limitation. How do
you describe exact timing all paths in a function in an
unambiguous way in C? Exact timing is an application
objective.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com






--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: David Brown on
Walter Banks wrote:
>
> Walter Banks wrote:
>
>> David Brown wrote:
>>
>>> Is there some disadvantage of having an assembly intermediate step?
>>> Obviously the compilation is going to be slightly quicker without it,
>>> but other than that I can't see any issues.
>> Control flow instructions branch and call distance measurements are
>> known, controlled and used by the compiler. Some processors that
>> have page limited branches or a mixed page and distance branches
>> (COP8) are easier for the code generator to manage in a single place.
>> Many assemblers (still!!) do a very bad job of forward control flow
>> instruction selection. Memory managed ROM becomes part of the
>> control flow optimization.
>>
>> It is possible to generate assembler but it then becomes
>> necessary for the compiler and assembler to make exactly the
>> same assumptions in processing the assembler source.
>>
>> We saw generating assembler code as a two copy problem that we
>> could avoid.
>>
>
> I was thinking about this after I posted it an realized there
> were two comments that I should have made.
>
> 1) When we compile to machine code directly in line assembly
> code can share the same symbol table manager as the
> compiler. This means that variables can share the same
> name space and reference each other directly without
> name mangling.
>

I can see that point.

> 2) Sheer execution time is actually reduced by quite a bit when
> all of the pieces are accounted for, duplication of compiler
> and assembler functionality, computing forward reference
> distances twice for example, roughly doubling the number
> of symbol table processing and references and the amount
> of data that needs to be passed between the compiler and
> assembler.
>

Yes, omitting the assembler pass will speed up the tools - but I don't
see tool speed as a big issue for small systems.
From: pete on
Jon Kirwan wrote:

> I was simply addressing myself to the line of reasoning from
> Hans-Bernhard Br�ker when he wrote:
>
> "Nothing stops a compiler from completely
> reorganizing a given function, as long as
> it's written in such a way that all effects
> to the outside are tightly scoped. I.e. a
> compiler is already allowed to detected a
> piece of code performs a sort and just call
> qsort() instead."
>
> Unless I'm just too sleepy to recognize something you are way
> ahead of me on, right now, I'd like to suggest we are talking
> at cross purposes.

Also,
what he wrote was oversimplified to the point of being wrong.

Given an array of pointers to strings:

char *array_1[] = {"one","two"};

If sorted by string length,
a nonstable sort could leave array_1 in either order.

--
pete