OSDev.org

I am almost convinced that most compilers generate redundant code..
even gcc...This may be less true for RISC architecture where there are 100's
of registers and we can view like a window only 30-40 of em ..like in SPARC...
Still it cant outperform a hardcore assembly programmer....,Yet It seems kina... boring to deal with this "micromanagement"....... (but the power
of controlling the register's and memory in your own way is tempting.!!)

One Final question.......
Whose time is more important your time or the machines time??? :

SandeepMathew wrote: I am almost convinced that most compilers generate redundant code..
even gcc...

Oh, definitely -- especially when inlining. The point is that sometimes the performance is actually better with such code because it avoids other overheads (like setting up a call frame).

Still it cant outperform a hardcore assembly programmer....

Except in terms of assembly instructions emitted per hour.

One Final question.......
Whose time is more important your time or the machines time??? :

Unless lives are at stake, developers' time is paramount. It's the most expensive factor in the equation.

I think you just summed up the assembler versus C/C++ argument.

Unless lives are at stake, developers' time is paramount. It's the most expensive factor in the equation.

Which is quite true because the developer's time is a finite amount that must be partitioned among many things including actually eating and sleeping in all cases. And by placing more of this into a partition such as "outperforming GCC optimization by hand" would seriously steal time from other partitions creating a lacking of you take you're pick or you make a bunch of picks for a amount lesser in direct relation to how many picks you make.

Solar wrote:

SandeepMathew wrote:Still ther wont come a time when a compiler can generate code better than a master assembly
programmer...?

Since someone has to write the backend for the compiler, there will always be someone who is better at ASM than the compiler is.

Compilers don't make mistakes and don't make omissions because they didn't see the application somewhere, at least, less so than the programmer (who will teach the compiler all he knows).

For a thread originally asking about portable object code, surely arguing the benefits of assembly over C is a move in the opposite direction?

Regards,
John

Conversation evolves... get over it... if you have anything productive to add to the original post go for it.

IMHO, even the greatest assembly programmers (for their respective architectures) will not write as efficient and useful code in the same period of time that a programmer writing in a high level language would. Especially as it is slightly more time consuming to write assembly for Modern Operating System Applications (as opposed to system development or DOS apps).

Then there is the case of System Development, there is a large number of people who want completely portable code (i know some aassembly developers claim assembly is easy to port, but you still have to go manually through it all) which doubles assembly production time. With unlimited time constraints, someone who knows the system inside out could probably beat the assembler, but in the end, compilers do a pretty fine job as it is.

felt the need to post twice tyler to make your statement

Still it cant outperform a hardcore assembly programmer....

Yeah like an asm programmer can fill all the instruction pipelines on a quad core processor and using mmx and xmm instructions in between. Problably he can but the compiler of a highlevel language programmer can do that much faster.

...and GCC -O3 is hardly the benchmark... try ICC.

Apologies! My internet is being really slow for some reason. I am only running Azureus... wonder what the problem is Didnt think it had posted the first time and i would delete it if i knew how, still i had a good point didnt i!

jnc100 wrote: For a thread originally asking about portable object code, surely arguing the benefits of assembly over C is a move in the opposite direction?

Regards,
John

The thread creator (SandeepMathew) changed the subject from portable object code (below). Surprisingly, huh.

SandeepMathew wrote: I am happy to know that it is feasible....,Still ther wont come a time
when a compiler can generate code better than a master assembly
programmer...? Any takers for this.......

meh..maybe a bit offtopic.. but one idea would be to use a generic assembly based bytecode
like have
"mov r0,30"
convert to
"mov ax,30"
except for that be byte code..

infact, I think I'll do this..lol just sounds fun to me..

That's what's being done in the intermediate Code Generation phase of
a compiler (if the compiler has this phase...)....But the problem is that
there is no standard for how the intremediate code should look like....

If you make the 'generic code ' more portable and if it can be very efficently
translated to native code then.... You will probably be the next James Gosling

(here the design of generic code is paramount...)one approach i would suggest (especially true to RISC arch's) is restrict most of the operations
to register whenever possible than to use the memory...... (keep some
kina index on the registers used and so on...)T00his should be
easier in RISC arch's where there are 100's of registers....,But unfortunately
i never had much opportunity to interact with RISC's ..... But from whatever
i have read..they seem to provide superior perfomance.... I practised my java labs on SUN (SPARC) servers connected via a thin client.... i did 'nt
seem to very fast...but i was amazed by its multitasking ability and roboustness,,,,,

Well, basically my idea would be best for application programming, and not OS, or even low level system programming..

but anyway..
ok so to code for optimizations on some archs, you use 100s of registers, so on those few archs that do support, it will be fast...but what do you do when the target arch only has 16?
My idea is to use memory in order to store missing registers..

the problem I have is bits(16,32,64) and endianess..I'm sure you could hardcode it somehow to fix that, but I'm not completely for sure on how to do that..

lets put endians aside..now bits:
lets say you wanted to program on 32bit for the generic assembly, but wanted to compile to use a 16bit arch. For example sake, we'll use 8086
now where it gets more complicated is with arithmetic and conditioning.. see..I can't figure out a quick fast, easy way to do that..



for my example compiler thing, I will only compile tokenized generic code to actual asm code..I don't want to mess with parsing all the crap...

Here is my auggestion.........(But this leads to less efficent translation......)
One way to get over this is to make your own custom library tnat performs the all the 32 bit operations for you ....(for the corresponding
archs)
say procedure add_32 , performs 32 bit arithmethic for your code gets translated to [/code]