News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

UASM 2.43 Release

Started by johnsa, October 27, 2017, 05:47:23 AM

Previous topic - Next topic

johnsa

Hi,

All packages are now available on the site and repositories on Git are updated.

Thanks to all those who have helped test this release! :)

Cheers
John

jimg

What was the solution for argtype conflicts in 32 bit again?


Make finished. 225 error(s) occured.

johnsa

With regard to MasmBasic ? I believe JJ was going to change the name internally.

jimg

Sorry, I didn't realize it was a variable from my code.   I'll change all the references.   Carry on :)

jj2007

Quote from: johnsa on October 27, 2017, 09:51:23 AM
With regard to MasmBasic ? I believe JJ was going to change the name internally.

Yes indeed, that is what I did, and it works fine.

johnsa

Just FYI, I suspect (and hope) that is the last operator I can see any uses for adding at present. In future I will publish the list of proposed names for anything we add before-hand so we can verify that it won't cause namespace conflicts. For 2.44 the only really big change I'm working on adding is macho output support, after that we'd like to focus on dwarf symbolic debugging and then I think it's pretty much complete.. until the next big idea :)

aw27

Saving xmm register unaligned.


option frame:AUTO

includelib \masm32\lib64\kernel32.lib
ExitProcess proto :dword

.code

Example1 PROC uses rsi xmm15 ; xmm15 is saved unaligned, causes exception
   ret 
Example1 ENDP 


main PROC
INVOKE Example1
INVOKE ExitProcess,0
ret
main ENDP

end

johnsa

2.43.2 packages (27th Oct) updated on the site. Should sort out the uses alignment issue.

Biterider

Hi
I use the command line option -D to define a symbol. It workd up to 2.42, but in th e last release it seems to be broken. Going back to 2.42.5 it works again.
Biterider




johnsa

This one is really wierd, this code hasn't been touched. From what I'm seeing unless I'm losing my mind.. it looks like the C compiler isn't generating the right code!!

the problem is here: (assemble.c line 587)



if( is_valid_identifier( name ) == ERROR ) {
00007FF75E903002  mov         rcx,qword ptr [rbp] 
00007FF75E903006  call        is_valid_identifier (07FF75E902D90h) 
00007FF75E90300B  test        eax,eax 
00007FF75E90300D  jne         add_cmdline_tmacros+14Fh (07FF75E90302Fh) 
            DebugMsg(("add_cmdline_tmacros: name >%s< invalid\n", name ));
00007FF75E90300F  mov         rdx,qword ptr [rbp] 
00007FF75E903013  lea         rcx,[MOVE_SIMD_QWORD+700h (07FF75EA87898h)] 
00007FF75E90301A  call        DoDebugMsg (07FF75E92D6B0h) 
            EmitErr( SYNTAX_ERROR_EX, name );
00007FF75E90301F  mov         rdx,qword ptr [rbp] 
00007FF75E903023  mov         ecx,0D2h 
00007FF75E903028  call        EmitErr (07FF75E92D8C0h) 


Now is_valid_identifier( name ) return NOT_ERROR (0)
ERROR = -1

As far as I can tell ... it's erroneously emitting a JNE instead of a JE/JZ .... wtf

EDIT:
Ok, the problem is that I added an additional include which happens to also define the constants ERROR and NOT_ERROR as different values!, so the test for zero is in fact right based on that :)
I was getting worried..

johnsa

Ok, this will be fixed shortly. I've extracted all the required definitions into it's own include and removed the need for Windows.h to be added to the project, avoids the definition conflicts.