UASM 2.41 Release + WinInc 2.09

[johnsa]

New packages for UASM 2.41 are up as well as an updated version of WinInc with a number of fixes.

UASM 2.41 updates a number of additional compiler warnings, but most importantly a totally re-worked implementation of RECORD directive and operator.

Code Select Expand



.data

COLOR RECORD blink:1, back:3, intense:1, fore:3
safir COLOR <1, 2, 0, 4>

COBALT STRUCT
    pntr DWORD ?
    rc   COLOR <>
COBALT ENDS

cobalt COBALT <>

COLOR64 RECORD blink:8, back:8, intense:8, fore:8,blink1:8, back1:8, intense1:8, fore1:8
safir64 COLOR64 <224, 225, 226, 14, 224, 225, 226, 14>

.code

mov cl, COLOR<1, 7, 0, 1>
mov cobalt.rc, COLOR<1, 7, 0, 1>
mov rax,safir64





In addition to RECORDS of 32bits, 64bit RECORDS can be declared in .data and manually referenced OR used inline in code if the destination is a 64bit GPR:

Code Select Expand



mov   rax,COLOR <224, 225, 226, 14, 224, 225, 226, 14>                        ; E0E1E20EE0E1E20E
mov   rcx,COLOR <224, 225, 226, 14, 224, 225, 226, 14>                        ; E0E1E20EE0E1E20E



Git source updated in 2.41 branch and master.
Cheers
John

[habran]

You can use 64 bit value direct in 64 bit registers:

Code Select Expand

mov   rax,COLOR <224, 225, 226, 14, 224, 225, 226, 14>                        ; E0E1E20EE0E1E20E
but that will throw an error:

Code Select Expand

mov   cobalt.rc,COLOR <224, 225, 226, 14, 224, 225, 226, 14>                  ; E0E1E20EE0E1E20E
and this as well:

Code Select Expand

mov   ecx,COLOR <224, 225, 226, 14, 224, 225, 226, 14>                        ; E0E1E20EE0E1E20E
this works fine:

Code Select Expand

mov   ecx,COLOR <224, 225, 226, 14>                        ; E0E1E20E

and this as well:

Code Select Expand

mov   cobalt.rc,COLOR <224, 225, 226, 14>                  ; E0E1E20E

[habran]

UASM takes care if incorrect values used in RECORD 8)
this is from jimg source from this forum:

Code Select Expand


    prtf "bear in mind that ML doesn't care if you enter stuff that doesn't match the specs for the record"
    ;but UASM cares, if you uncomment nex 2 lines it will throw errors
    ;mov dcbw.fbits,wBITRECORD<9,9,9,9,9,9,9,9,9,9,9,9,9,9>
    ;prtf "entering 9 for every field gives jibberish, should have cause assembly error - fbits=%x",dcbw.fbits


[habran]

DCB struct changed in winbase.h to this to be compatible with masm:

Code Select Expand


BITRECORD RECORD fBinary:1,fParity:1,fOutxCtsFlow:1,fOutxDsrFlow:1,fDtrControl:2,fDsrSensitivity:1,fTXContinueOnXoff:1,fOutX:1,fInX:1,fErrorChar:1,fNull:1,fRtsControl:2,fAbortOnError:1,fDummy2:17

DCB STRUCT
  DCBlength     DWORD      ?
  BaudRate      DWORD       ?
  fbits         BITRECORD      <>
  wReserved     WORD       ?
  XonLim        WORD          ?
  XoffLim       WORD         ?
  ByteSize      BYTE        ?
  Parity        BYTE          ?
  StopBits      BYTE        ?
  XonChar       BYTE         ?
  XoffChar      BYTE        ?
  ErrorChar     BYTE       ?
  EofChar       BYTE         ?
  EvtChar       BYTE         ?
  wReserved1    WORD       ?
DCB ENDS

LPDCB typedef ptr DCB


[habran]

I believe that all issues with the SWITCH - ENDSWITCH block have been solved :t

[aw27]

DCB struct changed in winbase.h to this to be compatible with masm:

Code Select Expand


BITRECORD RECORD fBinary:1,fParity:1,fOutxCtsFlow:1,fOutxDsrFlow:1,fDtrControl:2,fDsrSensitivity:1,fTXContinueOnXoff:1,fOutX:1,fInX:1,fErrorChar:1,fNull:1,fRtsControl:2,fAbortOnError:1,fDummy2:17

