i86 AS: use extern symbols as operands?

[johnathancn]

I am new to ACK (and pretty rusty on 8086 asm too...).

I have been poking around the old minix 2.0 source code and have been wanting to hack around with it... I thought it would be an interesting project to see what it would take to cross compile/build minix 2.0 from a modern linux environment. My understanding was that the original minix toolchain was built on some older variant of ACK so I figured this project would be a good place to start.

I have built ack and was able to compile a few C files but when it comes to ASM it chokes on lines like the following: https://github.com/davidgiven/minix2/blob/master/minix-2.0/fs/usr/src/kernel/mpx88.s#L116 inc _mon_return

Where the operand is a symbol not defined in that file. "./mpx88.s", line 116: bad operand

I've looked at the manpage for AS and didn't see anything for "importing" external symbols, it looks like "extern" is actually an "export" command.

Is the ACK assembler supposed to be able to support this kind of syntax?

[davidgiven]

'bad operand' is typically the assembler's response to anything it doesn't understand, which is less than helpful. The import command is .define (you can see a bunch further up the file). It's weird that this is failing to assemble given that Minix natively uses the same assembler --- although it's a different version.

[tkchia]

Hello @johnathancn, hello @davidgiven,

It seems that the mpx88.s source file uses an assembly language syntax that is different from what is now in ACK? E.g. I see that constants are referred to with # while address dereferences have no surrounding brackets, e.g.

    push    ds_ex_number
    call    _exception
    add sp,#2

In the syntax that is now implemented this would become something like

    push    (ds_ex_number)
    call    _exception
    add sp,2

So perhaps the complaint was that inc _mon_return was trying to increment a constant.

Thank you!

[davidgiven]

Hmm. Looking at the diffs for the 8086 assembler, it looks like it hasn't changed much. The 386 assembler got more work but still nothing major. It's possible that the assembler used for Minix got changed after it was forked, but I wouldn't know anything about that. The idea's plausible.

[o-oconnell]

@johnathancn @davidgiven there's a note about inconsistency between 16-bit and 32-bit syntax here: https://wiki.minix3.org/doku.php?id=ackassemblylanguage, mpx88.s runs in 16-bit real mode because it's part of the bootstrap program. I am interested in doing the same as @johnathancn - were you successful?

[davidgiven]

I actually spent a while poking at the 386 assembler (for another project). It's not great. It only has approximate knowledge of the difference between 16 and 32 bit code, and so if you accidentally use a 32-bit register or instruction in 16-bit mode it'll just go ahead and generate bad code. Its ability to handle instruction relaxation is also rather poor. I'm strongly tempted to just try and replace it entirely, which I realistically know is a terrible idea...