flat assembler
Message board for the users of flat assembler.

Index > Heap > Intel C/C++ compiler discussion

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
Quote:

Besides, I have come to like the level of ease fASM gives when compiling. i hate having to make a project in VC++ just to compile a simple source file


I agree! Fasm is truly 'easy to use' tool. No need to blame the compiler if my code does not work. Wink

regards,
Mac2004.
Post 12 Aug 2007, 16:32
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
mandeep wrote:
I want to get advice from you on this, can we just rely on compilers and just stop using assembly for better of it.


As I already said, compilers are suitable for most of the tasks but in some cases they perform less than optimal.

The cycle looks like this:

1. Algorithm that performs some task evolves or completely new one gets invented
2. Compilers can't recognize new or changed algorithm and produce suboptimal code for it
3. Someone optimizes new algorithm in assembler
4. Compiler writers implement that trick in the next version of the compiler
5. Rinse, repeat

So over the time compilers become more capable and people who write them are able to look at all those tricks from a distance, notice a pattern and devise some generic optimization rule. That makes compiler "intelligent" thus allowing it to create good code for even more cases than before. Humans are at disadvantage there because they cannot generalize things at that scale unless they have years of evolving practice.

sleepsleep wrote:
just my opinion is, until the computer/system/pc is "creative" enough to draw a picture by giving it a title, until then, imho, compiler would never beat human coz the best/main part of us is "creativity"


There are many, many people who can't do that as well so it is not realistic to expect it from a computer.

My impression is that assembler programmers like to think about themselves as if they are very creative.

Truth is that assembly programming is not about creativity but about solid knowledge of the underlying architecture and relevant optimization rules. Creativity comes last.

FrozenKnight wrote:
Besides, I have come to like the level of ease fASM gives when compiling. i hate having to make a project in VC++ just to compile a simple source file


You don't have to make a project every time if you don't like Visual Studio IDE. You can use makefile and command line tools -- nmake, cl, rc, ml, link, lib.

For example for Visual Studio 2005 just create a shortcut named build.lnk with the following command line:
Code:
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
    

Put it in a folder of your choice and then write some C/C++ code in the same folder. Clicking on the shortcut opens console window which allows you to compile and link, and it is as easy as:
Code:
cl /c /O2 test.cpp <- this produces just .obj, doesn't link
cl /O2 test.cpp <- this produces .exe file
    

As I said, you can also use batch files and a makefile and you can mix assembler and C/C++ to your liking.
Post 14 Aug 2007, 23:07
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
mandeep



Joined: 11 Aug 2007
Posts: 6
mandeep
Thanks levicki!
I have made up my mind that unless absolutely unavoidable for the task at hand
I will stay away from assembly!

_________________
Mandeep Singh
Post 16 Aug 2007, 04:51
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
mandeep wrote:
Thanks levicki!
I have made up my mind that unless absolutely unavoidable for the task at hand I will stay away from assembly!


No, no, no... let me get this straight -- it wasn't my intention to discourage the use of the assembler, especially not in this forum. After all, I use it myself.

What I wanted to say is that some things need to be put in the correct perspective.

For me it doesn't make sense to (mis)use hand-written assembler to perform dumb tasks such as to load or save a file or to write a program which most of the time just calls various system functions.

There is no significant benefit in doing so in assembler compared to any non-interpreted high-level language.

But if that program has some calculations which should be as fast as possible, I would first try algorithmic optimizations, then numeric optimizations, then regular optimizations available in the high-level language itself, and only in the end I would check the compiler code to see if there is some room for improvement by hand.

If there is, then I would usually write the function as an inline assembler block because it is practical for maintainance and building doesn't require any additional steps.

It also allows you to access C/C++ variables by name and if you do not want compiler's prolog/epilog code you just put __declspec(naked) in front of the function definition and roll your own prolog/epilog referencing variables on the stack directly through the ESP thus leaving you with one extra register free.

That is in my opinion the easiest way to get the most out of both worlds provided that you don't need your code to be portable.
Post 16 Aug 2007, 23:39
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
mandeep



