Author: Robert Hyatt
Date: 13:52:34 12/09/02
Go up one level in this thread
On December 09, 2002 at 16:36:38, Matt Taylor wrote: >On December 09, 2002 at 14:00:38, Robert Hyatt wrote: > >>On December 09, 2002 at 12:43:13, Matt Taylor wrote: >> >>>On December 09, 2002 at 11:12:10, Dieter Buerssner wrote: >>> >>>>On December 09, 2002 at 10:11:54, Matt Taylor wrote: >>>> >>>>>>Thanks. Could not find the "1f" or "1b" stuff anywhere on the web or in the gcc >>>>>>docs/info pages. >>>>>> >>>>>>Bob >>>>> >>>>>I've never seen that particular behavior documented, but I know the 1f/2f/1b >>>>>stuff is common in GNU assembly. >>>> >>>>It is documented in the GNU assembler manual: >>>>--- >>>>Local Symbol Names >>>>------------------ >>>> >>>> Local symbols help compilers and programmers use names temporarily. >>>>They create symbols which are guaranteed to be unique over the entire >>>>scope of the input source code and which can be referred to by a simple >>>>notation. To define a local symbol, write a label of the form `N:' >>>>(where N represents any positive integer). To refer to the most recent >>>>previous definition of that symbol write `Nb', using the same number as >>>>when you defined the label. To refer to the next definition of a local >>>>label, write `Nf'-- The `b' stands for"backwards" and the `f' stands >>>>for "forwards". >>>> >>>> There is no restriction on how you can use these labels, and you can >>>>reuse them too. So that it is possible to repeatedly define the same >>>>local label (using the same number `N'), although you can only refer to >>>>the most recently defined local label of that number (for a backwards >>>>reference) or the next definition of a specific local label for a >>>>forward reference. It is also worth noting that the first 10 local >>>>labels (`0:'...`9:') are implemented in a slightly more efficient >>>>manner than the others. >>>> >>>> Here is an example: >>>> >>>> 1: branch 1f >>>> 2: branch 1b >>>> 1: branch 2f >>>> 2: branch 1b >>>> >>>> Which is the equivalent of: >>>> >>>> label_1: branch label_3 >>>> label_2: branch label_1 >>>> label_3: branch label_4 >>>> label_4: branch label_3 >>>>[...] >>>>--- >>>> >>>>There is a small contradiction: "N repreresents any positive integer" >>>>and later: "the first 10 local labels (`0:'...`9:')" >>>> >>>>>I would have suggested nasm syntax, but that wouldn't get inlined, >>>>>unfortunately. >>>> >>>>gcc cannot produce nasm output from C-code. I guess the inlining part would >>>>actually work - but wouldn't be of any help, of course. >>>> >>>>Regards, >>>>Dieter >>> >>>I know. >>>gcc produces gas code. I find gas distasteful, but that's probably because I >>>learned Intel syntax first. >>> >>>-Matt >> >> >>Actually "gas" uses the "AT&T assembly format" which is a well-known standard >>to those of us using unix for any length of time. :) >> >>I personally think AT&T syntax is better. Much less typing, such as in >>movl which moves a 32 bit word, rather than having to add dword ptr to >>the operand when it isn't clear... >> >>I find it makes the code easier when the instructions have less internal spaces >>(as >>in the dword ptr case above) to deal with as my "parser" is getting "old". :) > >How does AT&T syntax resolve the movzx instruction? You can move 8-bits or >16-bits -> 32-bit register. I guess they have movzxs and movzxb? > >The only ambiguous instructions in all of IA-32 are movzx and alu [mem], imm. >They're the only instructions that -need- prefixing with "dword ptr" and such. I >personally don't mind the operand size suffix on the instruction; it's the >logical ordering (as opposed to Intel's backward ordering) and %'s that drive me >nuts. I am so used to reading Intel format that the src-dest ordering throws me >off and makes it difficult to read. Whether you like src,dst or dst,src is probably based on your experience and which you encountered first. As far as the % goes, I personally like that. %eax is a lot clearer than eax. eax and eay look close but one is a reg and one is not. I've used the % notation for a long time and many vendors chose to go that route (Sun is one, for example). Again, it is a matter of preference, but the syntax mov eax, [dword ptr ebx] just plain looks ugly to me... movl (%ebx), %eax Seems to be cleaner, but again, personal preference rather than absolute factoid... > >Also, the "dword ptr" comes from masm. Nasm is a different, cleaner syntax. All >memory is enclosed in brackets. Variable names outside of brackets represent the >address of the variable. Masm/Intel will dereference, and that is both confusing >and annoying. > >The major idieosyncrasy is the meaning of word and dword which are >counter-intuitive. Windows SDK is quite amusing because it's so coupled with >Intel terms. They likewise make the silly use of word and dword. It's worse with >64-bit though. They have several interesting types: INT64, LONG64, DWORD32, >DWORD64, and my personal favorite, __int3264. The world would be a better place >without this nonsense. Yep. however, even the ANSI C committe could not agree on what to do with things from int, short, long and how to specify 64 bit ints... so I doubt a vendor will come up with something palatable. :) :) > >-Matt
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.