Author: Matt Taylor
Date: 13:36:38 12/09/02
Go up one level in this thread
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. 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. -Matt
This page took 0.01 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.