well Vyoma I think you sumed it up in a nutshell, in saying ASM sucks on x86 well how can that be? ASM is a hardware language whether it be on a computer or a chipset it your DVD player they rely on machine language (which asm is next best way of ready a bunch of 000's and 111's for a human) so all hardware rely's on ASM whether is a PHONE or a COMPUTER

ASM is used when direct programming and repeative functions that NEED QUICK RESPONSE in small space is needed. This can then be a common funtion\libary or file within your program. The most common programs you will see being written in ASM that are used on all machines are drivers. All driver files rely on ASM language to talk to individual hardware. The main use is asm besides graphics, drivers and os programming is RCE. It is a vital key to know asm programming for Reverse Engineering this can hold great knowlegdge for those who want to understand how other programmers think and archieve certain programming functions.


So in a conclusion ASM is not a preferred method for humans to use for BIG applications that are often update, manipulate and work on via alot of programmers that is why they invented 3GL programming. It is a lot easier to maintain and update programs writtin in languages such as C++ and JAVA. BUT ASM is great for maniputing HARDWARE were libaries or funtions aren't available to these programmers, or where the programmer is wanting a QUICK RESPONE ROUTINE in SMALL AMOUNT OF SPACE.

anywayz thats my 2cents, please feel free to correct me if I'm wrong

thanks

Yes prorip, you are right.

What you were saying about the 'quick responses' and 'small amount of space' made me go through Michael Abrash's books mentally. (I am like total fan of his works. I worship him - maybe because only his books where available back in those days on assembly, optimization and graphics put together).

I would like to tell you all one of the trick that he had up his sleeve, one that explained where to go for optimization. Consider the following pseudo code (with the relative time taken in the square brackets):

START
TASK A [10]
...
...
TASK B [10]
...
...
TASK C [120]
...
...
TASK D [10]
...
...
LOOP 500 TIMES
...
TASK E [10]
...
TASK F [40]
...
END LOOP
...
(the logic moves on)

Say, the values in the square bracket are time take for the task to be done when written in a 3GL (3rd Generation Language).

Now, if you notice the above code, on the first glance, we would jump at optimizing task C, since it takes way too much time. But according to Michael Abrash, and what I have found myself, optimization should be done for those that are repetitive. In the above example, Task F should be optimized.

Let us look at both the cases.

1. Case 'Task C' reduced to 50%:
Time saved = 120 - (120 x 50%) = 60

2. Case 'Task F' reduced to 50%:
Time saved = 500 x (40 - (40 x 50%)) = 500 x (40 - 20)
= 500 x 20 = 10000

3. Case 'Task F' reduced to 75%:
Time saved = 500 x (40 - (40 x 75%)) = 500 x (40 - 30)
= 500 x 10 = 5000

As can be seen, when both the optimization lead to reduction to 50%, optimizing Task F is better. (Case 1 Vs Case 2)
Even when Task F is reduced to only 75% as opposed to the whooping 50% of Task C, the time saved for Case 3 is way higher than that of Case 1. (Case 1 Vs Case 3).

Now these case are theoretical, but trust me, real-case senarious are a lot closer to this than we think.

Oops! I got carried away. Hope this not way off track, but what I was making a point is that Assembly when used with right strategy can lead to powerful applications.