RECORD bug

[jimg]

The following produces an error in all descendants of wasm but not ml614 or ml615.

Code: [Select]

.386
.model flat, stdcall
option casemap:none
include windows.inc

.data?
dcbx DCB <>

.code
program:

xBITRECORD RECORD xBinary:1, xParity:1, xOutxCtsFlow:1, xOutxDsrFlow:1, xDtrControl:2,
     xDsrSensitivity:1, xTXContinueOnXoff:1, xOutX:1,xInX:1, xErrorChar:1, xNull:1,
     xRtsControl:2, xAbortOnError:1, xDummy2:17

mov dcbx.fbits, xBITRECORD < TRUE, NULL, TRUE, TRUE, DTR_CONTROL_HANDSHAKE, FALSE, \
                FALSE, FALSE, FALSE, FALSE, FALSE, RTS_CONTROL_HANDSHAKE, FALSE, NULL >

;gives  : Error A2151: Missing operator in expression


    ret
end program


[johnsa]

I'll put this on the 2.36 backlog, too much to do now to change whats in 2.35.

Perhaps someone else can suggest a workaround for this?

[jj2007]

Perhaps someone else can suggest a workaround for this?

SetField was an attempt to do that. I've never used it in any of my sources. One could write a macro that emulates the <fieldA, fieldB, > stuff, but is it really worth it? In practice, you can always use mov eax, 1+2*0+4*1+8*1+16*0 etc

[mineiro]

Not sure if I get the point but I think the error is that error message, so, if ignoring that message inside this context can be a solution, but I do not read assembler source code.

Variable dcbx.fbits is dword and ok, and record structure is (1+1+1+1+2+1+1+1+1+1+1+2+1+17)=32 bits, ok too. Even if record structure have a size in bits smaller that can fit on destination operand, the fault can happen if record structure have bigger bits size than destination operand.

[jimg]

This assembles-

yy4 BITRECORD <TRUE,0,TRUE,TRUE,DTR_CONTROL_HANDSHAKE,0,0,0,0,0,0,RTS_CONTROL_HANDSHAKE,0,0>
mov eax,yy4
mov DCB_New.fbits,eax

Not sure if it's giving the correct answers, but uasm doesn't complain.

It's just the direct move as in the first post that isn't working.


Pretty sure the whole this is just a parsing problem for the "Error A2151: Missing operator in expression" to make sense.

[johnsa]

I had a quick skim through a debug on it, and it looks like the definition of the record itself was ok, and yes the direct mov seems to cause a parsing error.