Index
> Main > To Privalov or Any Master in FASM? |
| Author |
|
|
JohnFound 01 Jan 2004, 22:37
Hi.
Well, I don't think I am a |Master", but I will try to answer you: FASM produces in most cases shorter code than other assemblers, because of it's multi pass architecture. It simply optimize the code and uses the smallest opcode for given instruction (especially for jumps). The speed of FASM is because of fact that it is written on assembler and the compilation scheme (algorithms) are optimized for speed. Regards. |
|||
01 Jan 2004, 22:37 |
|
|
Betov 02 Jan 2004, 00:52
All Assemblers written in Assembly (FASM, RosAsm, GoAsm) are, more or less (...) compiling at comparable speeds. My own tests shown me that GoAsm was a little bit faster, but this is very difficult to evaluate, because the speed depends also on many aspects, like the Macros system power, and so on...
For the sizes, all Assemblers output the same sizes. No matter if they are multi-pass, mono-pass or incremental, because the general rule, when some choice is possible between several identical Encodings (at a functionality point of view) are available, is that all Assemblers Authors choose the smaller form. For the short jump size, this is another problem, that depends on some 'ergonomic' choice. In no case it may have any importance on the generated Code quality. The fact of having the jumps sizes choosen by the Assembler or by the programmer does not change a thing at the size. Also, as a general rule, there is zero direct relationship between the Assembler speed and the outputed Code Quality. Betov. |
|||
|
02 Jan 2004, 00:52 |
|
|
fasm9 02 Jan 2004, 02:48
Hi,
Doesn't compiler produce assembly-or-intermediatecode-or-machinecode with more unused instructions than assembly? And i heard super optimized compiler is much faster than some hand-written assembly. -- In anycase, compiler which is written in FASM is the right choice. the consistency. the compiler also FASM to me. 
and btw, about the super compiler, here is a quote. christian_staudinger wrote: The link is just to download the software. You still need a license key. The license key you can order from a reseller who will send you a serial number you need to register. The registration will then send you the license key. Simultanously, the registration will give you access to Intel Premier Support. |
|||
|
02 Jan 2004, 02:48 |
|
|
scientica 02 Jan 2004, 12:00
fasm9 wrote: And i heard super optimized compiler is much faster than some hand-written assembly. The reason for this is: bad human optimizer, good/decent compiler optimizer. _________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
02 Jan 2004, 12:00 |
|
|
vid 02 Jan 2004, 15:56
scientica is right. Ask anyone who claims this to show you his assembly code and you 'll see the reason
 |
