flat assembler
Message board for the users of flat assembler.

Index > Heap > GAS vs FASM

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
tom tobias wrote:
As a native speaker, educated half a century ago, therefore probably completely out of touch with everyone else, may I suggest, only an opinion, not a fact, that it is natural to provide source, then destination.

My opinion (though applied more to experience with Polish, not English) is that this may depend on which one is more important for you at the moment. When it is more important for me what should happen at the destination point, and not so important from where thing comes, then i would be "natural" to provide destination first. If the object itself is more important for me, and the destination only some perhaps temporary container for it, then it's "natural" to provide source (the object itself, in this case) first.
Of course this all with keeping in mind that "natural" may mean nothing more than our habits.
Post 25 Jan 2007, 11:32
View user's profile Send private message Visit poster's website Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
Tomasz Grysztar wrote:
I notice one nice thing about it: since the destination operand always comes first (and since people usually align instruction and the operands in the two columns) you immediately see the operand ON which the operation is performed.

Thats very close to the actual reason.
x86 is based upon the paradigm that all operands may have different from none to 3 sources, BUT only ONE destination (aside some few exceptions like xchg and some CPU management/context instructions, maybe MUL/DIV), and this is even more true for ther, less bloated instruction sets.

if you wrote the one destination at the right like this
Code:
mov     eax,edi
imul    [some_memory],100h,edi
mov     eax,[esi+ecx*8+100h]
    

you would indeed have more difficulties to see where the destination is cause the operands are not one-upon the other.

Whereas if you write destination first at the left:
Code:
mov     edi,eax
imul    edi,[some_memory],100h
mov     [esi+ecx*8+100h],eax
    

It's way more easy

_________________
MCD - the inevitable return of the Mad Computer Doggy

-||__/
.|+-~
.|| ||
Post 25 Jan 2007, 11:58
View user's profile Send private message Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
When I was learning assembly I thought this was very weird (destination first, and then source).
But now I like it a lot, and can't work with AT&T syntax. I think I got used to thinking in reverse way.
But Tomasz has pointed some nice feature of using the intel syntax. You first see the destination, which is more important.


Also, when you program in pascal or C you see destination first too:
Code:
somevar := anothervar;

x = 2 + 2;
    


and in intel syntax:
Code:
mov [somevar], 4
    
Post 25 Jan 2007, 19:26
View user's profile Send private message Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
tom tobias wrote:
Richard Blum wrote:
One unique feature of GAS {GNU assembler} is its ability to create instruction codes for a platform other than the one you are programming on. (page 42)
The AT&T opcode syntax originated from AT&T Bell Labs, where the UNIX operating system was created. It was formed based on the opcode syntax of the more popular processor chips used to implement UNIX operating systems at the time....unfortunately, Intel chose to use a different opcode syntax. (page 49)
One feature of GAS which I prefer, is that it uses, as Blum explained, the OLDER cpu ideas, including the preferred notion, at least preferred to those of us accustomed to old things, Smile of using SOURCE, DESTINATION, rather than Intel's obtuse, arcane, and counterintuitive notion of destination first, then source. At least in English, maybe not in other languages, we explain our port of embarkation, prior to offering our place of destination, so I find GAS more intuitive, than Intel. Still difficult for me to read Intel code, what with all the xor's and @@@@@.
Confused

