2

I'm currently working on a MS-DOS .com file application using Turbo Assembler 1.0. The file starts with the following assembler directives.

 DOSSEG
.286
.MODEL tiny
.CODE
 ORG 100h

This assembles fine so far; however, if .286 is changed to .386 TASM generates error messages "Forward reference needs override". This is somewhat correct, as variables are accessed but defined later.

  1. Why don't these error messages appear when assembling with the .286 directive?
  2. What can I do to fix these error messages? If, for instance, there is a later variable definition like Variable dw ?, how can this be taken care of in an earlier reference? What is the TASM syntax for this?

Edit: Let me be more specific by giving full examples.

Version 1: Works fine.

      DOSSEG
     .286
     .MODEL tiny
     .CODE
      ORG 100h
Main:
     inc Var  
     ret
     Var dw ?
     END Main

Version 2: Error message "Forward reference needs override" (after enabling 386 opcodes).

      DOSSEG
     .386 ; <-- this has changed
     .MODEL tiny
     .CODE
      ORG 100h
Main:
     inc Var  
     ret
     Var dw ?
     END Main

Version 3: Also complains about "Forward reference needs override", although I believe to have indicated the size of the variable.

      DOSSEG
     .386
     .MODEL tiny
     .CODE
      ORG 100h
Main:
     inc word ptr Var ; <-- this has changed
     ret
     Var dw ?
     END Main
Codor
  • 17,447
  • 9
  • 29
  • 56
  • 1
    This question would be improved if your [mcve] included an example forward reference and definition. e.g. `mov si, OFFSET Variable` might be different from `mov ax, [Variable]`, since the latter could use 16 or 32-bit address size, but mov-immediate to a register could only use imm16. I don't know TASM so I don't know the answer, though. – Peter Cordes Aug 21 '21 at 15:36
  • @PeterCordes You are totally right; I cannot access the source code at the moment. Assume that e.g. ``inc Var`` generates the error, where ``Var`` is later defined as ``Var dw ?``. I think that it it possible to _declare_ a variable (and its type) whitout acutally _defining_ the location (which is done later), but I don't know the correct syntax for that. Thanks for the comment however! – Codor Aug 21 '21 at 15:44
  • `inc Var` doesn't even imply an operand-size except via the declaration / definition of the symbol; does `inc word ptr Var` make a difference? – Peter Cordes Aug 21 '21 at 15:53
  • Thanks @PeterCordes, but adding `word ptr` does not make difference. I totally agree, from ``inc Var`` it is impossible to know the operand size ; I just wonder if it can be specified. I think it should be possible, but I can't find any reference on how to do so. – Codor Aug 21 '21 at 16:01
  • 2
    What happens if you use multiple passes when assembling the ASM file with TASM. How about adding option `/m2` for two passes? – Michael Petch Aug 21 '21 at 17:02
  • Hi @MichaelPetch, thanks for your suggestion; however TASM 1.0 does not support multiple passes. This was introduced in later versions. – Codor Aug 21 '21 at 17:38
  • 1
    Ah I missed the mention of 1.0 in the question - sorry – Michael Petch Aug 21 '21 at 17:44
  • Nevermind, I can also try 2.0. But how to approach the problem in 1.0? – Codor Aug 21 '21 at 17:45
  • @Codor: `word ptr` *does* specify the operand-size. That's what makes it possible to unambiguously do `inc word ptr [si]` vs. `inc byte ptr [si]`, or to override the implied "word" size from a var you defined with `dw` in an instruction like `movzx ax, byte ptr [Var + 1]`, loading one byte of a `dw`. – Peter Cordes Aug 21 '21 at 17:55
  • 2
    What happens if you move `.286` after the `.model tiny` rather than before? – Michael Petch Aug 21 '21 at 18:28
  • Er... if I switch ``.386`` ``.MODEL tiny`` in Version 2, there are no complains. Thanks for your help, consider converting this to an answer. But why does this work, what is the difference?! That really made my day, but I would like to understand it! – Codor Aug 21 '21 at 18:34
  • 2
    I think part of the issue is related to this: https://stackoverflow.com/a/62603303/3857942 – Michael Petch Aug 21 '21 at 18:36
  • 1
    Thanks @MichaelPetch, your linked answer is really detailed. I think I will come back to that several times in the future! – Codor Aug 21 '21 at 18:41

0 Answers0