Difference in MASM and WASM handling EXTERNAL Structs- "assume" affects address

[brianvs]

My first thread here. I downloaded MASM32 a couple of days ago, thankyou for all of the hard work in maintaining it. I've used MASM since V2 came out and Macro-80 before that. I still use MASM V5.1 for real mode. I probably still have the V2 manuals and all my old IBM Tech Ref manuals. Remember back when the reference manuals had the BIOS source code and board schematics in them?

Mostly I've used the Pharlap 386asm since the late 1980s, current with V8.0, and the Microway Compilers to develop 32-bit code for embedded processors, currently the ICOP VortexDX series.

I've started rewriting a LOT of assembly, FORTRAN, and C for the WATCOM compilers, the V2 fork. The compiler properly generates code for the PharLap TNT environment, which is what I like to use for realtime processing. The WATCOM handles Fortran Common blocks as External Structures, different from the Microway Compilers. I'm converting common blocks in 386asm to Extrn Struct. Just ported my INT0 interrupt handler to WATCOM Fortran/Assembly, which uses common blocks for communications.

I've encountered a difference between the Watcom WASM vs 386ASM and MASM32 concerning the Assume directive.
With MASM32 and 386ASM, the code works properly when "assume ds:dataseg" is used. When this code is assembled in WASM, the address generated for the external structure is wrong. The WASM assembler requires "assume ds:nothing" to work, then generates the same correct address as MASM32 and 386ASM. "assume ds:nothing" produces errors when assembling the code under MASM32 and 386ASM, cannot access label through section register.

If anyone has an explanation, I would appreciate it. If anyone also used WASM, might be nice to know. So far I've converted 5000 lines of PharLap assembly routines to work with the Watcom compilers. I have more assembly to convert, but having common blocks and interrupts working was the hard part. This is the first difference encountered in MASM32 and WASM.

Some of the segment directives of 386asm have changed, I have more learning to do and will have some questions.

 

        TITLE   COMMON TEST
        NAME COMVLU
        .586p
        .387
        assume  cs:codeseg
;        assume  ds:dataseg         ; USE FOR PHARLAP ASSEMBLER AND MASM32
        assume  ds:nothing          ; USE FOR WATCOM WASM
        assume  ES:NOTHING

dataseg segment dword use32 public      ;
align   4

TESTNAME STRUC
INT1    DD      ?
INT2    DD      ?       
ARRAY   DD 100 DUP (?)
TESTNAME ENDS
; USE FOR MICROWAY COMPILER
; CMTEST EQU _cmtest_   
EXTRN CMTEST:TESTNAME
;
;       INTEGER* 4 FUNCTION COMTST( CMOFST)
;
CMOFST= 0
dataseg ENDS
codeseg segment dword public use32
CMNBGN  PROC NEAR
        PUBLIC COMVLU
        PUBLIC _comvlu_
_comvlu_        LABEL NEAR
COMVLU          LABEL NEAR
; LOAD EBP WITH ADDRESS OF ARGUMENT LIST.
        PUSH EBP                ; SAVE EBP.
        MOV EBP,ESP             ; COPY STACK POINTER.
        ADD EBP,8               ; ARG LIST IS NOW 8 BYTES FROM TOP.
        PUSH ECX                ; SAVE REGISTERS
        PUSH EBX
        PUSH ESI
        MOV EBX,DWORD PTR [EBP+CMOFST]  ; GET ADDRESSES OF OFFSET
        MOV ESI,DWORD PTR [EBX]         ; GET VALUE OF OFFSET.
        MOV EAX,DWORD PTR CMTEST.INT1[ESI]      ; GET COMMON VALUE.
        POP ESI
        POP EBX                 ; RESTORE REGISTERS TO ORIGINAL VALUES.
        POP ECX
        POP EBP
        RET
        PUBLIC INT2VLU
INT2VLU         LABEL NEAR
        PUBLIC _int2vlu_
_int2vlu_       LABEL NEAR
; LOAD EBP WITH ADDRESS OF ARGUMENT LIST.
        PUSH EBP                ; SAVE EBP.
        MOV EBP,ESP             ; COPY STACK POINTER.
        ADD EBP,8               ; ARG LIST IS NOW 8 BYTES FROM TOP.
        MOV EAX,DWORD PTR CMTEST.INT2   ; GET COMMON VALUE.
        POP EBP
        RET
        PUBLIC INT1VLU
INT1VLU         LABEL NEAR
        PUBLIC _int1vlu_
