Aligning memory for later instructions.

[hutch--]

Simple enough to do and necessary for XMM and YMM operations.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL pMem :QWORD           ; allocated memory pointer
    LOCAL aMem :QWORD           ; aligned memory pointer

    padd equ <512>              ; extra bytes (must be at least size of required alignment)
    bcnt equ <1024*1024*4>      ; 4 meg

    mov pMem, alloc(bcnt+padd)  ; allocate the memory plus padding
    memalign rax, 256           ; align the memory up to the next 256 byte boundary
    mov aMem, rax               ; store result in aligned memory pointer

  ; do what you need with the 256 byte aligned memory (YMM addresses, register etc ....)

    mfree pMem                  ; free the original allocated address

    waitkey

    invoke ExitProcess,0

    ret

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

[K_F]

Doing something similar with dynamic pointer allocations... but using bit/and comparisons ?

[jj2007]

For the amount of memory usually needed for working efficiently with YMM regs, wouldn't VirtualAlloc be a good choice?

[hutch--]

 

Once memory is allocated, its all the same, whatever floats your boat.  :P

[jj2007]

Yes, but with VirtualAlloc you get the alignment "for free" ;-)

[hutch--]

Another trick while tweaking the main include file, mis-align at least some structures and it crashes when the procedure that tries to use it is called. 8 byte alignment is necessary with most and probably all structures used in 64 bit.

[jj2007]

Another trick while tweaking the main include file, mis-align at least some structures and it crashes when the procedure that tries to use it is called. 8 byte alignment is necessary with most and probably all structures used in 64 bit.

Indeed. The Zp switch is the way to go...

And that one works fine if you build it with Zp4 for 32-bit and Zp8 for 64-bit code, but it crashes for X64 and Zp4.

Which means that the default structure alignment of the Windows API is DWORD in 32-bit code and QWORD in 64-bit code. Both on a 64-bit processor, of course (see Reply #30); Redmond should take their documentation a bit more seriously 8)

[hutch--]

 

This is only a problem if you are trying to multiport similar assemblers. ML64 is NOT MASM compatible, it is only ML64 compatible, its error messages while organising include files are unintelligible and buggy and at time crashes with stack dumps. It does not have the tolerance that the old ML had and is a genuine joy to make working include files for structures and equates.

Now if you have a look at the guts of Japheth's h2incX output you will have genuine nightmares at this tangled mess of typedefs, prototypes, bugs, equates, the odd "tag" attached to the front of structures and with a possible delivery date at about the year 3000.

[jj2007]

if you have a look at the guts of Japheth's h2incX output you will have genuine nightmares at this tangled mess of typedefs, prototypes, bugs, equates, ...

The C++ fraction will insist that the 100+ types are necessary. IMHO the only real change from Windows.inc+WinExtra.inc is the distinction between "data" DWORDs (they can stay "as is") and "pointers" that are DWORDs in 32-bit code, and QWORDs in 64-bit code. In \Masm32\MasmBasic\Res\DualWin.inc the latter is called SIZE_P, and it's size depends on whether you build 32- or 64-bit code, obviously. Otherwise, there are only minor changes compared to Windows.inc+WinExtra.inc - a few structure members choked with ML64.

So, give DualWin.inc a try - no tangled mess of typedefs, prototypes, bugs, equates, just the old Windows.inc format.

Besides, it runs with all assemblers. So if you are fond of unintelligible and buggy error messages and stack dumps, use ML64, if instead you like the old .if eax>99 etc syntax, you can use the same include file with HJWasm.

[hutch--]

 

>  So if you are fond of unintelligible and buggy error messages and stack dumps, use ML64

I don't have the problem, I am not trying to use Japheth's includes. With ML64 I am free of "Open Sauce" licencing and the army of parasites that come with it. 

[mineiro]

With ML64 I am free of "Open Sauce" licencing and the army of parasites that come with it. 

Cmon sir hutch, tell us the true, you probably have a lot of softwares "open sauce" inside your computer, from pdf readers to disassemblers, just look to libraries.

But I take your point of view, I don't like open source too just because one thing: have lawyers inside. This is why I prefer public domain.

[jj2007]

>  So if you are fond of unintelligible and buggy error messages and stack dumps, use ML64

I don't have the problem, I am not trying to use Japheth's includes. With ML64 I am free of "Open Sauce" licencing and the army of parasites that come with it. 

Me neither. I am trying to use the standard Masm32 includes. Unfortunately, they make Microsoft ML64 crash with exceptions.

[hutch--]

That is because they were written for 32 bit ML.EXE, they are not compatible with ML64. I would not be doing the work if it was. Shortly I will have another tool that isolates the prototypes in the Microsoft vc2015 header files and that will be a method of creating prototypes for 64 bit assembler. I don't need it for ML64 but it will be useful for the assemblers that need prototypes. I doubt you can get an auto converter to work on the C .H files, they are too much of a tangled mess and too much useless noise but you can get equates, structures and prototypes which will ease the production of assembler include files.

I have attached a zip file with a C header file cleaner in it. A lot more needs to be done with it but it converts C hex to asm hex, removes the comments and a lot of the junk. Just drop a C header file onto it and it will produce a text file "cleaned.txt" that is at least readable.

[jj2007]

That is because they were written for 32 bit ML.EXE, they are not compatible with ML64. I would not be doing the work if it was. Shortly I will have another tool that isolates the prototypes in the Microsoft vc2015 header files and that will be a method of creating prototypes for 64 bit assembler. I don't need it for ML64

You may compare your results to the attached \Masm32\MasmBasic\Res\pt.inc, which gets generated if somebody attempts to run the MasmBasic 64-bit examples.

Hutch,

The error checking of invoke is relevant for this type of case:

Code: [Select]

invoke CreateFile, esi, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0, 0
And for nothing else. I guess we can safely assume that everybody can write their own proc with named parameters like hWnd and the like. If then somebody is thick enough to add a fifth parameter to the PROTO list, he should really go for Scratch or Logo 8)

Btw Microsoft's CrippleWare Assembler^TM can be convinced to count the paras. I am currently a bit stuck with the PROLOGUE bug, but with ML64 jinvoke works like a charm :icon_mrgreen:

[hutch--]

This looks like an interesting technique.

j@BitBlt equ 2069/41:s111111111

Just a suggestion, instead of just supplying the argument count, use a 1 character notation for the data size.

q = QWORD
d = DWORD
w = WORD
b = BYTE