Discussion:
OpenWatcom newbie: Standalone assembler problems
(too old to reply)
Binarus
2013-02-25 13:30:57 UTC
Permalink
Dear experts,

please forgive that I am posting my question to this group - the openwatcom.users.assembler group seems to be dead.

I am trying to port a big project from Borland C++ 5.02 to OpenWatcom. The main reason for this is that the OpenWatcom toolchain is more advanced and that it is well integrated into Code::Blocks (I don't want to use Borland's outdated IDE any more).

The project contains some assembler source code files (pure assembler, not inline assembler). I have some difficulties with porting these to WASM:

1) Declaring PROCs with parameters:

According to the docs, WASM is almost compatible to MASM, so I am using the documentation for MASM 6.1 as reference. In MASM, if I have a function _StartPerfCounter with two parameters which are both pointers to a DWORD, I can do the following:

.MODEL HUGE,C
_StartPerfCounter PROC FAR, PDW_DestLow: FAR DWORD PTR, PDW_DestHigh: FAR DWORD PTR
...

That code produces errors with WASM. It doesn't seem to be possible to declare FAR pointer parameters or pointers to a certain type at all. The following works:

.MODEL HUGE,C
_StartPerfCounter PROC FAR, PDW_DestLow: PTR, PDW_DestHigh: PTR
...

But I am not sure if this does what I mean. How should I declare a procedure with FAR pointer parameters in WASM?

2) Predefined symbols:

The existing project uses @fardata and friends in many places. According to the docs, MASM understands that predefined symbol. But WASM complains about undefined symbols, and I haven't found something similar what I could use.

So what's the correct method to get the current fardata segment in WASM?

The existing project (mainly) uses the predefined symbols for something like that:

MOV AX, @fardata
MOV DS, AX
...

Thank you very much for any help,

Binarus
Uwe Schmelich
2013-02-25 19:12:19 UTC
Permalink
Post by Binarus
....
According to the docs, WASM is almost compatible to MASM, so I am using
the documentation for MASM 6.1 as reference. In MASM, if I have a function
....
If you need real MASM compatibility it may be better to use JWasm instead of
Wasm.

http://www.japheth.de/JWasm.html
Binarus
2013-02-27 11:35:48 UTC
Permalink
Post by Uwe Schmelich
Post by Binarus
....
According to the docs, WASM is almost compatible to MASM, so I am using
the documentation for MASM 6.1 as reference. In MASM, if I have a function
....
If you need real MASM compatibility it may be better to use JWasm instead of
Wasm.
http://www.japheth.de/JWasm.html
Thank you very much. I will also play around with the compatibility settings of wasm.
Binarus
2013-02-28 16:48:42 UTC
Permalink
Post by Binarus
Post by Uwe Schmelich
Post by Binarus
....
According to the docs, WASM is almost compatible to MASM, so I am using
the documentation for MASM 6.1 as reference. In MASM, if I have a function
....
If you need real MASM compatibility it may be better to use JWasm instead of
Wasm.
http://www.japheth.de/JWasm.html
Thank you very much. I will also play around with the compatibility settings of wasm.
Indeed, JWasm can handle the PROC arguments as stated in the MASM 6.1 documentation. Regarding the predefined symbol @fardata, I have found a replacement (just using the SEG operator).

Thanks,

Binarus
Wilton Helm
2013-03-14 23:12:51 UTC
Permalink
I moved all of my development from tasm to wasm a number of years ago. Tasm
has some interesting features that, unfortunately are non-standard. The
process can get complex. The Tasm stuff is nice, but nobody else supports
it, so the end result of such a conversion is more compatible code. For
better or worse, Masm is the 10 ton gorilla that most x86 assembly mimics.

Another change I had to deal with was I wanted to take advantage of OWs
register based parameter passing, because it is more efficient that stack
based passing. That required rewriting at least the beginning of just about
every assembly language function that was called by C. But the result was
worth it.

Wilton

Loading...