DOS ain't dead

> Module: VV.OBJ(C:\CALSRC24\vv.asm)
>
> 10fb:0c7e      activpg
>
> [...]
>
> Why would Watcom think "activpg" is at two different addresses? (3461:0C4C
> versus 3461:027C)

Isn't that three addresses? The map has it at an even address, not a multiple-of-4. But yes, it's very weird that consecutive instructions are using a different address. Can you look at the object file, does that have the two addresses?

Another question is: since the address is in bx, why not just use [bx]?

> I linked a large memory model executable v.exe

> _NULL CODE DGROUP 10fb:0000

> Why would Watcom think "activpg" is at two different addresses? (3461:0C4C
> versus 3461:027C)

It's almost certainly a memory model conflict.

In the large memory model, code sections aren't part of DGROUP.

More analysis isn't possible, since you didn't provide a full map file.
Wasm doesn't support to create a listing file, but - as Rugxulo suggested - wdis may be used for a disassembly listing.

---
MS-DOS forever!

> Why would Watcom think "activpg" is at two different addresses? (3461:0C4C
> versus 3461:027C)

Comparing 0x0C4C-0x027C=0x09d0 with the map file indicates that there is some _DATA segment related offset being used while this should be a DGROUP related offset.

As WASM generates group related offsets when encountering something like this:

dgroup group data
data segment
x   db 2
    mov  bh, byte ptr [y]
data ends
end

as shown in the following decoded OMF fixup record (decoded with OMFDUMP, the important part is the "frame method"):

9c FIXUPP16      6 bytes, checksum 7F (valid)
   FIXUP  segment-relative, type 1 (16-bit offset)
          record offset 0005
          frame method F1 (GRPDEF) index 0001 'dgroup'
          target method T4 (SEGDEF) index 0001 'data'


this is indeed puzzling. Can you upload the .OBJ file? Then I can verify via OMFDUMP if the corresponding fixup in the OBJ is correct.

mov bx, offset symbol_name loads the BX register with the address of the symbol, which is an immediate number.

mov bh, byte ptr [symbol_name] uses the symbol as a pointer and copies the contents of that memory address into the BH register.

mov bh, byte ptr symbol_name copies the value from the symbol's own memory address into the BH register.

When you are writing assembly, the symbol also probably resides in the code segment, so what you want to do is loading a 8-bit register with the value of that symbol, what you probably want to do is

mov bh, byte ptr cs:symbol_name

In any case you should always make sure that the segment registers point into correct paragraphs. But sometimes it's just more efficient to do a segment override instead of loading the segment registers with new values.

In large memory model, if the symbol is in the DGROUP segment, you first have to load a segment register (either DS or ES, or GS/FS if you use a 386+) with the paragraph address where DGROUP starts before you can access the symbol. Be sure to also save and restore the value of the segment register before modifying it.

Accessing data where DS points to does not need a segment override, but other segment registers need it. In other words, DS is the default segment.