DCB STRUCT
  DCBlength     DWORD      ?
  BaudRate      DWORD       ?
  fbits         BITRECORD      <>
  wReserved     WORD       ?
  XonLim        WORD          ?
  XoffLim       WORD         ?
  ByteSize      BYTE        ?
  Parity        BYTE          ?
  StopBits      BYTE        ?
  XonChar       BYTE         ?
  XoffChar      BYTE        ?
  ErrorChar     BYTE       ?
  EofChar       BYTE         ?
  EvtChar       BYTE         ?
  wReserved1    WORD       ?
DCB ENDS

LPDCB typedef ptr DCB


I don't understand this part. The declaration of BITRECORD RECORD  is wrong in Windows.inc because records in MASM  are in reverse order of records in C.

There is even an old discussion about this  here.

[habran]

This was there before:

Code Select Expand


DCB_R0 RECORD fDummy2:17,fAbortOnError:1,fRtsControl:2,fNull:1,fErrorChar:1,\
fInX:1,fOutX:1,fTXContinueOnXoff:1,fDsrSensitivity:1,fDtrControl:2,\
    fOutxDsrFlow:1,fOutxCtsFlow:1,fParity:1,fBinary:1
   
DCB struct
DCBlength DWORD ?
BaudRate DWORD ?
r0 DCB_R0 <>
wReserved WORD ?
XonLim WORD ?
XoffLim WORD ?
ByteSize BYTE ?
Parity BYTE ?
StopBits BYTE ?
XonChar SBYTE ?
XoffChar SBYTE ?
ErrorChar SBYTE ?
EofChar SBYTE ?
EvtChar SBYTE ?
wReserved1 WORD ?
DCB ends

LPDCB typedef ptr DCB


Jimg has given this info in his example:

Code Select Expand


; stock BITRECORD from windows.inc but with w prepended and with binary set so we can find it
wBITRECORD RECORD wBinary:1=1,wParity:1,wOutxCtsFlow:1,wOutxDsrFlow:1,wDtrControl:2,wDsrSensitivity:1,wTXContinueOnXoff:1,wOutX:1,wInX:1,wErrorChar:1,wNull:1,wRtsControl:2,wAbortOnError:1,wDummy2:17
; reversed definition
zBITRECORD RECORD zDummy2:17,zAbortOnError:1,zRtsControl:2,zNull:1,zErrorChar:1,zInX:1,zOutX:1,zTXContinueOnXoff:1,zDsrSensitivity:1,zDtrControl:2,zOutxDsrFlow:1,zOutxCtsFlow:1,zParity:1,zBinary:1=1

so, tell me which one is really reversed, or better yet:
we should finally all agree about it
then we can make as you wish
To me doesn't matter it can not run on my machine and I can not check which one is reverse and which one is not.
   

[aw27]

Habran,

I am not sure what jimg said in every occasion. What I can quote from Jimg is this:
"I disagree.  The final correct result is to define the record properly, not like it is in windows.inc"

So, the correct definition (subject, of course, to confirmation from Jimg) should be :
BITRECORD RECORD fDummy2:17,fAbortOnError:1,fRtsControl:2, fNull:1,fErrorChar:1,fInX:1,fOutX:1, fTXContinueOnXoff:1,fDsrSensitivity:1,fDtrControl:2,fOutxDsrFlow:1,fOutxCtsFlow:1,fParity:1,fBinary:1

[aw27]

In addition to RECORDS of 32bits, 64bit RECORDS can be declared in .data and manually

This does not work in 32-bit and does not work as advertised in 64-bit:

Code Select Expand


includelib \masm32\lib64\msvcrt.lib

OPTION LITERALS:ON

printf proto :ptr, :vararg

_FP32 RECORD sign:1, exponent:8, mantissa:23
FP32_t UNION
parts _FP32 <>
number REAL4 ?
FP32_t ENDS

.data
someFloat FP32_t <>

.code

main proc
LOCAL _real8 : REAL8
; This works ...
mov rcx, _FP32<0, 80h, 4ccccdh> ; but why need a 64-bit register for a 32-bit record?
mov someFloat.parts, ecx
; This does not work:
; mov someFloat.parts, _FP32<0, 80h, 4ccccdh>

