Currently the overall architecture of this is acceptable, but pretty hideous. The choices were made for various different (not necessarily correct) reasons at the time when this was written, but needs a fixing to some better choices now.

• There is one lalrpop file which generates the "initial" parser, whose job is to take raw text input, make sure the syntax is correct, and generate list of label maps, data and code instructions ( as strings).
• Next is interpreter which , again, takes the instructions as string, parses them and runs them.
• Finally there is a print parser, dedicated to parse and run print instructions.

This is horrible for many reasons :

• three parsers means it takes a lot of time to generate each from lalrpop file, pretty irritating for dev
• print parser does not need to exist, its syntax is simple enough to manually lex and parse it
• Because initial parser uses default lexer from lalrpop, which
  • does not report \n, so we have to go through input before everything for making newline mapping
  • because the way we define tokens using regexp , there are conflicts when we define two token which are overlapping, eg see issue #5 (comment) , here the issue is the regexp for db text gobbles up everything upto the last quote (the last quote it can find, so it includes the next 'db' and the text as string). If we try to fix that regexp, it collides with string regexp. We cannot stop the db string at EOL, as lalrpop does not give access to \n
• We really don't need to parse the instructions again from text for the interpreting. We can just use an enum to indicate instructions and store related params in it, and match on it , which will be a much better scheme overall.

Currently the two strategies are :

• make a custom lexer which will be used with lalrpop as parse to do the initial parsing. The custom lexer will take care of newline mapping, as well as considering capital/small letters.
• Make a custom lexer + (recursive decent?) parser, and remove the lalrpop dependency completely

Even though second option is desirable, it is equally tricky, so first shifting to custom lexer, than a custom parser separately might be a better way.

Either way, we should make the initial parser generate enum instead of text again and remove "interpreter parser", and remove print parser as well.

Tracking:

• Remove Print parser with custom lexer+parser
• Add lexer for "normal" asm , i.e. the main lexer (possibly integrate with print parser somehow?)
• Integrate this lexer's token into lalrpop with custom token support which lalrpop provides, so at least the issue mentioned above can be mitigated in short term
• Define enum for asm opcodes, so the original / lalrpop parser can (eventually) emit this instead of text
• Port "initial" parser from emitting text instruction to the enum defined above, simultaneously port the "interpreter" from lalrpop to a giant match stmt on this enum values
• Add a custom (recursive decent) parser for the "initial" parser, so that lalrpop dependency will completely removed. This is still up for discussion , need to see if that will actually provide any benefit , otherwise with custom tokens, the lalrpop parser file will be much simpler anyways.

Just noticed that the 8086 manual also include hex codes for instructions, if we can use them, we can actually store instructions in the memory and remove that barrier.

`start:
;JG, JGE Bug:
MOV AX, 20
MOV BX, -10
CMP AX, BX
JG AX_GREATER_THAN_BX ;JG, JGE is for signed numbers
MOV AX, 0 ;But no jump made
AX_GREATER_THAN_BX: ;Must jump here
MOV AX, 0

;JL, JLE Bug
MOV AX, 20
MOV BX, -10
CMP AX, BX
JL AX_LESSER_THAN_BX ;JL, JLE is for signed numbers
MOV AX, 0 ;Must no jump
AX_LESSER_THAN_BX: ;Jumps here
MOV AX, 0`

I tried:

start:
MOV AX, 0xFFFF
ADD AX, AX

Expected: AX = 0xFFFE, CF = 1, OF = 0
Got: AX = 0xFFFE, CF = 1, OF = 1

My understanding from Peter Cordes's analysis is OF is always tracking CF which is not right. https://stackoverflow.com/a/75679804/14768

As from a mail received :

start:
MOV AL, 0xF9 (-7)
MOV BL, 0x02 (2)
IMUL BL

It gives the result of 01F2. This answer is the result of unsigned number multiplication (MUL).
It is expected to give the answer of FFF2 (-14).

This is because of a bug in imul implementation which does the sign extension + expansion incorrectly.

Normally next will print the instruction about to be executed, but for some instructions (maybe the "singleton data" family?) it prints the following one instead. (It does seem to execute the correct one.)

Given the following input file:

start:  pushf
        add bx, 1
        pushf
        add bx, 2
        pushf
        add bx, 3
        popf
        add bx, 4
        lahf
        add bx, 5
        sahf
        add bx, 6
        xlat
        add bx, 7

Running with -i and entering n every time (e.g. by piping in yes n), the output is:

