Author Topic: JWASM ignores -0 and -1 parameter even when .286 directive is present  (Read 123 times)

bugthis

  • Regular Member
  • *
  • Posts: 20
When i use an assembler command like
Code: [Select]
; 286
SHR DL, 3
then i need the .286 directive in the source code too.
Because SHR DL, NUMBER does only work on a 80286 CPUs or better.
An 8086 needs the CL Register as a replacement for NUMBER.
Code: [Select]
; 8086
MOV CL, 3
SHR DL, CL

8086
Code: [Select]
; 8086 code
; Tests shift operator SHL, SHR with JWASM without .286 Directive
; Prog.Name:    s_test.asm
.MODEL SMALL, C

.STACK 256

.CODE
START:
  MOV     AX,0097h
  MOV     CX,0004h
  SHL     AX,CL
  SHR     AL,CL

  ADD     AX,3030h ; Create ASCII digits
  MOV     BX,AX

  MOV     DL,BH    ; Output upper digit
  MOV     AH,02h
  INT     21h
  MOV     DL,BL    ; Output lower digit
  MOV     AH,02h
  INT     21h

  MOV     AH,4Ch    ; return to DOS
  INT     21h
  END START

286
Code: [Select]
; 286 code
; Tests shift operator SHL, SHR with JWASM and .286 Directive
; Prog.Name:    s_test_2.asm
.MODEL SMALL, C
.286
.STACK 256

.CODE
START:
  MOV     AX,0097h

  SHL     AX,04h
  SHR     AL,04h

  ADD     AX,3030h ; Create ASCII digits
  MOV     BX,AX

  MOV     DL,BH    ; Output upper digit
  MOV     AH,02h
  INT     21h
  MOV     DL,BL    ; Output lower digit
  MOV     AH,02h
  INT     21h

  MOV     AH,4Ch    ; return to DOS
  INT     21h
  END START



So far so good. But when i assemble the 286 version with:
Code: [Select]
JWASMR -0 -mz s_test_2.asm
or
Code: [Select]
JWASMR -1 -mz s_test_2.asm

Then JWASMR doesn't complain, but it should. Because the manual says that the parameter options -0 produces a binary for 8086 CPUs and -1 a binary for  80186 CPUs or older.
https://www.japheth.de/JWasm/Manual.html#CMDOPT0https://www.japheth.de/JWasm/Manual.html#CMDOPT0

If i remove the .286 directive in the 286 code, then JWASMR complaines with an ERROR message like it should. But the -0 and -1 command line parameters are ignored.

_japheth

  • Member
  • **
  • Posts: 99
Re: JWASM ignores -0 and -1 parameter even when .286 directive is present
« Reply #1 on: November 16, 2022, 04:19:01 PM »
Then JWASMR doesn't complain, but it should. Because the manual says that the parameter options -0 produces a binary for 8086 CPUs and -1 a binary for  80186 CPUs or older.
https://www.japheth.de/JWasm/Manual.html#CMDOPT0https://www.japheth.de/JWasm/Manual.html#CMDOPT0

Well, the documentation is probably a bit unclear here. The "number arguments" just set the cpu to a default value, and this may be modified by the cpu directives ( .8086, .286, ...)
So, if you don't want to override the default, don't use those directives. There's the @Cpu equate that is set by both the arguments and the directives, maybe this helps?
The road to hell is paved with good intentions.

bugthis

  • Regular Member
  • *
  • Posts: 20
Re: JWASM ignores -0 and -1 parameter even when .286 directive is present
« Reply #2 on: November 20, 2022, 06:23:34 AM »
Well, the documentation is probably a bit unclear here. The "number arguments" just set the cpu to a default value, and this may be modified by the cpu directives ( .8086, .286, ...)
So, if you don't want to override the default, don't use those directives. There's the @Cpu equate that is set by both the arguments and the directives, maybe this helps?

I understand. So the argument numbers don't enforce the allowed CPU related assembly commands.

But when i want have a binary, that definitely runs on an 8086, how can i enforce it, that the assembler throws a warning or error, when an assembly command got used, that isn't for the 8086 CPU?

_japheth

  • Member
  • **
  • Posts: 99
Re: JWASM ignores -0 and -1 parameter even when .286 directive is present
« Reply #3 on: November 22, 2022, 01:40:33 AM »
But when i want have a binary, that definitely runs on an 8086, how can i enforce it, that the assembler throws a warning or error, when an assembly command got used, that isn't for the 8086 CPU?

Hmm, perhaps using the NOKEYWORD option?

By disabling anything beyond .8086 the source must stay with 8086 opcodes.
The road to hell is paved with good intentions.