News:

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

Main Menu

2.46.8 available

Started by johnsa, January 27, 2018, 12:58:02 AM

Previous topic - Next topic

johnsa

Hi,

2.46.8 update is available, Windows packages today, OSX and Linux ones tonight.

Changes are:

CLMUL and SHA instruction set support added including pseudo-op forms of CLMUL.
Fixed bug in DEREF macros for OO and COM preventing correct expansion of ->Release().
Added support for typedef chain on return types so not only primitive types work.

Cheers
John

ragdog

Hello

I use a older version of HJWasm v2.15r2, a new can i not find.
If i compile my project have i this error


jwasm.exe /c /coff /Cp "DlgMain.Asm"
HJWasm v2.15r2, Sep 25 2016, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

DlgMain.Asm(30) : Error A2168: General Failure

Error(s) occured.



By Uasm this


rc /v "DlgMain.Rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17298

Copyright (C) Microsoft Corporation.  All rights reserved.


Creating DlgMain.res

Using codepage 1252 as default

DlgMain.Rc.
Writing DIALOG:1000, lang:0x409, size 92.
Writing 24:1, lang:0x409, size 612

uasm32.exe /c /coff /Cp "DlgMain.Asm"
UASM v2.46, Jan 26 2018, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

DlgMain.Asm: 31 lines, 2 passes, 555 ms, 0 warnings, 0 errors

link /SUBSYSTEM:WINDOWS /RELEASE /VERSION:5.0 /MACHINE:X86 /OUT:"DlgMain.exe" "DlgMain.obj"  "DlgMain.res"
Microsoft (R) Incremental Linker Version 12.00.31101.0
Copyright (C) Microsoft Corporation.  All rights reserved.

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

Error(s) occured.



Here is my project can you tell me what is wrong?

Regards,
ragdog

jj2007

Just throw away DlgMain.inc, it doesn't contain anything useful. This works.include \masm32\include\masm32rt.inc

IDD_DIALOG equ 1000

.data?
hInstance dd ?

.code
start:
invoke GetModuleHandle,NULL
mov hInstance,eax
invoke InitCommonControls
invoke DialogBoxParam,hInstance,IDD_DIALOG,NULL,addr DlgProc,NULL
invoke ExitProcess,0
;########################################################################

DlgProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

.if uMsg==WM_INITDIALOG

.elseif uMsg==WM_COMMAND

.elseif uMsg==WM_CLOSE
invoke EndDialog,hWnd,0
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
DlgProc endp
end start

ragdog

I have test your code but is same  ::)
DlgMain.Asm(31) : Error A2168: General Failure

jj2007

Quote from: ragdog on January 31, 2018, 08:10:54 AM
I have test your code but is same  ::)
DlgMain.Asm(31) : Error A2168: General Failure

Attached code builds fine with ML 6.14, JWasm, latest UAsm64.

@John: Latest UAsm64 fails to recognise default argument size. Version 8 January was still OK. Example:

OK:
SetMouse proc idmx:DWORD
  invoke SetCursor, rv(LoadCursor, 0, idmx) ; hourglass, ...


Fail:
SetMouse proc idmx
  invoke SetCursor, rv(LoadCursor, 0, idmx) ; hourglass, ...

johnsa

Hey,

Ok the issue with that default argument size is how the return types are now handled. With .8 we've allowed any type to be specified as the return type, not just one of the built-in types (byte/word/dword) etc.
However, what this means is that the return type can be an identifier(ID) so with the default argument  size syntax it becomes grammatically ambiguous as to what that is suppose to be, an argument or a return type.

The only way I can see to really solve this is to change the return type syntax slightly. It needs some form of marker to identify the intention grammatically...

We could do something like this:

MyProc PROTO (HRESULT) :DWORD, :DWORD

MyProc PROC (HRESULT) aVar, bVar

Use brackets to enclose the return type, that way there is no confusion between the types and their meaning/intention.

If that works for all I will make this change.

jj2007


johnsa

Was that a yes or a no ? :)

[EDIT] .. Ok I think I've maybe confused people a bit here..

So.. writing/declaring procs and protos is 100% normal as you would in Masm etc..
IF however you specifically WANT to add a return type to a PROC (which offers some benefits) then you can.

At present this is simply a type specified before the argument list (refer to the manual).
The bug now is that we've added support for identifiers to that return type, not just the built-in standard types.. which now makes that syntax ambiguous if you're using un-typed parameters.

So my suggestion was to change the return-type syntax to occur inside ( ) so that it's not ambiguous with the parameter list.

The big PRO of using the return type is that enables other macro expansions using @LastReturnType which can correctly generate based on the proc that was called..
For example:

.if( MyProc() == 1.0 ) 
;assuming MyProc returns a REAL4

or

.if( MyProc() == al )
; assuming MyProc returns a BYTE

and this works with normal uinvoke syntax too if you're not keen on the c style calls.
This is much smarter than everything just assuming the return is always eax/rax.

aw27

Quote
The big PRO of using the return type is that enables other macro expansions

I don't see a benefit and your example is not much convincing, I see it as a potential source of bugs. If nobody uses it you will not be aware of the bugs, of course - this is probably what happens with other great features. I have my doubts much people uses them but have not done any pool.

johnsa

Quote from: aw27 on February 01, 2018, 10:20:34 AM
Quote
The big PRO of using the return type is that enables other macro expansions

I don't see a benefit and your example is not much convincing, I see it as a potential source of bugs. If nobody uses it you will not be aware of the bugs, of course - this is probably what happens with other great features. I have my doubts much people uses them but have not done any pool.

Without a return type how would you expand:



.if( DotProduct(vec) == 0.0 )

; or

vmovaps xmm0, uinvoke(myfuncX, xmm2)



You'd have to wrap things in macros yourself and deal with special cases all over the place.. much easier if you have the ability to specify the return type which is then type-checked.
As long as these additions are not mandatory and no way affect normal asm code, it's a valuable addition.


aw27

Now, I understand the idea.
However, the example:
vmovaps xmm0, uinvoke(myfuncX, xmm2) is not a good one because reals can only return in xmm0 and we will have:
vmovaps xmm0, xmm0

:t


johnsa

Quote from: aw27 on February 01, 2018, 11:29:52 PM
Now, I understand the idea.
However, the example:
vmovaps xmm0, uinvoke(myfuncX, xmm2) is not a good one because reals can only return in xmm0 and we will have:
vmovaps xmm0, xmm0

:t

lol.. good spotting.. make that vmovaps xmm1, ... then ;)
Getting myself all excited to start working on the plt/got stuff now.. would like to see the back of it and know it's done and working.

johnsa

PS, with regards to Ragdog's original question.. the source he posted works perfectly for me pretty much as-is (apart from changing a few paths), I've attached my archive include the then built exe.
I used uasm32 and uasm64.. both produced the same result.


jj2007

Tested UAsm with my major sources, everything OK now :t

ragdog

Hello

My code works fine now  :t