_int1vlu_       LABEL NEAR
; LOAD EBP WITH ADDRESS OF ARGUMENT LIST.
        PUSH EBP                ; SAVE EBP.
        MOV EBP,ESP             ; COPY STACK POINTER.
        ADD EBP,8               ; ARG LIST IS NOW 8 BYTES FROM TOP.
        MOV EAX,DWORD PTR CMTEST.INT1   ; GET COMMON VALUE.
        POP EBP
        RET
CMNBGN  ENDP
codeseg ENDS
        END

[jj2007]

You might try UAsm, it's a Masm clone based on the WatCom assembler. What you are using is pretty rare, there is a chance that the assume handling is WatCom compatible.

[brianvs]

Thankyou for the tip- and I will give this a try, just downloaded it.

With WASM- I hit a few "This feature not yet implemented" when porting code from 386asm.

I got spoiled by the Microway compilers: it is a port of the Green Hills compilers, bought back when 4MBytes of memory was a lot of RAM. It has most of the VAX VMS extensions, plus more. Common blocks aligned on 4K Page boundaries with the Microway compiler, was useful for using the virtual memory manager to map files into memory. WASM did not like my PAGE4K directives, either.

[_japheth]

> If anyone has an explanation, I would appreciate it.

In Masm & clones, it does matter where the EXTRN directive has been placed. In your sample, it's inside the dataseg segment, so the assembler assumes that the "frame" is dataseg for this definition. If you want to avoid this, place the EXTRN directive outside of any SEGMENT/ENDS block.

the PAGE4K attribute ( it's no directive, just a segment attribute ) is something Masm doesn't know, since it's a Pharlap extension ("easy omf"). However, it should be implemented in WASM, and the wasm clones may still have it, too, although support is not activated by default ( see file globals.h in the jwasm/uasm? source code ).

btw, this forum is more or less for "windows" only, hardly the correct place for "DOS extender" questions. The BTTR forum may be a better  place.

[brianvs]

Thankyou for the explanation.

As the WATCOM and MASM32 tools that I started using run under Windows, I placed the question on this forum and got a useful answer.

The BTTR forum does not have anyone other than myself that uses PharLap, and would not have anyone that could have answered this question. I doubt that anyone on either forum will have a question about PharLap or Microway NDP compilers, but if they do- I probably know more about them than anyone else that still using them. The PharLap tools and Microway compilers run under real-mode DOS only, or on a DOS VM. I'm porting my code to WATCOM and MASM32 to do development on a Windows machine with the VortexDX running real-mode DOS and TNT  PharLap as the target.

[hutch--]

If I remember correctly, MASM 6.11 used a PharLap extender when runnng the PWB editor so it could handle larger builds but I confess I did not like it, I preferred the MASM 6.00 PWB and wrote multiple modules to build bigger apps but this is something like early 1990s. I wonder why you would put so much effort into getting stuff of this age up and going again, if you want console mode, Win10 64 can be set up as CMD.EXE instead of Explorer and you can build both 32 and 64 bit code that runs on it.

[brianvs]

Moving the external structure out of dataseg now has MASM and WASM assembling the same code correctly. Watcom uses "DGROUP" for the data segments for the compiler, as opposed to "dataseg" used by Microway. Renaming the data segment to DGROUP that had the memory allocated did not change anything for WASM. Moving the external structure out of  the segment and using assume ds:nothing produced correct code with WASM and MASM. So the answer- with extern structures, assume nothing. Thankyou for solving this for me.

I've had boards made to my specifications for almost 40 years now, write all of my own device drivers. Pays the mortgage and bills. I've used PharLap for over 30 years now, get a library built up. No problem booting up an I5 computer to run real-mode DOS and all of the development tools last updated in 1994.  They produce very fast code, no OS to get in the way. I am not writing code to run under windows, but am looking at using newer development tools that do run under windows. The WATCOM compilers produce code that runs under PharLap. Being able to share memory between the protected mode interrupt handlers, real-mode memory, and protected-mode memory is required for my code to work. So far, things are working. I can easily do the entire project using 386asm and Microway compilers. The test code for common blocks (above) and protected-mode interrupts, written in the 1980s. Proof of concept code for using the Watcom for production work, in addition to the Microway compilers used ever-since. All of the Microway and Pharlap development tools run on the ICOP VortexDX3 which is used as the embedded processor of the custom hardware.

PharLap uses up to 4GBytes of memory, just for fun- I wrote my own raw (DNG) processor for my Leica cameras. That code, I ported to WATCOM and can compile and run under a Windows command line or under PharLap.