• Please review our updated Terms and Rules here

OpenWatcom 1.9 C/C++, using enums in inline asm?

Scali

Veteran Member
Joined
Dec 13, 2014
Messages
2,024
Location
The Netherlands
I have the following code:
Code:
typedef enum
{
	MACHINE_PCXT,
	MACHINE_PCAT,
	MACHINE_PS2
} MachineType;

...
MachineType machineType;

_asm {
	mov [machineType], MACHINE_PCXT
}

Now, for some reason, OpenWatcom complains about an invalid operand for the MACHINE_PCXT value (I ported this code over from Turbo C++ 3.1, where it worked fine).
I guess its problem is that it doesn't know the size of the operand.
But I tried using 'word ptr' or 'byte ptr' to indicate size, and I couldn't make it work.
The only thing that worked was to replace the MACHINE_PCXT with an immediate '0'.

Does anyone have any idea if you can get enums to work inside asm blocks at all, and if so, how?
 
Hum, sadly that does not seem to do the trick, I still get this:
8259A.C(71): Error! E1156: Assembler error: 'Invalid instruction operands'
8259A.C(112): Error! E1011: Symbol 'MACHINE_PCXT' has not been declared

I am not sure why it even says the symbol is not declared (and why it says that at the end of the asm block, while it says 'invalid instruction operands' at the instruction itself).
The declaration is clearly there, otherwise I could not make the MachineType variable in the C-code in the first place :)
 
I don't use Watcom, but I'd still try things such as MachineType.MACHINE_PCXT as an operand. There's got to be some sort of magic involved.

Yea, what's the magic word? :)
I tried MachineType.MACHINE_PCXT and MachineType::MACHINE_PCXT, but it didn't like either.
Not sure what else to try.
 
Well, the assembler seems rather limited.
I've looked through the manual, and it specifically states that inline asm does not support access to structs.
It doesn't mention enums, but it could well be that enums are not supported either, since they are a somewhat related concept.

So I might have just run into a limitation of the inline assembler. It does support #define statements though, so I could work around it.

I'm more worried about another limitation though... some of the math code I've compiled gives very different results from Turbo C++ and Visual C++. I'm afraid the floating point code may be unstable/buggy.
 
Issues like this are why I abandoned using the inline assembler in borland languages, I can't imagine Watcom being all that different in that regard. Took a long time for me to buckle down and do it as I HATE MASM and too many other alternatives try to be like MASM... Which is why I ended up settling on NASM. I'm just more comfortable with it.

Inline assemblers are fun for quick one-offs, but the moment you try to do anything "real" with them their shortcomings become painfully obvious.
 
Microsoft C++ has a pretty good inline assembler; I've used it on and off, but if I'm doing serious work, I'll write a separate assembler module and link it in.

MASM/ML 6.10 and later are pretty darned good in the world of x86 assemblers--mostly for the assembly-time features. (a pretty rich macro facility).
 
I suppose I'll have to check out Microsoft C++ for DOS sometime. I still have my MSDN copy of Visual C++ 1.52, which includes the latest DOS toolchain as well.
I kept putting it off because Visual C++ is a 16-bit Windows application, so it won't run in a modern Windows. OpenWatcom is 32-bit Windows stuff. Also, OpenWatcom delivers some insanely good C/C++ performance on 8088 machines (way faster than Turbo C++ at least). I doubt that Visual C++ can touch that part.
But yes, if all else fails, perhaps it's better to do more in pure asm, and just link the code. It's just that this was the kind of code that was just a few lines of asm in a C program. Simple enough in Turbo C++, but apparently not in OpenWatcom.
 
Back
Top