11

I'm learning how to create real mode programs assembled and linked with:

  • GCC Assembler version 2.25
  • Binutils version 2.25
  • GCC version 5.2.0

I use Intel syntax without prefixes specified with .intel_syntax noprefix

I want to load the address of a string into the SI register. I know, how to refer to a memory location in NASM, but when I do the same inside the GNU Assembler code, it only moves a WORD of the string into the register instead of the address of the label.

My code is:

.code16
.intel_syntax noprefix

mov cx, 11
mov si, name
mov di, 0x7E00
push di
rep cmpsb
pop di
je LOAD

When I compile it with GCC, I can see in the debugger that the processor does:

mov si, WORD ptr ds:0x7d2d

but I want the address of the string moved into the register, not the data it points at.

I also tried to put square brackets around the name like this:

.code16
.intel_syntax noprefix

mov cx, 11
mov si, [name]
mov di, 0x7E00
push di
rep cmpsb
pop di
je LOAD

It doesn't make a difference.

From NASM I know that this assembly code works:

mov si, name

NASM will generate the instruction that moves the address of name into register SI.

My question: Is there a way to force GCC using Intel Syntax with No Prefix to load the address of a symbol into a register?

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
TheDome
  • 343
  • 3
  • 10
  • 2
    After the fact I found a related question, with a [Stackoverflow answer](http://stackoverflow.com/questions/16121173/why-does-switching-from-att-to-intel-syntax-make-this-tutorial-segfault-using-g) that is similar . This question might be considered a duplicate depending on perspective. – Michael Petch Apr 27 '16 at 20:01
  • 1
    I found both questions (and answers) useful separately. This question _exactly_ described the problem I was having, as I was using direct system calls to Linux to print a string. The related question addressed a different problem I encountered when using the C standard library to print a string. – Ed Graham Jan 26 '22 at 12:34

1 Answers1

12

If you are using GNU assembler code (via GCC) with the directive:

.intel_syntax noprefix

Then the syntax can seem a bit unusual, and not well documented in canonical sources. This code:

mov si, name

Moves the 16-bit WORD at memory location pointed to by label name into SI. The following instructions do the same thing, although I prefer the square brackets [ and ] because the code's intent is clearer:

mov si, name              
mov si, [name]
mov si, word ptr [name]   # This is the same as two above in long form
                          #     The use of "word ptr" here is similar to MASM

To get the address of name and place it into the register you need to use offset like this:

mov si, offset name

If someone has a canonical source that actually describes the syntax that can be used with .intel_syntax noprefix please let me know in the comments. I am aware of blogs about the syntax, along with some contempt, but nothing official.

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
  • 3
    I haven't seen any open-source projects with `.intel_syntax` source files. Projects usually choose either AT&T-syntax, or use NASM or YASM. I can't think of / remember any specific reasons why GNU `.intel_syntax` is less good, though. e.g. I don't think there's anything you can do in AT&T syntax that you can't in `intel_syntax`, or extra ambiguities. (The downside for me is that it's like MASM syntax, while I prefer NASM syntax where `[]` is required for all effective addresses.) – Peter Cordes Apr 27 '16 at 20:50
  • 2
    @PeterCordes : I agree, and this syntax is not something I see often - I know of some of the ambiguities, but it is definitely one area that I lack first hand experience with. If I'm using GAS I'll usually settle for AT&T syntax, if I want Intel I'll use NASM, YASM etc. If you are stuck with GAS with no alternative and aren't use to AT&T syntax then I guess that might be a use case here. imagine my disappointment when I couldn't find a canon source for the complete syntax. Reading binutils source is too much like work ;-) – Michael Petch Apr 27 '16 at 20:54
  • 2
    Yeah, I expected it would be officially documented somewhere, too. I'm not totally shocked that it doesn't seem to be, though. For me, it's read-mostly format for disassembly / compiler output, not writing in. – Peter Cordes Apr 27 '16 at 21:02