From: Walter Banks on 16 Jan 2010 05:18 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 18 Jan 2010 20:16 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 21 Jan 2010 13:02 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
First
|
Prev
|
Pages: 1 2 Prev: How to ascertain the type of files being read Next: Hide application from activities list |