Author Topic: Asmc source and binaries  (Read 14144 times)

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #90 on: July 06, 2018, 06:56:26 AM »
Added more support for 32-bit vectorcall. This was rendered as a 32-bit fastcall without support for XMM and stack arguments.

This behaves a bit different from the 64-bit implementation where no stack is allocated for register arguments, so these refer directly to registers as oppose to a memory location. Register usage is limited to ECX and EDX but support up to six XMM registers (XMM0..5).

A bit clunky to use REAL8 values to XMM args given they will be needing a memory location in this case. This is done by pushing the number to the stack, load the XMM register and pop the stack:

    foo proto :real8, :real4
    foo(8.0, 4.0)
  * mov eax, 4.0
  * movd xmm1, eax
  * pushd high32 (8.0)
  * pushd low32 (8.0)
  * movq xmm0, [esp]
  * add esp, 8
  * call foo@@12

A test case is added to the regression folder for the stack versus reg usage.

I also added one more test using 32-bit in the D3D11 directory. This from the Tutorial04.cpp file:

  This application displays a 3D cube using Direct3D 11

  http://msdn.microsoft.com/en-us/library/windows/apps/ff729721.aspx

The 32-bit binary is around 8K but uses only inline functions (macros) from the DirectXMath library.

Caché GB

  • Member
  • **
  • Posts: 59
  • MASM IS HOT
Re: Asmc source and binaries
« Reply #91 on: July 06, 2018, 05:20:20 PM »
Hello nidud.

I must say you have an awesome project going here. Are you perhaps considering
creating some day an IDE may be something like Thomas Jaeger's Visual MASM?
Caché GB's 1 and 0-nly language:MASM

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #92 on: July 06, 2018, 09:40:16 PM »
Are you perhaps considering creating some day an IDE may be something like Thomas Jaeger's Visual MASM?

 :biggrin:

I'm a bit old-fashion so I mainly use make files and command-line tools.

Assuming this is a graphic editor I will consider this a waste of time. When writing code I only use text based IDE's without fiddling with a mouse and a mace of settings. I also find all of this (time-consuming) bling bling rather annoying that seems to crave more attention than it's actual purpose, so at best the editor should cover the whole screen.



The simple IDE included in the Asmc package allows easy access to file handling, edit, transfer, search and many other things directly from the keyboard.
« Last Edit: July 06, 2018, 11:03:54 PM by nidud »

zedd151

  • Member
  • ****
  • Posts: 847
Re: Asmc source and binaries
« Reply #93 on: July 06, 2018, 10:34:36 PM »
I'm a bit old-fashion so I manly use make files and command-line tools.

How about Edlin ?   :P
 
I could'nt get it to run in Win 7 - 64 b
 
So, all you get is a screen shot of it's properties page.  :biggrin:
« Last Edit: July 19, 2018, 04:19:30 PM by zedd151 »
I'm not always the sharpest knife in the drawer, but I have my moments.  :P

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #94 on: July 06, 2018, 11:00:39 PM »
 :biggrin:

copy con test.asm

Caché GB

  • Member
  • **
  • Posts: 59
  • MASM IS HOT
Re: Asmc source and binaries
« Reply #95 on: July 09, 2018, 07:52:59 AM »
Hello nidud.

If you are a bit old-fashioned I do respect that.
Thank you very much for the reply.

Caché GB's 1 and 0-nly language:MASM

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #96 on: July 09, 2018, 09:05:20 AM »
Could be I'm set in my old ways I guess but I did write a test pad some time ago with syntax highlighting similar to the above so there is at least a resemblance of something.

I do however use a few IDE's so different tools for different things.

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #97 on: July 11, 2018, 08:34:57 AM »
Next sample, Tutorial05.cpp:

    Tutorial 5: 3D Transformation

    https://msdn.microsoft.com/en-us/library/windows/apps/ff729722.aspx

Bit of a mystery this one. The Win32 PE binary works fine but the Win64 PE version seems to scale the objects (zoom) for some reason. Using the linker however (in 64-bit) works fine. The build commands for all three:

Win32 PE:
    asmc -pe -gui -I\Asmc\include test.asm
Win64 PE:
    asmc -pe -win64 -gui -I\Asmc\include test.asm
Win64:
    asmc -gui -win64 test.asm
    linkw system gui_64 file test

« Last Edit: July 11, 2018, 10:56:48 AM by nidud »

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #98 on: July 14, 2018, 08:31:51 AM »
Extensive use of the FLT4(value) macro tend to create a lot of duplicate numbers so this now reuse the value if already defined.

The DirectXMath library now include most of the Matrix and Vector functions, 213 modules so far, but only a selected few of them are exclusive. This means you may use most of the functions directly without using the actual library.

The net benefit of using the library versus the C++ implementation with regards to size seems to be exactly 1:10, so the last sample built with full optimization is around 80K in C++. Using memory (no vectorcall) adds around 30K on top of that.

As for benchmark this is a bit tricky to do. You want full optimization applied to the library code but given the actual test code do not do anything useful this will be removed by the compiler. Using the pragma directive to enforce the meaningless call sequence, the ASM test using the same sequence with no in-lining, should produce the same results.

