flat assembler
Message board for the users of flat assembler.

Index > Main > To Privalov or Any Master in FASM?

Author
Thread Post new topic Reply to topic
alf_ua



Joined: 18 Dec 2003
Posts: 11
Location: Ukraine, Lviv
alf_ua
Almost all assemblers are written on C and they compile source file to binary slower then FASM do. For example MASM32 is much more slower.
So the question is : Does this mean that CODE produced by MASM32, HLA, TASM or any other assembler will be bigger then code produced by FASM.
Offcource sometimes bigger program can run even faster then smaller one, but still it is good to get small compiled file (binary).
Can somebody make the list (FASM, NASM, MASM32, HLA are most interesting for me but you are welcome to add some other assemblers) with numbers 1-n (1 - the smallest code produced, n - the slowest).
I think this question will be very interesting to all people who are interested in assembler programming, because we use assembler for speed (at least I do so).
Thank you for your answer.

_________________
Codeing is an ART !
Post 01 Jan 2004, 22:25
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
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.
Post 01 Jan 2004, 22:37
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Betov



Joined: 17 Jun 2003
Posts: 98
Betov
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.
Post 02 Jan 2004, 00:52
View user's profile Send private message Visit poster's website Reply with quote
fasm9



Joined: 19 Jun 2003
Posts: 439
fasm9
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. Wink

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.

There is no difference between the ESD version and the CD version other than the media. Other than for Fortran, Intel doesn't offer printed manuals. All manuals are online.

Christian
Intel
Post 02 Jan 2004, 02:48
View user's profile Send private message Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
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
Post 02 Jan 2004, 12:00
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
scientica is right. Ask anyone who claims this to show you his assembly code and you 'll see the reason Smile
Post 02 Jan 2004, 15:56
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
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.
Post 03 Jan 2004, 20:40
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
BTW, there is a site (http://home.sch.bme.hu/~ervin/codegems.html) which contains many useful tips and tricks in assembly language.
Post 03 Jan 2004, 20:49
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Confused 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! Smile )
http://developer.intel.com/design/Pentium4/manuals/ -> IA32 Optimization manual Exclamation
Post 04 Jan 2004, 19:20
View user's profile Send private message Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
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:

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.


????
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:

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.

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:

Also, as a general rule, there is zero direct relationship between the Assembler speed and the outputed Code Quality.

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
Post 06 Jan 2004, 17:53
View user's profile Send private message Visit poster's website Reply with quote
Betov



Joined: 17 Jun 2003
Posts: 98
Betov
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.
Post 06 Jan 2004, 18:25
View user's profile Send private message Visit poster's website Reply with quote
alf_ua



Joined: 18 Dec 2003
Posts: 11
Location: Ukraine, Lviv
alf_ua
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 !
Post 06 Jan 2004, 21:18
View user's profile Send private message Reply with quote
fasm9



Joined: 19 Jun 2003
Posts: 439
fasm9
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. Wink


Last edited by fasm9 on 14 Jan 2004, 07:38; edited 1 time in total
Post 06 Jan 2004, 22:09
View user's profile Send private message Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
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.

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.


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
Post 06 Jan 2004, 22:21
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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 Wink

regards
Post 06 Jan 2004, 22:34
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
...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 Rolling Eyes yet Cool
Post 07 Jan 2004, 00:34
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Randall Hyde



Joined: 03 Dec 2003
Posts: 57
Randall Hyde
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.
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 Rolling Eyes yet Cool


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
Post 07 Jan 2004, 02:26
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Me + Randall Hyde = Just what I wanted to say Very Happy
Post 07 Jan 2004, 12:08
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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 cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.