About to execute line 2 :         add bx, 1
>>> About to execute line 2 :         add bx, 1
>>> About to execute line 4 :         add bx, 2
>>> About to execute line 4 :         add bx, 2
>>> About to execute line 6 :         add bx, 3
>>> About to execute line 6 :         add bx, 3
>>> About to execute line 8 :         add bx, 4
>>> About to execute line 8 :         add bx, 4
>>> About to execute line 10 :         add bx, 5
>>> About to execute line 10 :         add bx, 5
>>> About to execute line 12 :         add bx, 6
>>> About to execute line 12 :         add bx, 6
>>> About to execute line 14 :         add bx, 7
>>> About to execute line 14 :         add bx, 7
>>> 

I have this string declared like the helloworld example:
hello: DB "Hello World" ; store string

Now I have just one instruction:
LEA DX, hello

it should load the address of hello string inside DX but it doesn't compile.

Errors:
Syntax Error at line 5:16 : LEA DX, hello : Unexpected Token : hello

Thank you!

PS:
Please can you implement service 0x09 (MOV AH, 0x09) with INT 0x21 ??? This way I could easly print strings like with EMU8086.

Hi,

I try to compile perfectly valid code with a procedure call, but I get this weird message:

Syntax Error at 27:0 : call f1 : 'call' can be only used with procedures, f1 is not a procedure

I wonder how does the emulator determines that 'f1' is not a procedure, when it is a valid label in my code:

f1: 
push bp
mov  bp, sp
mov ax, ax
pop bp
ret

Moreover, I note that in the web app, bp is not syntax-highlighted, which is strange and makes me think of some implementation lacking.

Any clarifications are highly appreciated.

Hi, can you help to make to software web interface for my BLIND student to program on 8086 ?

Miguel

If IDIV would produce a quotient of 0x8000 (word) or 0x80 (byte), the real 8086 traps (INT 0, divide overflow). 8086-Emulator yields 0x8000 and continues. (Note this behavior changed between 8086 and 80386, not sure what the 80186/80286 did.)

The nop instruction is not implemented.

With ds = 0, mov word [0xffff], 0xbeef should write bytes 0x0ffff and 0x00000: the offset should wrap around but not propagate its carry. Instead it writes 0x0ffff and 0x10000.

To fix this, I think one needs to change inc_addr to take a segment and offset, instead of just a linear address.

`inputBufferSize: DB 64
inputBufferAddr: DW 10

start:
;Input string
MOV DI, word inputBufferAddr ; DI ← 10
MOV BL, byte inputBufferSize
MOV byte [DI], BL;offset inputBufferSize ;[10] ← 64

MOV DX, DI

MOV AH, 0x0a
INT 0x21

;Output string
MOV DI, word inputBufferAddr
INC DI
INC byte [DI] ; Bug. Need this correction to workaround (counter + 1)

mov CH, 0
mov CL, byte [DI]
INC DI
MOV BP, DI

MOV AH, 0x13
MOV AL, 0x01
MOV BX, 0x00
MOV DL, 0
INT 0x10

The algorithm performed by the ASCII Adjust After Addition instruction is documented as always clearing the upper nibble of AL. However, the current implementation does not do so.

From https://www.felixcloutier.com/x86/aaa:

IF 64-Bit Mode
    THEN
        #UD;
    ELSE
        IF ((AL AND 0FH) > 9) or (AF = 1)
            THEN
                AX := AX + 106H;
                AF := 1;
                CF := 1;
            ELSE
                AF := 0;
                CF := 0;
        FI;
        AL := AL AND 0FH;
FI;

This can be fixed by adding the bitwise and in the aaa implementation.

In the push/pop instructions, the value of ss is multiplied by 0x10 before passing to Address::calculate_from_offset:

But the latter multiplies by 0x10 again:

So ss effectively gets shifted 8 bits instead of 4.

You can reproduce with

mov ax, 0x1000
mov ss, ax
mov sp, 0x20
mov bx, 0xdead
push bx

and note that address 0x0001e gets written instead of 0x1001e as it should.

mul bl currently sets the carry and overflow flags if ah was nonzero on input. It should set them if ah is nonzero on output. I think somebody misread the manual.

The same goes for the other multiply instructions. Additionally, the flag set logic in IMUL is incorrect. It clears/sets them according to whether AH is equal to 0xff. Instead they should be cleared if AH equals the sign bit of AL (0xff or 0x00 as appropriate), otherwise set.

The 8086 XLAT instruction can take a segment override prefix. Currently the emulator has no way to express this.

One option that would be reasonably consistent with 8086 assembly would be xlat byte es [bx]. Of course no other addressing mode besides [bx] would be valid here. (Actually, I believe the original assembler would let you write some other addressing mode but just ignore it.)

To avoid the parser awkwardness, they used xlat for this "one operand form" and xlatb for the zero-operand form where DS is assumed.