3

After much trial and error, I still have some trouble understanding why the assembly syntax used in my textbook caused so many issues when using Windows 8. 

    .MODEL  SMALL
    .586

    .STACK 100h

    .DATA
    Message DB  'Hello, my name blank', 13, 10, '$'

    .CODE
Hello PROC
    mov ax, @data
    mov ds, ax
    mov dx, OFFSET Message
    mov ah, 9h 
    int 21h 
    mov al, 0 
    mov ah, 4ch
    int 21h
Hello ENDP

    END Hello

At first I tried running the code with masm32, using the command prompt and correct linker. Then I tried using Visual Studio 2013 ultimate; even using masm32 within Visual Studio, I got the similar issues each time. The assembler had issues with the @data line, and no leading underscore for Hello. Fixing the latter only resulted in a issue with unmatched blocks.

I did find a workaround by using a MS-DOS virtual environment, and the code worked fine after removing the .586 instruction.

I suspect the main issues were trying to run this code in a x64 OS environment, but I'm still learning the language so I'd like to hear other opinions on why I couldn't get it to run initially.

The book we're using is Jones, Assembly Language for the IBM PC Family 3rd edition.

Welz
  • 236
  • 2
  • 10
  • 21
Los
  • 31
  • 1
  • 3
    Your code is 16 bit, which is no longer supported natively on 64 bit architectures. You need a DOS emulator for that. – Devolus Jan 21 '14 at 07:23
  • 1
    What exactly makes this code 16 bit vs 32 bit? What makes certain instructions ineligible in newer architectures? I've honestly only just began learning assembly, so it may seem like trivial questions, but I'm really fascinated in understanding syntax usage. – Los Jan 21 '14 at 15:23
  • 1
    if you wrote the code you should know it. Anyway, using `int 21h` means quite likely that you are writing a DOS program which is 16 bit. – Devolus Jan 21 '14 at 17:00

2 Answers2

0

You are using a 32 bit linker. You need to use the 16 bit linker called link16 in masm32/bin to link the code.

e.g.

ml /c /Fl filename.asm

-then-

link16 filename.obj
JBES
  • 1,512
  • 11
  • 18
0

The difference between the 16 bit and the 32 bit addressmode is the default size of the operands/registers and addresses inside of our codesegment and how the assembler use the operandsize and the addresssize prefixes.

Within the 16 bit addressmode the default size is 16 bit and if we want to use 32 bit register/operands and/or 32 bit addresses within the 16 bit addressmode, then our assembler have to place an operandsize and/or an adddresssize prefix to all of those 32 bit instructions. But if we use only 16 bit instructions within the 16 bit adressmode, then we do not need those operandsize and/or adddresssize prefixes.

Whithin the 32 bit addressmode the default size is 32 bit and if we want to use 32 bit register/operands and/or 32 bit addresses within the 32 bit addressmode, then our assembler do not have to place an operandsize and/or an adddresssize prefix to all of our 32 bit instructions. (This is good for to minimize the number of bytes of our code, if we use mostly 32 bit instructions.) But if we use 16 bit instructions within the 32 bit adressmode, then our assembler have to place the operandsize and/or adddresssize prefixes.

Additional there are two assembler directives(use16 and use32) for to determine for wich adressmode the code is written, if we want to have different parts of code for both addressmodes.

..

Beside both addressmodes there are also a large difference between the realmode and the protected mode. For the realmode in combination with the 16 bit Addressmode(default on startup) we become a default segmentsize of 64 KB segments and all addresses will be calculate together with the segment part of a segmentregister and the offset part for to build an address. For the protected mode we have to use global and/or local descriptor tables for to specify the size of a segment that we want to use.

...

At last the architecture of the underlying operating system give us the demands for the target for that we have to assemble our code and which software interrupts are aviable for to use.

Dirk

Dirk Wolfgang Glomp
  • 529
  • 3
  • 4