first, thanks for the book tip Smile (I might actually try to find it - the example chapter I found here http://www.thattechnicalbookstore.com/b0764579010.htm looks quite nice)

second (maybe Blum should answer this), why would you want to render instructions for other CPUs than the one you write for? (asm is so deeply tied with the target CPU and (possibly) using CPU specific stuff that simply letting some instructions be "generic/portage" is quite pointless, and it wouldn't guarantee portable assembly code in any way - especially when some of the instructions aren't "portable").

Well back to the part about "src, dest", vs. "dest, src", I think it's a question of habit. To me Intel's more natural as it's like most HLL's (eg Ada, Pascal, etc (etc "Dest := Src;"), or LISP "(setq Dest Src)" (otho that's "bad/improper" usage of a functional language to use variables in such a (imperative?) way Wink).
Btw "substituting B for A" or "replacing A with B" (I hope I got the order right on the first one) -- "mov a,b" or "movl %b, %a" Wink

Also in pseudo code (eg the one in the Intel manuals) it's quite often you can see assignments in the form:
something <- value
but, in eg TI-BASIC (Basic dialect used on Texas Instruments' calculators) assignment is done with "->" eg:
sin(A) -> X
(would store the value of sin(A) in X )
and I think PostScript does it this way:
/x a sin def
(should make x = sin(a))

f0dder wrote:
I don't read source code as English.

You('d) probaly hate COBOL then Wink "DIVIDE NUMERATOR BY DENOMINATOR GIVING X."
(sorry just couldn't resist, yes, I'm getting more and more damaged by studying CS Razz (though, we've only been show examples of COBOL (not coded in it), and heard about idiocies like that you can make 1 = 2, so that "ADD 1 TO A GIVING X.", would make X get the value A+2 instead of A+1 -- not sure about the syntax but I think "ADD 1 TO 1 GIVING 1." should make 1 = 2 -- speak of horrible language Smile))

_________________
... 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 25 Jan 2007, 21:04
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
vid wrote:
allright, read these for me

Allow me please to clarify my point. I do not defend GAS, nor do I proclaim that Intel's awkward notion is "wrong". In fact, if one is used to thinking in Arabic or Hebrew, it is probably NORMAL. My trouble is, I am accustomed to thinking, if at all, in English, and we work from left to right, not right to left, as the Hebrew native speakers write. For the Intel engineers, Israeli, Hebrew native speakers, the syntax is logical. For me it is grotesque. I have a similar problem when in Nigeria, India, Pakistan, Japan, England or Australia, because they drive all their busses, and automobiles and trucks clockwise, and I am accustomed to the method used in Russia, China, USA, Canada, Italy, France, Germany, Spain, Poland, Denmark, and Sweden, i.e. counterclockwise. As Tomasz indicated, it is a matter of taste, though the rotation of the earth ought to dictate the superiority of one method or the other ( does it spin clockwise?) We ought to live in harmony with nature........
The GAS syntax is horrible to read, filled up, as it is with (unnecessary) punctuation symbols, which I detest. They use these symbols to ensure compatibility across different cpu architectures. I am disinterested in such nonsense. I prefer a well written assembler, based upon a more rational cpu design, one which does not limit a person to FOUR miserable registers, three of which have implicit additional functions. There is NOTHING about the cpu design of Intel that I find attractive. I use it only because it is the least expensive, but certainly not because of some supposed speed advantage....vid, if you understand my disenchantment with GAS' use of punctuation symbols, then you can also understand my irritation with @@@@@@.
Smile
Post 25 Jan 2007, 21:48
View user's profile Send private message Reply with quote
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
tantrikwizard
tom tobias wrote:
As Tomasz indicated, it is a matter of taste, though the rotation of the earth ought to dictate the superiority of one method or the other ( does it spin clockwise?) We ought to live in harmony with nature.......

Laughing I think it depends on which pole you consider 'up' from outer space LOL
Post 25 Jan 2007, 23:04
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
MHajduk



Joined: 30 Mar 2006
Posts: 6034
Location: Poland
MHajduk
I think, that we could make peace between fans "mov dest, src" and "mov src, dest" syntax. See here: http://board.flatassembler.net/topic.php?t=6606 Smile
Post 26 Jan 2007, 12:26
View user's profile Send private message Visit poster's website Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
MHajduk wrote:
I think, that we could make peace between fans "mov dest, src" and "mov src, dest" syntax. See here: http://board.flatassembler.net/topic.php?t=6606 Smile


I guess you could make macros to make FASM parse C too.
Post 26 Jan 2007, 12:51
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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. Also on YouTube, Twitter.

Website powered by rwasa.