fld someFloat.number
fstp _real8
INVOKE printf, "Value %f", _real8 ; expected to print 3.2
ret
main endp

end main


[habran]

Why are you using \masm32\lib64\msvcrt.lib
I never succeeded to build anything with that
here is your code:

Code Select Expand


--- awrec.asm ------------------------------------------------------------------
     1: includelib msvcrt.lib
     2:
     3: OPTION LITERALS:ON
     4:
     5: printf proto :ptr, :vararg
     6:
     7: _FP32 RECORD sign:1, exponent:8, mantissa:23
     8: FP32_t UNION
     9: parts _FP32 <>
    10: number REAL4 ?
    11: FP32_t ENDS
    12:
    13: .data
    14: someFloat FP32_t <>
    15:
    16: .code
    17:
    18: main proc
00007FF6E6E71010 55                   push        rbp 
00007FF6E6E71011 48 8B EC             mov         rbp,rsp 
00007FF6E6E71014 48 83 EC 10          sub         rsp,10h 
    19: LOCAL _real8 : REAL8
    20: ; This works ...
    21: mov ecx, _FP32<0, 80h, 4ccccdh> ; but why need a 64-bit register for a 32-bit record?
    22: mov someFloat.parts, ecx
00007FF6E6E71018 89 0D E2 3F 00 00    mov         dword ptr [someFloat (07FF6E6E75000h)],ecx 
    23: ; This does not work:
    24: mov someFloat.parts, _FP32<0, 80h, 4ccccdh>
    25:
    26: fld someFloat.number
00007FF6E6E7101E D9 05 DC 3F 00 00    fld         dword ptr [someFloat (07FF6E6E75000h)] 
    27: fstp _real8
00007FF6E6E71024 DD 5D F8             fstp        qword ptr [_real8] 
    28: INVOKE printf, "Value %f", _real8 ; expected to print 3.2
00007FF6E6E71027 48 83 EC 20          sub         rsp,20h 
00007FF6E6E7102B 48 8B 55 F8          mov         rdx,qword ptr [_real8] 
00007FF6E6E7102F 48 8D 0D D7 3F 00 00 lea         rcx,[__ls2393 (07FF6E6E7500Dh)] 
00007FF6E6E71036 E8 1D 10 00 00       call        printf (07FF6E6E72058h) 
00007FF6E6E7103B 48 83 C4 20          add         rsp,20h 
    29: ret
00007FF6E6E7103F 48 83 C4 10          add         rsp,10h 
00007FF6E6E71043 5D                   pop         rbp 
00007FF6E6E71044 C3                   ret 
--- No source file -------------------------------------------------------------

Now I can see that mov ecx, _FP32<0, 80h, 4ccccdh> ; but why need a 64-bit register for a 32-bit record?
is skipped as well as :
mov someFloat.parts, _FP32<0, 80h, 4ccccdh>
It is interesting find
I'll check on it

[aw27]

For 64 bit records:

Code Select Expand



includelib \masm32\lib64\msvcrt.lib

OPTION LITERALS:ON

printf proto :ptr, :vararg

_FP64 RECORD sign:1, exponent:11, mantissa:52
FP64_t UNION
parts _FP64 <>
number REAL8 ?
FP64_t ENDS

.data
someDouble FP64_t <>

.code

main proc
; This does not assemble the record correctly
mov rax, _FP64<0, 400h, 999999999999Ah>
mov someDouble.parts, rax
; and this does not work at all:
;mov someDouble.parts, _FP64<0, 400h, 999999999999Ah>

INVOKE printf, "Value %f", someDouble.number ; expected to print 3.2
ret
main endp

end main


[aw27]

Why are you using \masm32\lib64\msvcrt.lib

msvcrt has many enemies here but everybody uses it, even disguised as crt_somefunction. 

[jj2007]

msvcrt has many enemies here but everybody uses it, even disguised as crt_somefunction. 

Well, almost everybody ;)

[habran]

I have found what was wrong, will be fixed soon and I'll post the exe here as soon as I fix it because I don't believe that John will be available tonight (OZ time)
That was very good find aw27 :t
as you know we see what we want to see but it doesn't have to be a common  reality

[aw27]

msvcrt has many enemies here but everybody uses it, even disguised as crt_somefunction. 

Well, almost everybody ;)

Show me something built by your Basic that does not call msvcrt.dll.  :icon_rolleyes: