### Author Topic: 2.46.8 available  (Read 1705 times)

#### johnsa

• Member
• Posts: 686
##### 2.46.8 available
« on: January 27, 2018, 12:58:02 AM »
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

• Member
• Posts: 572
##### Re: 2.46.8 available
« Reply #1 on: January 31, 2018, 05:16:30 AM »
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

Code: [Select]
`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 FailureError(s) occured.`

By Uasm this
Code: [Select]
`rc /v "DlgMain.Rc"Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17298Copyright (C) Microsoft Corporation.  All rights reserved.Creating DlgMain.resUsing codepage 1252 as defaultDlgMain.Rc.Writing DIALOG:1000, lang:0x409, size 92.Writing 24:1, lang:0x409, size 612uasm32.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 errorslink /SUBSYSTEM:WINDOWS /RELEASE /VERSION:5.0 /MACHINE:X86 /OUT:"DlgMain.exe" "DlgMain.obj"  "DlgMain.res"Microsoft (R) Incremental Linker Version 12.00.31101.0Copyright (C) Microsoft Corporation.  All rights reserved.LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corruptError(s) occured.`
Here is my project can you tell me what is wrong?

Regards,
ragdog

#### jj2007

• Member
• Posts: 8617
• Assembler is fun ;-)
##### Re: 2.46.8 available
« Reply #2 on: January 31, 2018, 06:14:44 AM »
Just throw away DlgMain.inc, it doesn't contain anything useful. This works.
Code: [Select]
`include \masm32\include\masm32rt.incIDD_DIALOG equ 1000.data?hInstance dd ?.codestart: 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 retDlgProc endpend start`

#### ragdog

• Member
• Posts: 572
##### Re: 2.46.8 available
« Reply #3 on: January 31, 2018, 08:10:54 AM »
I have test your code but is same
DlgMain.Asm(31) : Error A2168: General Failure

#### jj2007

• Member
• Posts: 8617
• Assembler is fun ;-)
##### Re: 2.46.8 available
« Reply #4 on: January 31, 2018, 10:42:33 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:
Code: [Select]
`SetMouse proc idmx:DWORD  invoke SetCursor, rv(LoadCursor, 0, idmx) ; hourglass, ...`
Fail:
Code: [Select]
`SetMouse proc idmx  invoke SetCursor, rv(LoadCursor, 0, idmx) ; hourglass, ...`

#### johnsa

• Member
• Posts: 686
##### Re: 2.46.8 available
« Reply #5 on: January 31, 2018, 08:35:55 PM »
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

• Member
• Posts: 8617
• Assembler is fun ;-)
##### Re: 2.46.8 available
« Reply #6 on: January 31, 2018, 08:53:31 PM »

#### johnsa

• Member
• Posts: 686
##### Re: 2.46.8 available
« Reply #7 on: January 31, 2018, 09:14:00 PM »
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.

#### AW

• Member
• Posts: 1394
• Let's Make ASM Great Again!
##### Re: 2.46.8 available
« Reply #8 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.

#### johnsa

• Member
• Posts: 686
##### Re: 2.46.8 available
« Reply #9 on: February 01, 2018, 10:50:59 PM »
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:

Code: [Select]
`.if( DotProduct(vec) == 0.0 ); orvmovaps 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.

#### AW

• Member
• Posts: 1394
• Let's Make ASM Great Again!
##### Re: 2.46.8 available
« Reply #10 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

#### johnsa

• Member
• Posts: 686
##### Re: 2.46.8 available
« Reply #11 on: February 02, 2018, 12:51:13 AM »
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

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

• Member
• Posts: 686
##### Re: 2.46.8 available
« Reply #12 on: February 02, 2018, 01:08:22 AM »
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

• Member
• Posts: 8617
• Assembler is fun ;-)
##### Re: 2.46.8 available
« Reply #13 on: February 02, 2018, 02:18:15 AM »
Tested UAsm with my major sources, everything OK now

#### ragdog

• Member
• Posts: 572
##### Re: 2.46.8 available
« Reply #14 on: February 03, 2018, 09:27:47 PM »
Hello

My code works fine now