Hello,
there's a new JWasm release candidate available at http://www.japheth.de/JWasm.html. It was intended to be a "bugfix" release only, but I was a bit curious and implemented support for SSE4.1 and SSE4.2 instruction sets. AFAIK that makes this release virtually compatible with Masm v9. The exception is the SSE4A instruction set, which isn't implemented yet ( mainly because of the strange INSERTQ instruction which needs 4 arguments, a hard job for the JWasm parser ).
:U
PS. is jwasm written in masm language?
C.
This macro:
; -----------------------
;; INLINE [nX] OPCODE,...
; -----------------------
inline equ <INLINE>
Inline equ <INLINE>
INLINE MACRO v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,v13,v14,v15
LOCAL pos
FOR arg,<v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,v13,v14,v15>
IFNB <arg>
pos=@InStr(1,arg,<!:>)
argy CATSTR <arg>
IF pos
argy CATSTR <@SubStr(<arg>,1,pos-1),@SubStr(<arg>,pos+1)>
ENDIF
IFIDN @SubStr(<arg>,2,1),<X>
REPEAT @SubStr(<arg>,1,1)
@SubStr(%argy,4)
ENDM
ELSE
argy
ENDIF
ENDIF
ENDM
ENDM
won't work in JWASM.
Usage:
inline 2X inc eax,mov nEvents:eax
Looks like the using of ":" messing up something.
Quote from: Ficko on December 10, 2009, 07:20:25 PM
Looks like the using of ":" messing up something.
The ":" is innocent. Here's a simplified test case:
.386
.model flat
argy CATSTR <@SubStr(<mov nEvents:eax>,1,11) , @SubStr(<mov nEvents:eax>,13)>
.data
nEvents dd 0
.code
argy
End
the problem occurs if a text macro contains more than 1 macro function, and the evaluation of the macro functions is "delayed" ( = they are enclosed in <> ).
It is fixed.
Thanx,
that was faaast! :bg
I just compiled a library with 408 modules.
No errors. :U
Quote from: Ficko on December 11, 2009, 06:07:08 PM
I just compiled a library with 408 modules.
No errors. :U
Good! So v2.01 is final now.
Quote from: japheth on December 12, 2009, 09:07:40 AM
Good! So v2.01 is final now.
Just slow down a little bit. :bg
I didn't say
everything is ok.
Just sad that JWASM didn't report error. :P
Seriously there is something not working right in my library.
A dialog won't open but no exception is generated.
I did found something that is strange may causing the problem.
Portion of my code:
.686p
.model flat
; ------------------------------------------------------------------
LF_FACESIZE equ 32
; ------------------------------------------------------------------
LOGFONT STRUCT
lfHeight DWORD ?
lfWidth DWORD ?
lfEscapement DWORD ?
lfOrientation DWORD ?
lfWeight DWORD ?
lfItalic BYTE ?
lfUnderline BYTE ?
lfStrikeOut BYTE ?
lfCharSet BYTE ?
lfOutPrecision BYTE ?
lfClipPrecision BYTE ?
lfQuality BYTE ?
lfPitchAndFamily BYTE ?
lfFaceName BYTE LF_FACESIZE dup(?)
LOGFONT ENDS
WNDCLASSEX STRUCT
cbSize DWORD ?
style DWORD ?
lpfnWndProc DWORD ?
cbClsExtra DWORD ?
cbWndExtra DWORD ?
hInstance DWORD ?
hIcon DWORD ?
hCursor DWORD ?
hbrBackground DWORD ?
lpszMenuName DWORD ?
lpszClassName DWORD ?
hIconSm DWORD ?
WNDCLASSEX ENDS
TEXTMETRICA STRUCT
tmHeight DWORD ?
tmAscent DWORD ?
tmDescent DWORD ?
tmInternalLeading DWORD ?
tmExternalLeading DWORD ?
tmAveCharWidth DWORD ?
tmMaxCharWidth DWORD ?
tmWeight DWORD ?
tmOverhang DWORD ?
tmDigitizedAspectX DWORD ?
tmDigitizedAspectY DWORD ?
tmFirstChar BYTE ?
tmLastChar BYTE ?
tmDefaultChar BYTE ?
tmBreakChar BYTE ?
tmItalic BYTE ?
tmUnderlined BYTE ?
tmStruckOut BYTE ?
tmPitchAndFamily BYTE ?
tmCharSet BYTE ?
TEXTMETRICA ENDS
DLGTEMPLATE STRUCT DWORD
style DWORD ?
dwExtendedStyle DWORD ?
cdit WORD ?
x WORD ?
y WORD ?
lx WORD ?
ly WORD ?
DLGTEMPLATE ENDS
.const
MSSansSerif db "MS Sans Serif",0
DlgClassN db "MYDLGDlgClass",0
.code
; =============== S U B R O U T I N E =======================================
CREATEDIALOG proc near syscall public uses ebx edi esi win:DWORD
LOCAL lf :LOGFONT
LOCAL wc :WNDCLASSEX
LOCAL tm :TEXTMETRICA
mov eax, tm.tmAveCharWidth
mov esi, SIZEOF(DLGTEMPLATE) + 21 + (SIZEOF DlgClassN)*2 + (SIZEOF MSSansSerif)*2
ret 4
CREATEDIALOG endp
end
Compiles into with MASM:
public CREATEDIALOG
CREATEDIALOG proc near
push ebp
mov ebp, esp
add esp, 0FFFFFF5Ch
push ebx
push edi
push esi
mov eax, [ebp-8Dh]
mov esi, 61h
pop esi
pop edi
pop ebx
leave
retn 4
CREATEDIALOG endp
With JWASM (/Zg):
public CREATEDIALOG
CREATEDIALOG proc near
push ebp
mov ebp, esp
add esp, 0FFFFFF5Ch
push ebx
push edi
push esi
mov eax, [ebp-90h]
mov esi, 5Fh
pop esi
pop edi
pop ebx
leave
retn 4
CREATEDIALOG endp
Like I sad I am not sure that this is causing the problem but likelly.
Quote from: Ficko on December 12, 2009, 06:48:40 PM
Just slow down a little bit. :bg
I didn't say everything is ok.
Just sad that JWASM didn't report error. :P
Too late.
Quote
Seriously there is something not working right in my library.
A dialog won't open but no exception is generated.
You have to provide a full test case.
Quote
I did found something that is strange may causing the problem.
...
Like I sad I am not sure that this is causing the problem but likelly.
I doubt it. AFAICS the little difference between Masm's and JWasm's code generation is due to a small flaw in your definition of TEXTMETRICA. The correct, C-compatible size of this structure is to be 56, but yours is 53 only. You should add a DWORD alignment argument to the struct definition.
Quote
I doubt it. AFAICS the little difference between Masm's and JWasm's code generation is due to a small flaw in your definition of TEXTMETRICA. ...
Yes I figured out that one.
But the second difference is more questionable.
I am building a dialoge template in memory and the calculations will be screwed up if I am getting different sizes.
mov esi, SIZEOF(DLGTEMPLATE)
give me MASM equivalent size only without (/Zg)
Looks like the alignment
DLGTEMPLATE STRUCT DWORD
get ignored.
Quote from: Ficko on December 13, 2009, 11:36:48 AM
I am building a dialoge template in memory and the calculations will be screwed up if I am getting different sizes.
mov esi, SIZEOF(DLGTEMPLATE)
give me MASM equivalent size only without (/Zg)
Looks like the alignment
DLGTEMPLATE STRUCT DWORD
get ignored.
DLGTEMPLATE is to be handled differently according to MS PSDK:
/*
* WARNING:
* The following structures must NOT be DWORD padded because they are
* followed by strings, etc that do not have to be DWORD aligned.
*/
#include <pshpack2.h>
/*
* original NT 32 bit dialog template:
*/
typedef struct {
DWORD style;
DWORD dwExtendedStyle;
WORD cdit;
short x;
short y;
short cx;
short cy;
} DLGTEMPLATE;
typedef DLGTEMPLATE *LPDLGTEMPLATEA;
typedef DLGTEMPLATE *LPDLGTEMPLATEW;
...
So sizeof DLGTEMPLATE must be 18, not 20.
Quote from: Ficko on December 13, 2009, 11:36:48 AM
give me MASM equivalent size only without (/Zg)
I overread this sentence at first glance. While it is correct that sizeof DLGTEMPLATE is to be 18, JWasm's option /Zg must not have any impact on structure sizes. However, in v2.01 - and also in v2.00 - it has an impact, which makes option /Zg unusable in these versions!
Quote
I overread this sentence...
Damn!
You were faster I was almost ready with a "nasty" answer. :green :bg
Quote from: Ficko on December 13, 2009, 12:48:32 PM
Damn!
You were faster I was almost ready with a "nasty" answer. :green :bg
Don't worry! I'm known for arrogant and/or annoying replies, so I'm sure there will be good opportunities for "nasty" answers in the future.
there's a prelim. v2.02 now where's the -Zg switch has no impact on structure "padding":
http://www.japheth.de/Download/JWasm/JWasm202b.zip
Cool!
At first glance seems to work. :U
It's probably my inexperience again but I cannot get the Win64_2.asm and Win64_3e.asm examples to assemble. Using the Microsoft Linker Version 9.00.30729.01 i got 14 unresolved external symbol errors, 3 are LNK2001 errors & 11 are LNK2019 errors. I'm happy that JWasm 2.01 assembles my 32 bit code like the champion it is.
Thanks again for this great assembler japheth.
Quote from: Alloy on January 01, 2010, 03:00:47 PM
It's probably my inexperience again but I cannot get the Win64_2.asm and Win64_3e.asm examples to assemble. Using the Microsoft Linker Version 9.00.30729.01 i got 14 unresolved external symbol errors, 3 are LNK2001 errors & 11 are LNK2019 errors. I'm happy that JWasm 2.01 assembles my 32 bit code like the champion it is.
From what you're telling it seems that the assembly step did run without errors, but it's the linker which feels like complaining? Then the reason probably is that you're feeding it with the wrong libraries. Please note that there are 64-bit versions of kernel32.lib and user32.lib which must be used for linking, because the calling convention ( and thus the name decoration ) has changed.
Great!!! That was my problem. It works. Thanks again.