|||
|
02 Jan 2004, 15:56 |
|
|
madmatt 03 Jan 2004, 20:40
To answer your first question, I wouldn't worry to much about compiler speed, unless you plan on writing a million line assembly program on a 286 12 mhz computer.
To answer your second question, again, instead of assembly size, you should worry about what algorithm you would use, also, with processors like 486, pentium, pentiumII, etc., how you would order your instuctions, memory alignment, how the cache and cache instructions work (Something I need to do!). You also should look at simple tricks like these: instead of dividing a floating pointer number by 2, multiply it by 0.5, because the (FMUL) instruction is faster than (FDIV), in my experience. and a classic trick with integers, to mulitply eax by 4 use shl eax,2 instead of using the MUL instruction. Again program size and compiler speed are almost useless worries now. There are many more "tricks" than what I stated here. Just ask around and I'm sure you get much info. Also read the AMD/INTEL developer/technical manuals. |
|||
|
03 Jan 2004, 20:40 |
|
|
decard 03 Jan 2004, 20:49
BTW, there is a site (http://home.sch.bme.hu/~ervin/codegems.html) which contains many useful tips and tricks in assembly language.
|
|||
|
03 Jan 2004, 20:49 |
|
|
madmatt 04 Jan 2004, 19:20
 Forgot to mention in my previous post one more piece of information, such as code alignment is also a factor in assembly development. Also, here are some links that have information about General optimizations, and pentium specific optimiztions.
www.agner.org -> click the assembly programming link (view the other links as well! )
http://developer.intel.com/design/Pentium4/manuals/ -> IA32 Optimization manual  |
|||
|
04 Jan 2004, 19:20 |
|
|
Randall Hyde 06 Jan 2004, 17:53
Betov wrote: All Assemblers written in Assembly (FASM, RosAsm, GoAsm) are, more or less (...) compiling at comparable speeds. My own tests shown me that GoAsm was a little bit faster, but this is very difficult to evaluate, because the speed depends also on many aspects, like the Macros system power, and so on... So, IOW, the more powerful assemblers are slower because they have better macro facilities, right? Hmm... That's a good argument for using a *slower* assembler. You are right, though, the speed of the assembler depends entirely on the source code it's compiling. Some assemblers do better with one source code organization than others. I've got several example programs that show MASM beating the pants off assemblers like FASM, GoAsm, and RosAsm; I've also got lots of examples where FASM, GoAsm, and RosAsm beat the pants off MASM. The good news is that assembly speed is nearly irrelevant. For most practical projects, *all* of the assemblers (including the slowest) are sufficiently fast than most common source files get processed in under five seconds. So who really cares? Quote:
???? I guess that's why FASM consistently produces smaller executables than most other assemblers. It's displacement optimization is generally even better than MASM's (which is quite good). Quote:
Unless, of course, the assembler requires the programmer to manually specify the displacement size all the time. Then the assembler that handles this process automatically (like FASM) generally winds up producing smaller executables. The fact that the programmer *could* have specified smaller branch displacements and made the code smaller doesn't imply that in the typical case they would do so. FASM, for example, typically produces smaller programs than RosAsm (which requires manual intervention) because most people aren't going to take the time to check out each and every displacement in the code to determine whether it can be a small displacement versus a large displacement. Quote:
Wrong. Displacement optimization is a provably NP-Complete problem. While in the typical case this is not going to have an impact on the performance of the assembler, in degenerate cases this means that creating an optimal output file (minimized displacement sizes) is an intractible problem. IOW, for certain source files, optimizing the output slows down the assembler by a considerable amount. Fortunately, this has little impact on typical source files (though the multi-phase operation of such assemblers does consume time and this is noticeable on large/complex source files). Cheers, Randy Hyde |
|||
|
06 Jan 2004, 17:53 |
|
|
Betov 06 Jan 2004, 18:25
Master Pdf, when i come and post at FASM Board, (and/or at NASM Board), this is a friendly posting trying to contribute to friends efforts.
Also, i have to consider the desire of these friends to not enter into Holly Wars, on their own Boards. So do not expect any answer, from a guy like me, to a guy like you, here. Betov. |
|||
|
06 Jan 2004, 18:25 |
|
|
alf_ua 06 Jan 2004, 21:18
As I heart this compiler (Intel C++ and Fortran Compiler) is the best optimizating compiler and it can produce better code then regular programer on ASM?
What you think about that? _________________ Codeing is an ART ! |
|||
|
06 Jan 2004, 21:18 |
|
|
fasm9 06 Jan 2004, 22:09
First: it's better when it used with vs.net 2003. (i just installed it now!)
IMHO, (note that i am newbie, just saying crap with emotional *feeling*) gcc, intel c++, vc 7, bc++ all compiler-maker consider that total-organized optimization, they see the mountain, so they neglect the tree. assembler-maker see the tree(simply instructions?) and half-see the mountain(grammar checker and abstraction). Afaik, gcc is good at RTL(register transfer language) approach. and the others i don't know, i think it's secret because it's money. Rayiner Hashem wrote: Note that cmucl is very competitive with gcc. Intel C++ blew both cmucl and gcc away, but that has nothing to do with the language. Intel C++ has an auto-vectorizer that will automatically generate SSE code if it finds algorithms (like the dot-prod and scale in this benchmark) that can be vectorized. GCC and CMUCL don't support his feature. but c++ is quite hard to learn, even much harder to master it. once you 've familiar with it. you will have power because it de facto standard. c++ and asm is friend. http://www.research.att.com/~bs/C++.html (sorry for the link) -- anyway, some nice compiler which is written in FASM that i want. Last edited by fasm9 on 14 Jan 2004, 07:38; edited 1 time in total |
|||
|
06 Jan 2004, 22:09 |
|
|
Randall Hyde 06 Jan 2004, 22:21
Betov wrote: Master Pdf, when i come and post at FASM Board, (and/or at NASM Board), this is a friendly posting trying to contribute to friends efforts. Perhaps, but that doesn't mean you're always right; and it doesn't mean that when you post something that is absolutely incorrect it should stand uncorrected. And if you're going to make claims about "no holy wars", etc., drop the "master PDF" nonsense. My name is Randall Hyde, you may refer to me as "Randy", "Randall", or "Mr. Hyde" if you're going to play the "friendly" game. Cheers, Randy Hyde |
|||
|
06 Jan 2004, 22:21 |
|
|
decard 06 Jan 2004, 22:34
Maybe Intel wrote that their compiler generates the best code, but it's still a program, and it can't think in a way human can. On win32asm community board had beed many threads where people were discussing some routine to make it maximally optimized. I (as a newbie) was totally suprised that they were able to reduce number of clock ticks of a given routine so much... Of course you need to have experience to write such optimised code, but IMO good asm programmer will be always better than any HLL compiler.
fasm9: why do you think C++ is so hard to learn? There are many good books, and dozens of tutorials can be found over the net. Syntax of C++ is well organized, and very logical. Learning ASM is more difficult IMHO, because you need to know many things about your computer's internals (registers, memory organisation..etc)... but all in all assembler is better
regards |
|||
|
06 Jan 2004, 22:34 |
|
|
Madis731 07 Jan 2004, 00:34
...I got a story to tell. Some time ago a computer won against human being in chess. There was no logical thinking, but its all about clock tick's. The computer just tried all possible ways.
Now, as it comes to compilers, there is a time factor. When you give compiler some rules, the it can combine you some serious low-tick code, but where is the limit. Think of the different possibilities in a 10byte code. Now think of 10KB code. The bigger the code gets, the better human brain can apply its logic. Computers CAN beat us, but until they do 1's and 0's, they just DON'T have LOGIC. We just can't compare compiler<=>man just like that  yet  |
|||
|
07 Jan 2004, 00:34 |
|
|
Randall Hyde 07 Jan 2004, 02:26
Madis731 wrote: ...I got a story to tell. Some time ago a computer won against human being in chess. There was no logical thinking, but its all about clock tick's. The computer just tried all possible ways. It's far worse than you state. You give the impression that there is a 1000:1 difference in complexity between your two examples. In fact, there is as much as an n^1000 difference in complexity (n being roughly the average number of instructions per byte in the instruction set). Optimization, that is producing truly optimal code, is an intractible problem with no known efficient solution. As you point out, humans deal with "heuristics" much better than computers; that's why humans will usually win. OTOH, do keep in mind that humans *have* to work hard to reach those levels. While humans can adopt heuristics to help them produce a better 10KB program, the truth is that many inefficiencies will probably still exist in that code. The intractibility probably applies to humans as well as it does to machines. Humans just have the ability to ignore cases that don't look promising. Alas, they often ignore cases that turn out to be better, as well. The best optimization, ultimately, is going to be achieved when people start developing optimization tools that work interactively - with the machine doing what it does best (keeping track of minutea and details) and the human added what s/he does best (pruning the decision tree by leaps and bounds by applying intuition). Intel's VTUNE program, for example, is a tiny step in this direction. Cheers, Randy Hyde |
|||
|
07 Jan 2004, 02:26 |
|
|
Madis731 07 Jan 2004, 12:08
Me + Randall Hyde = Just what I wanted to say
 |
|||
|
07 Jan 2004, 12:08 |
|
< Last Thread | Next Thread > |
Forum Rules:
|