There is a problem to consult, this code? Call far PTR s machine code doesn't seem normal, it should contain the address and offset, but emu8086 are incorrect,

 
Assume cs: code 
The stack segment 
The db 16 dup (0) 
Stack ends 
Code segment 
Start: mov ax, stack 
Mov ss, ax 
Mov sp, 16 
Mov ax, 0 
Call far PTR s 
Inc ax 
S: pop ax 
The add ax, ax 
Pop bx 
The add ax, bx 
Mov ax, 4 c00h 
Int 21 h 
Code ends 
The end start 

CodePudding user response:

Is something wrong, so far call, it should be 9 a... Kind of instruction, FF, seems to be misunderstanding became indirect transfer calls, just coding is also wrong, if the tool has the special provisions on the instructions written?

CodePudding user response:

reference 1/f, zara's reply:

was as if some wrong, so far call, it should be 9 a... Kind of instruction, FF, seems to be misunderstanding became indirect transfer calls, just coding is also wrong, if the tool has the special provisions on the instructions written?

Running code, please use your tool, the results?

CodePudding user response:

I am using masm look after assembly instructions is normal,

CodePudding user response:

If this is it generated machine code, then assembly completely wrong, should also be indirectly call ff 1 e xx xx, but seems to be emu8086 are unlikely to have such a serious BUG

CodePudding user response:

Have just online to find an v4.08 under virtual machine tried, found support for far it is problematic,
Definition is far cheng properties, call it, compile-time tip error, let reference farfar_call_... Examples, see the provided three examples, are not directly call, but fill to the variable target address first, then call memory indirectly; JMP directly to the procedure, the compiler is passed, but the production code is not far type, like ordinary, can be short is short,
So, the software, should be simple introduction to use, not serious,