Code: [Select]
#pragma optimize( "", off )

void main()
{
    __int64 time_start = GetTickCount64();

    for ( int i=0; i < 1000000; i++ ) {

        DirectX::XMScalarSinCos(&Sin, &Cos, 20.5f);
        DirectX::XMVectorSinCosEst(&C1, &C2, V);
        DirectX::XMVectorModAngles( V );
        DirectX::XMVectorLog( V );
        DirectX::XMVectorSin( V );

The result from a selected few functions is 1:1. Without vectorcall the result is around 1:3.

As for function calls versus macros the functions preserves XMM6 and XMM7 (the library only use XMM0..7) and the macros allows immediate values so this will tilt the benchmark towards the latter.

Caché GB

  • Member
  • **
  • Posts: 59
  • MASM IS HOT
Re: Asmc source and binaries
« Reply #99 on: July 16, 2018, 09:31:18 AM »
Hello nidud.

You are making it very exciting to be programming DX11 in ASM.

I do like your floating point variable redundancy checking Macros.
I've been using the ones developed by savage here-

http://www.masmforum.com/board/index.php?topic=5453.0  (Reply #5)

I have now replaced then with yours.

Thank you.
Caché GB's 1 and 0-nly language:MASM

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #100 on: July 21, 2018, 07:56:19 PM »
However, I don't think you will find any of these algos included in msvcrt.dll.

Hi nidud,

Sorry if I am missing something but msvcrt.dll exports memcpy and a lot of traditional C functions :

What I suspect is that Microsoft never used ML64 in any 64-bit versions of Windows. The CRT assembler source supplied with VS do not correspond with any of the functions in the .dll files (msvcrt.dll in this case) as they do in 32-bit. There is also missing files there which makes it impossible to assemble any of the source supplied. The answer giving with regards to this also suggest 64-bit assembly is not a big priority for Microsoft.

This may explain the limitations of the assembler: they don't need it.

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #101 on: July 21, 2018, 08:53:55 PM »
Some new updates:
- added fix for flags ZERO? || CARRY? in hll
- fixed bug in using 0.0 as argument -- asin(0.0)
- allowed support for movq rax,xmm0

The combined flags are now rendered as LE (or GT):

_mm_comile_sd macro a, b
   comisd a, b
   retm<ZERO? || CARRY?>
   endm
_mm_ucomigt_sd macro a, b
   ucomisd a, b
   retm<!(ZERO? || CARRY?)>
   endm

    .if _mm_comile_sd(xmm0, xmm1)
    .if _mm_ucomigt_sd(xmm0, xmm1)

Code: [Select]
jz ?_001  ; -- old
jnc ?_002
?_001: nop
?_002: jz ?_003
jc ?_003
nop
        ...
ja ?_001  ; -- new
nop
?_001: jbe ?_002
nop

A float value of zero was rejected as argument so this is now fixed. REAL16 const values in vectorcall are now allowed. They will be moved directly to [rsp] and loaded to a corresponded vector:

foo proto vectorcall a1:real16

    foo(-3.0)

Code: [Select]
        mov     qword ptr [rsp], 0
        mov     rax, 0C000800000000000H
        mov     qword ptr [rsp+8H], rax
        movaps  xmm0, xmmword ptr [rsp]
        call    foo@@16

Some math functions are added:
- REAL4 (float) - fastcall
- REAL8 (double) - fastcall
- REAL10 (long double) - vectorcall
- REAL16 (__float128) – vectorcall

The REAL10 version is REAL16 vectors using the FPU.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5756
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Asmc source and binaries
« Reply #102 on: July 25, 2018, 06:35:13 PM »
 :P

> This may explain the limitations of the assembler:

What limitations ? This sounds like propaganda.  :eusa_naughty:
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

nidud

  • Member
  • *****
  • Posts: 1605
    • https://github.com/nidud/asmc
Re: Asmc source and binaries
« Reply #103 on: July 25, 2018, 10:59:31 PM »
The limitations of ML64 versus ML should be pretty obvious where the latter was made for building applications and the former is not.

One of the reasons for this is the calling convention used which, in addition to vectorcall, makes assembly more or less obsolete so that may explain the future of assembler from Microsoft's point of view.

To compete with this is difficult given you have to produce something less bloated and faster than an optimized compiler is capable of producing with at least the same readability as ML.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5756
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Asmc source and binaries
« Reply #104 on: July 25, 2018, 11:35:01 PM »
I have heard claptrap like this before, back in the 90s it was the TASM brigade with much to say and little performance and ML.EXE took a lot of criticism while it was being developed but MASM (ML.EXE) outlasted and out performed them all. The only real difference was that ML was part of the last commercial MASM product where the 64 bit version was developed as part of VC\VS and it was never designed as a consumer product.

MASM is not trying to be a C compiler, it is an assembler and while it is missing a few consumer luxuries, there is very little it cannot do, works fine in AVX, SSE, MMX and integer instructions and with enough pre-processor support it is already application capable. While I have a grasp of what you are designing as an asm / C hybrid, you don't have a point of comparison here, MASM is an assembler, you use CL.EXE for C code, MASM does not need to emulate it.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin: