1

I have tried most basic instruction "mov ax,B006H" and got the error message

error message

Community
  • 1
  • 1
Basilisk
  • 13
  • 4
  • I assume A000H doesn't work and that you really mean 16-bit values greater than or equal to A000h . The rule is that if you using the `h` suffix to denote a hexadecimal number, and value that starts with A, B, C, D, E, F the hex number must be preceded by a 0. Basically if you have a Hex number that begins with a letter (and uses an `h` suffix) you have to tack on a 0 to the beginning. – Michael Petch May 20 '20 at 17:11
  • 2
    It isn't just for 16-bit numbers. Without adding an extra 0 to the beginning for cases where the upper most digit is Ato F the assembler would have no way of knowing if `mov al, ch` means move register CH to AL or whether you meant move the hex value `c` (12 decimal) to AL. To do that you'd have to write `mov al, 0ch` . – Michael Petch May 20 '20 at 17:22
  • 1
    The error message tells you exactly what the problem is. – fuz May 20 '20 at 17:45

2 Answers2

3

Hexadecimal numbers must start with a decimal digit. That is why so many hex constants start with a leading zero.

This will work:

mov ax, 0b006h
wallyk
  • 55,472
  • 16
  • 84
  • 144
  • mov ax, 0b006h worked also mov ax, 0xb006h works too. – Basilisk May 20 '20 at 16:49
  • What do you mean be `even`? Oh you didn't mean "even" (as in evenly divisible by 2). For clarity I'd strike the word `even` – Michael Petch May 20 '20 at 17:25
  • 1
    @Basilisk if you use `0x` prefix don't put `h` on the end. Although EMU8086 supports that most other assemblers including MASM/TASM will give an error. Either use `0x` prefix or `h` suffix but not both. – Michael Petch May 20 '20 at 17:28
  • 3
    @MichaelPetch: It means that for the assembler to recognize a token as a numeric literal, it has to start with a digit, but *even* for hex numbers it has to be a decimal digit, not any hex digit. I think I mentally parsed it that way the first time I read it, but after seeing your comment it took me a few seconds for my brain to parse it correctly again. :P – Peter Cordes May 20 '20 at 17:29
  • 1
    @PeterCordes : Yeah in my comment suggested they consider striking the word `even` for clarity. – Michael Petch May 20 '20 at 17:31
  • @MichaelPetch: Great suggestion. Thanks! – wallyk May 20 '20 at 17:56
2
mov ax,0B006H

the parser is picky

Joshua
  • 38,744
  • 8
  • 68
  • 123
  • This is the older answer by 10 seconds. – Joshua May 20 '20 at 16:45
  • 1
    Older, but slightly less detail about why the parser is picky. In your answer it's left to the reader to work out why a leading 0 is necessary here. (Obvious if you think about how you'd write a parser / the ambiguity with symbol names, but not everyone will easily come up with that reasoning.) – Peter Cordes May 20 '20 at 17:33
  • @PeterCordes: I couldn't work out why because the assembler I used couldn't handle a symbol name there, but only [symbolname], so I though the parser was picky for no good reason. – Joshua May 20 '20 at 19:03
  • 1
    I'm curious what assembler you use; in both major flavours of Intel syntax (NASM and MASM), `mov ax, symbol` is valid. In NASM, it's a mov-immediate of the address. In MASM-like assemblers it's a load from the symbol address, same as `mov ax, [symbol]` – Peter Cordes May 20 '20 at 19:08
  • @PeterCordes: I learned on Borland C++'s asm {} blocks before I got a real assembler. – Joshua May 20 '20 at 19:13
  • @PeterCordes: I wrote quite a bit of 80x86 assembler code which didn't require any futzing (like using `ifdef` or whatever) for the code to assemble with both `masm` and `tasm`. – wallyk May 21 '20 at 03:36
  • @wallyk: I was including TASM in the MASM-like flavour group. They even use similar directives I think, unlike GNU gas `.intel_syntax noprefix` which is also MASM-like but uses completely different directives outside of instruction lines. – Peter Cordes May 21 '20 at 03:48