Joined: 11 Aug 2007
Posts: 6
mandeep
Thanks for your time and comments levicki!
Well
*
first algorithmic optimization
second numeric optimization
third HLL optimization
enough optimized code Smile
*
I do not need to go further down for assembly optimization!
I will rather bet on improving compilers.
Post 17 Aug 2007, 05:11
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
mandeep wrote:
I do not need to go further down for assembly optimization!


Sometimes you do but it is your choice, just don't claim I gave you that advice.

Assembler is good to know, because you will understand the way things work on a low-level and you won't make mistakes that will affect performance of your code.
Post 17 Aug 2007, 22:33
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
mandeep



Joined: 11 Aug 2007
Posts: 6
mandeep
No levicki no body is blaming you (at least not me)!
It's just that your comments on improving compiler technologies have given me a ray of hope.
And I decided to rely on the compilers improvements that doing all the hard work myself.
It's kinda similar to how we avoid knowing the details of our HDD drivers and do not do file space allocation manually. That's too much work for a human. Let the software do whatever it can do. And the only tasks which are not possible with a software (till today) can be done by the humans.

_________________
Mandeep Singh
Post 18 Aug 2007, 04:25
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
Replies: 176


My COOLest post Laughing

Quote:
I will rather bet on improving compilers.


Still betting on ASM. When compilers one day stop being fools and become smart instead, just let me know Wink And, someone will have to invent a non-silly HLL up to then ... I hate to code a routine or declare/include many 100's of lines of garbage for something trivial that ASM can do with 1 or 2 instructions ......
Post 18 Aug 2007, 05:19
View user's profile Send private message Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
NTOSKRNL_VXE wrote:
Quote:
My COOLest post Laughing


I think this thread is one of the longest in this forum Smile


NTOSKRNL_VXE wrote:
Quote:

Still betting on ASM. When compilers one day stop being fools and become smart instead, just let me know Wink And, someone will have to invent a non-silly HLL up to then ... I hate to code a routine or declare/include many 100's of lines of garbage for something trivial that ASM can do with 1 or 2 instructions ......


Agreed! Very Happy

regards,
Mac2004
Post 18 Aug 2007, 07:03
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
NTOSKRNL_VXE wrote:
I hate to code a routine or declare/include many 100's of lines of garbage for something trivial that ASM can do with 1 or 2 instructions ......


Can you post an example?
Post 18 Aug 2007, 15:08
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> Can you post an example?

