Recent Posts

21

64 Bit Assembler / Re: May 20, update.

« Last post by TouEnMasm on July 03, 2020, 05:09:30 PM »

To be more clear,here is a sample using my headers http://luce.yves.pagesperso-orange.fr/header.htm
I have re-took the messagebox 64 bits provided by UASM and added a messagebox using the headers
As i say,you add "include sdk64.inc" and all is done.
You can put in comment the useless things (externdef ...)
ML64 is like a dinosaure if we compare it with UASM.
What is simple to use,must stay simple.

22

64 Bit Assembler / Re: May 20, update.

« Last post by TouEnMasm on July 03, 2020, 03:46:00 PM »

No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.

Here,I am a little lost.
I have re-compiled my IDE (32) with my headers and with UASM without a problem.
For 64 bits ,I have made further little prog using UASM and my headers without a problem.

With my headers,to use UASM ,You need to download the package and include the SDK64.inc ,That's all.
Where is the problem ?

23

The Campus / Re: push/pop in 64 bit

« Last post by Biterider on July 03, 2020, 03:36:53 PM »

Hi JJ

Really fun article. Fortunately, I did NOT find it before ...
Otherwise I would not have followed the 64bit path so quickly.


Biterider

24

Full SDK Include Project / Re: A translator for sdk header files (64 and 32 bits translate)

« Last post by TouEnMasm on July 03, 2020, 03:25:07 PM »

I see than you speak about Size_T  and about PTR ,have you  a modify to ask ?

25

The Campus / Re: push/pop in 64 bit

« Last post by jj2007 on July 03, 2020, 09:44:34 AM »

Three years ago CMalcheski wrote a nice article titled Nightmare on (Overwh)Elm Street: The 64-bit Calling Convention. It's fun to read

26

ASMC Development / Re: Object-oriented programming (OOP) in Asmc

« Last post by nidud on July 03, 2020, 08:55:33 AM »

Assignment of members based on input.

The main reason for these constructs is to optimize code based on type. The typeid operator is in C++ part of the standard library header typeinfo.

The Asmc implementation is similar and used as type identification for macro arguments. It's a text macro and may be used for direct branching in a class or a regular macro. This simplify and also gives a more accurate type definition than TYPE and OPATTR that is often used for the same purpose.

The preprocessor also handles real math so this opens up more possibilities for doing the same as more advanced compilers do. This also means that more code is moved to the header files but less needed on the user end.

As an example the ARGB color constants are defined as a DWORD and expanded to a D3DCOLORVALUE struct of 4 float values. The input will then in most cases be immediate values:

    .new color:D3DCOLORVALUE(Black, 0.0)

The code for each float:

    mov      eax,_1
    and      eax,sc_redMask
    shr      eax,sc_redShift
    cvtsi2ss xmm0,eax
    divss    xmm0,255.0
    movss    [rcx].D3DCOLORVALUE.r,xmm0

Or the simplified version:

    %mov [rcx].D3DCOLORVALUE.r, @CatStr(%((_1 and sc_redMask) shr sc_redShift), <.0>) / 255.0

27

The Campus / Re: push/pop in 64 bit

« Last post by hutch-- on July 03, 2020, 07:37:52 AM »

In win64 FASTCALL, each argument fits into a 64 bit location, the first 4 are what is called "shadow space" as the first 4 arguments are written to 4 registers, rcx rdx r8 and r9. Any additional arguments get written to the higher addresses on the stack so you have a format something like this.

reg | reg| reg | reg | mem | mem | mem | etc ......

If you pass arguments of different sizes from BYTE to QWORD, they are all written to 64 bit addresses and the important thing here is the stack remains at the same alignment. By writing arguments according to the 64 bit Windows calling convention, you don't have to balance the stack on exit with a "ret number", you just use a "ret".

I know for certain that UASM uses the convention correctly and I have no doubt that nidud does so as well. With MASM I had to write the macros that set up the stack for procedure calls and the "invoke" style technique for calling procedures.

It can be done by writing the procedure and the calling technique manually but it is messy and very unreliable where having this automated makes win64 as easy to use as win32. With all of the extra registers and FASTCALL, win64 is more efficient and has less overhead than the 32 bit STDCALL where you push args and balance the stack on exit.

28

64 Bit Assembler / Re: May 20, update.

« Last post by HSE on July 03, 2020, 07:37:11 AM »

No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.

There is a set of includes and libraries for UASM. Biterider maked that for ObjAsm.

29

64 Bit Assembler / Re: May 20, update.

« Last post by hutch-- on July 03, 2020, 07:17:56 AM »

No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.

30

The Campus / Re: push/pop in 64 bit

« Last post by jj2007 on July 03, 2020, 05:44:11 AM »

In 64 bit i can do all the things with the stack i can do in 32 bit as long as this rule is met - is this correct?

Many but not all the things

check carefully the concept of shadow space, e.g. googling for shadow space x64