HJWasm Releases

[nidud]

deleted

[habran]

Hi nidud, which compiler are you using?
It compiles fine with VS13
It looks to me that your compiler can not handle 'int i'
Tray to declare it before for loop like:

Code Select Expand


  int i;
     for ( i = 0; i < len; i++)
        CurrSeg->e.seginfo->CodeBuffer[idx++] = *(pBytes++);


[GoneFishing]

I'm afraid I'm too slow and you're applying changes to source code tooo quick ... but  finally I got to compile HJWasm as it was in times of post #101 + patched codegen.c (#107 )

Built with Open Watcom C compiler 1.9 ,  linked with JWLINK  on  Linux
Size of executable:

337401

Output from file utility:

./hjwasm: ELF 32-bit LSB  executable, Intel 80386, version 1 (GNU/Linux), statically linked, not stripped

OW compiler can't produce 64 bit executables.

[EDIT]:  Always wanted to ask how to run regression tests from JWASM source code in batch mode ?

[nidud]

deleted

[jj2007]

What habran meant is

Code Select Expand

int i;
for (i = 0; i < len; i++)
instead of

Code Select Expand

for (int i = 0; i < len; i++)

IIRC MS VS doesn't like it in C mode, but accepts it if the source ending is .cpp.

[qWord]

In C data needs to be declared like { int a,b; /* use a and b */ }, so adding data on the fly generates errors.

This restriction had been removed with ISO/ANSI-C99.

[johnsa]

Tray to declare it before for loop like:

Yes, that's a good habit.

In C data needs to be declared like { int a,b; /* use a and b */ }, so adding data on the fly generates errors.

Code Select Expand


fseek( file, 0L, SEEK_END );
long sz = ftell( file ) - fileoffset;


Ok,

1) I've modified assemble.c (line 253) to declare int i; before the loop.. as this should be more compatible then with non C99 compilers.. github updated.. again.. :)

[TouEnMasm]

My test program for 64 bits is here:
http://masm32.com/board/index.php?topic=4528.msg48489#msg48489
He is in tut64_partiel.zip and named tut31nlistview.asm and had a batch for compile.

[TouEnMasm]

This time,Iget an assertion failure:
see zip file
istype.cpp line 26

[habran]

Hi ToutEnMasm,
Your mistake is here:

Code Select Expand


start:
;fastcall need stack space before call
;one qword for return adress of call
;
    add rsp,-(8 + 80 * 8) ; - (align + shadow space) ;generous size + align 16
    ;invoke DebugBreak
invoke GetModuleHandle, NULL
mov    hInstance,rax
mov InitCtrls.dwSize,sizeof INITCOMMONCONTROLSEX
mov InitCtrls.dwICC, ICC_LISTVIEW_CLASSES
invoke InitCommonControlsEx,addr InitCtrls ;cumulatif

invoke WinMain, hInstance,NULL, NULL, SW_SHOWDEFAULT
invoke ExitProcess,eax

end start

You can not do that in x64 code
You have to use 'WinMainCRTStartup PROC FRAME USES ....'
and don't mess with stack alignment HJWasm takes care for you if you use PROC FRAME and :

Code Select Expand


option casemap : none
option win64 : 11
option frame : auto
option STACKBASE : RSP


[TouEnMasm]

There is no mistake here and the proc works perfectly since a long time.
Run the exe.
There is just a stack reserve a little too big.
Don't search here it's a vast of time.

[TouEnMasm]

Here the compiled listview with Jwasm 2.13 without your avx 512

Here what see windbg on it,NOTHING:

************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       symsrv*symsrv.dll*c:\symbols*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
OK                                             H:\tut64_partiel\tute31
Deferred                                       SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols
0:000> g
ModLoad: 00007ffc`479c0000 00007ffc`479fb000   C:\WINDOWS\system32\IMM32.DLL
ModLoad: 00007ffc`433c0000 00007ffc`43456000   C:\WINDOWS\system32\uxtheme.dll
ModLoad: 00007ffc`47530000 00007ffc`477ad000   C:\WINDOWS\system32\combase.dll
ModLoad: 00007ffc`44be0000 00007ffc`44c4a000   C:\WINDOWS\system32\bcryptPrimitives.dll
ModLoad: 00007ffc`47a60000 00007ffc`47bba000   C:\WINDOWS\system32\MSCTF.dll
ModLoad: 00007ffc`41490000 00007ffc`414b2000   C:\WINDOWS\system32\dwmapi.dll
ModLoad: 00007ffc`37600000 00007ffc`37874000   C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.10586.0_none_8c15ae12515e1c22\comctl32.DLL
ModLoad: 00007ffc`45680000 00007ffc`45735000   C:\WINDOWS\system32\SHCORE.dll
ModLoad: 00007ffc`44970000 00007ffc`4497f000   C:\WINDOWS\system32\kernel.appcore.dll
ModLoad: 00007ffc`472c0000 00007ffc`47403000   C:\WINDOWS\system32\ole32.dll
ntdll!NtTerminateProcess+0x14:
00007ffc`483e5364 c3              ret

[johnsa]

Ok.. I downloaded your source and your full include project..
first thing i had to do was change line 442 of commctrl.sdk

It has a struct member called Frame (which is a reserved word) so I made it _Frame.

Then i created a new batch file to build.. set the includes.. using the latest hjwasm64.exe ... and it works perfectly.. (I still agree with Habran.. you really should never touch RSP.. ever.. and it's best to use WinMainCRTStartup as an actual PROC (rather than just the start: label).

I've attached my folder (including a new build.bat file AND the exe as it's just assembled/linked for me.. which is working fine), using the same hjwasm64 available for download.. and this works perfectly.
The only difference between us might possibly be that I'm using the libs from the platform / windows sdk.. but they should be identical.

[TouEnMasm]

Thanks to try
I am a little lost on your various versions of jwasmx64
I get the same result with:
HJWasm v2.13.64bit., Jan 27 2016, Masm-compatible assembler.
Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz
Microsoft Windows 10 Famille Version: 10.0.10586
correct results with 32 bits asm compile

On the RSP use,see:
http://blogs.msdn.com/b/ntdebugging/archive/2009/01/09/challenges-of-debugging-optimized-x64-code.aspx

It's the better and usable information on the subject

[johnsa]

HJWasm will automatically allocate and utilise the stack space (following the abi).

1) so a minimum of 32 bytes are always reserved
2) if you have 4+ args and shadow space enabled, the args will be copied
3) if you don't have shadow space enabled (which you always should by virtue of win64:11).. then no home space are used
4) irrespective of 2 and 3.. if there are unused slots in the homespace these will be used for non-volatiles (preserved via USES) AND / OR locals..
5) each proc will automatically determine the maximum shadow space requirement of all invokes within itself and adjust accordingly at prologue

So.. it's basically exactly what a C++ compiler would do with optimisations on.. except perhaps for using RSP for all references instead of RBP.

So.. based on that
1) NEVER use push/pop at all ever for anything..
2) NEVER touch RSP..
3) 1+2 will make your life much happier and trouble-free :)