- Dirty chaining of 4 signed 16-bit integers (only 8 bits used in each) to get an UINT32 (OK, this did improve, my recent C compiler no longer has this bug)
- Ugly ***-hacks to access memory (very trivial in ASM)
- Additional hacks and crap includes to access low memory or VESA LFB (memory.h, movedata.h, farptr.h, ...)
- All the struct/union/typedef crap needed just to execute an INT (my recent C compiler supports inline asm, so it's mostly "fixed" there)
Post 20 Aug 2007, 23:24
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
ntos: okay, so 2 of 4 are fixed in your recent compiler, remained:

- "ugly *** hack to access memory": i can't imagine memory accessing hack that will take more than two lines, and one is usually enough.

i agree that if you wan't to do something like "read 32bit number which is 3 bytes behind this pointer", then it is little pain in C (usually two casts). But C is not designed for that, and you shouldn't do that kind of stuff unless you have really good reason to do it. C is designed for portable applications, and i couldn't think of better way to design it.

- Additional hacks and crap includes to access low memory or VESA LFB (memory.h, movedata.h, farptr.h, ...)
agree, segmented memory in C is mess.

fortunatelly, virtually all today OSes use flat address space and mapping instead of segmenting, so this isn't practical problem anymore.
Post 20 Aug 2007, 23:55
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
Quote:
"read 32bit number which is 3 bytes behind this pointer", then it is little pain in C (usually two casts)


Actually that would be poor code design if you need to do that too often.

I understand that some people still need to use real x86 mode and in that case assembler may be a bit easier but in my opinion it is not fair to generalize on high-level languages and today's compilers based on an experience from DOS era.
Post 22 Aug 2007, 22:02
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Actually that would be poor code design if you need to do that too often.


i needed that when i was reading structure that looked like "non-fixed length string followed by dword". That dword needed to be aligned (because of portability to ARM architecture with forced alignment of data). Of course i used macro to align so it was just a one-time pain to write macro, but still.

I hope you agree that such structures are sometimes needed...
Post 23 Aug 2007, 10:41
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
Quote:
i needed that when i was reading structure that looked like "non-fixed length string followed by dword"


If that string was padded to end on a dword boundary you wouldn't have that problem. So it is (not neccessarily yours of course) bad design.

I agree that sometimes you have to do what you have to do though. That is why I said that it is ok to do it if it is not too often.
Post 23 Aug 2007, 18:56
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
I always program in C with non-standard stuff. For example I declare my own:

#define ptr void*

so I can always change the size if I want to (for example, replace it with "unsigned short"). Of course this also means I have to type-cast when I need to dereference it, but that's ok anyways as 'types' are for me, a bad optimization (because they restrict yourself to only one type for a specific 'memory location' so to speak).

The only thing that annoys me, is the "Calling convention" (or any convention for that matter). I mean, why can't the stupid compiler just check through all the code and adjust the convention accordingly for better optimization? I know the performance might not increase a lot, but I'm kind-of like a perfectionist, and knowing that the code is junk in some areas (like function calls, etc) due to the compiler's stupidity, I have a feeling that just haunts me somehow.

My problem with Calling conventions is not because Compilers 'can't do it. In fact it would be pretty simple for a linker to do that (check through all code and determine best arrangement of parameter passing, for example function 1 receives parameters in 'eax','ebp' and 'esi' while function 2 receives them in 'ecx', 'eax' and on the stack; of course these two functions receive that in this way to yield a better optimization or size). This is one reason why I like asm's total control over stupid 'C' compilers/linkers. It's actually the compiler's fault (or linker), and isn't impossible to do either. But AFAIK no compiler or linker does that.

Is there such a hard-core optimizer out there, for every tiny thing?
Post 04 Sep 2007, 15:54
View user's profile Send private message Reply with quote
FrozenKnight



Joined: 24 Jun 2005
Posts: 128
FrozenKnight
Short answer NO. The only hard core optimizer out there is your brain.
Which is why i perfer asm over all the compilers out there.
Post 04 Sep 2007, 22:36
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki
The_Grey_Beast wrote:
so I can always change the size if I want to (for example, replace it with "unsigned short"). Of course this also means I have to type-cast when I need to dereference it, but that's ok anyways as 'types' are for me, a bad optimization (because they restrict yourself to only one type for a specific 'memory location' so to speak).


First, what is the point of being able to change the size?

In my opinion it only shows that you haven't thought things out carefully in the beginning if you need to change sizes half-way through the development process.

Second, instead of casting only when it is needed you cast all that time? Whatever way you look at it that doesn't count as an optimization in my book.

The_Grey_Beast wrote:
The only thing that annoys me, is the "Calling convention" (or any convention for that matter).


It would be a total chaos without conventions. By being annoyed by them you are again showing how disorganized you actually are.

The_Grey_Beast wrote:
I mean, why can't the stupid compiler just check through all the code and adjust the convention accordingly for better optimization?


Why don't you try to do that by hand for some larger project and let us in on the hard facts? Like giving us the performance numbers before and after such "optimization"?

The_Grey_Beast wrote:
but I'm kind-of like a perfectionist, and knowing that the code is junk in some areas (like function calls, etc) due to the compiler's stupidity, I have a feeling that just haunts me somehow.


You know, we have a saying here in Serbia:
"Selo gori, baba se češlja".
"Village is burning while the old woman is combing her hair".

It means you are devoting your attention to unimportant things.

The_Grey_Beast wrote:
My problem with Calling conventions


Your problem seems to be the lack of understanding of those conventions. Whether you are passing parameters via the stack or using the registers and stack, every compiler optimizes register usage in the whole executable.

The_Grey_Beast wrote:
Is there such a hard-core optimizer out there, for every tiny thing?


There is an optimizer which processes assembler output generated by compiler, it was mentioned earlier in this thread.

FrozenKnight wrote:
The only hard core optimizer out there is your brain. . Which is why i perfer asm over all the compilers out there.


The same brain writes the compiler. Actually, not one brain, dozens of brains. You seem to be holding yourself in high regard if you believe you are smarter than all of them together. High self-esteem is nice up to a certain point where it becomes pure arrogance and when it starts to inflate your own value by underestimating other's.
Post 05 Oct 2007, 22:50
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
levicki wrote:

You know, we have a saying here in Serbia:
"Selo gori, baba se češlja".

http://www.phrases.org.uk/meanings/fiddling-while-rome-burns.html
http://en.wikipedia.org/wiki/Great_Fire_of_Rome
levicki wrote:
...You seem to be holding yourself in high regard if you believe you are smarter than all of them together....
An alternative explanation for the remark is that one focused human, writing assembly language, can outperform a compiler, no matter how many people contributed to the creation of the software. In other words, one need not presuppose arrogance, nor is it necessary to invoke underestimation of the compiler writers. The software program, no matter how elegant, how swiftly executing, or how expensive to purchase, is nontheless still a program, not a thinking person.
In the end, what really matters, in my opinion, is readability, for that holds the key to modification as circumstances change. Is the compiler, authored by MANY people, going to be well documented? Perhaps!!! This could be an argument in favor of the compiler. If the assembly language version was sloppily constructed, even if faster than the compiled version, then it would not be superior, in the long run. In my experience, most large projects, whether constructed by single persons, or whole teams of twenty or fifty people, are poorly documented. In such a case, the compiler, created by fifty geniuses, OR the equivalent large ASM program, written by one lonely guy, would both, simply go into the wastebasket, as repairing either one was simply more expensive, than starting anew.
It was indeed, exactly this point--> the crucial importance of readability, that led me to argue against XOR, in favor of MOV, at the outset of this thread, since one does not improve readability through use of an unnecessary Boolean operation.
Post 06 Oct 2007, 11:28
View user's profile Send private message Reply with quote
levicki



Joined: 29 Jul 2007
Posts: 26
Location: Belgrade, Serbia
levicki


I am not certain if our saying has the same origin as that one. Anyway, my point was that optimizing across function calls is done reasonably well by the compiler and that being pedantic about it serves no purpose other than neglecting the optimization of real hot-spots in the code which should first be determined by profiling.

tom tobias wrote:
An alternative explanation for the remark is that one focused human, writing assembly language, can outperform a compiler, no matter how many people contributed to the creation of the software.


Focused human is not neccessary better. For example, I can focus myself on fishing, but since I know next to nothing about it, my results will most likely be poor, and any potential success will be purely by accident. So, before focusing one should be knowledgeable.

Furthermore, if I get obsessed about choosing the right fishing equipment and completely neglect the choice of a good fishing spot, my results will be poor regardless of the equipment I use. So before focusing one should also be rational and understand where to focus their effort.

In other words, optimization out of pefectionism is pointless, profiling is the only way to be sure you are optimizing the right part of the code.

tom tobias wrote:
The software program, no matter how elegant, how swiftly executing, or how expensive to purchase, is nontheless still a program, not a thinking person.


I hope you will agree that chess programs were written by teams of thinking persons, right?

If so, then how is it possible that the single focused thinking person cannot defeat such a program? Just think about it for a moment, and then substitute "chess program" with a "compiler" and hopefully you will understand what I meant when I talked about arrogance and high self-esteem.

tom tobias wrote:
In the end, what really matters, in my opinion, is readability


We already discussed that, no need to bring it up again. Readabilty is important but XOR in my opinion doesn't make code less readable to a thinking person.
Post 07 Oct 2007, 13:35
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.