On Sunday, 12 November 2017 at 21:27:28 UTC, Dibyendu Majumdar wrote:
> On Sunday, 12 November 2017 at 18:48:02 UTC, Eugene Wissner wrote:
>>>> https://dlang.org/spec/iasm.html#agregate_member_offsets
>>>>
>>>> aggregate.member.offsetof[someregister]
>>>
>>> Sorry I didn't phrase my question accurately. Presumably to use above with the mnemonics I would need additional mixin templates where the aggregate type and member etc would need to be parameters?
>>
>> You can use just string parameters instead of enums, then you can pass arbitrary arguments to the instructions. The compiler will tell you if something is wrong with the syntax of the generated assembly.
>
> Okay thank you. Sigh. It would be so much simpler to be able to just define mnemonics for registers.
>
> Anyway, another question:
>
> Does the compiler generate appropriate unwind information on Win64? Prsumably if a function is marked 'naked' then it doesn't?
>
> Thanks and Regards
> Dibyendu

yeah about stack frame..., also don't forget to mark the asm block "pure nothrow" if possible...
It's not documented but the syntax is like that:

```
void foo()
{
    asm pure nothrow
    {
        naked;
        ret;
    }
}

```

On Sunday, 12 November 2017 at 22:00:58 UTC, Basile B. wrote:
> On Sunday, 12 November 2017 at 21:27:28 UTC, Dibyendu Majumdar

>> Does the compiler generate appropriate unwind information on Win64? Prsumably if a function is marked 'naked' then it doesn't?
>>
> yeah about stack frame..., also don't forget to mark the asm block "pure nothrow" if possible...
> It's not documented but the syntax is like that:
>
> ```
> void foo()
> {
>     asm pure nothrow
>     {
>         naked;
>         ret;
>     }
> }
>
> ```

I am not sure I have understood above; will DMD generate the right Win64 unwind info for this contrived example:

int luaV_interp(lua_State *L)
{
	asm pure nothrow {
		naked;
		push RDI;
		push RSI;
		push RBX;
		push R12;
		push R13;
		push R14;
		push R15;
		sub RSP, 5*8;
		mov  RAX, 0;
		add RSP, 5*8;
		pop R15;
		pop R14;
		pop R13;
		pop R12;
		pop RBX;
		pop RSI;
		pop RDI;
		pop RBP;
		ret;
	}
}

On Sunday, 12 November 2017 at 22:20:46 UTC, Dibyendu Majumdar wrote:
> On Sunday, 12 November 2017 at 22:00:58 UTC, Basile B. wrote:
>> On Sunday, 12 November 2017 at 21:27:28 UTC, Dibyendu Majumdar
> I am not sure I have understood above; will DMD generate the right Win64 unwind info for this contrived example:

no in naked mode you have to save and restore by hand.

On Sunday, 12 November 2017 at 22:24:08 UTC, Basile B. wrote:
> On Sunday, 12 November 2017 at 22:20:46 UTC, Dibyendu Majumdar wrote:
>> On Sunday, 12 November 2017 at 22:00:58 UTC, Basile B. wrote:
>>> On Sunday, 12 November 2017 at 21:27:28 UTC, Dibyendu Majumdar
>> I am not sure I have understood above; will DMD generate the right Win64 unwind info for this contrived example:
>
> no in naked mode you have to save and restore by hand.

So how does one manually generate the .pdata and .xdata sections?
Are you saying that this is what I would need to do?

Another question - how can I tell DMD to no generate the frame pointer?

Thanks for answering my questions.

Regards
Dibyendu

On Sunday, 12 November 2017 at 11:01:39 UTC, Dibyendu Majumdar wrote:
> Hi,
>
> I have recently started work on building a VM for Lua (actually a derivative of Lua) in X86-64 assembly. I am using the dynasm tool that is part of LuaJIT. I was wondering whether I could also write this in D's inline assembly perhaps, but there is one aspect that I am not sure how to do.
>
> The assembly code uses static allocation of registers, but because of the differences in how registers are used in Win64 versus Unix X64 - different registers are assigned depending on the architecture. dynasm makes this easy to do using macros; e.g. below.
>
> |.if X64WIN
> |.define CARG1,		rcx		// x64/WIN64 C call arguments.
> |.define CARG2,		rdx
> |.define CARG3,		r8
> |.define CARG4,		r9
> |.else
> |.define CARG1,		rdi		// x64/POSIX C call arguments.
> |.define CARG2,		rsi
> |.define CARG3,		rdx
> |.define CARG4,		rcx
> |.endif
>
> With above in place, the code can use the mnemonics to refer to the registers rather than the registers themselves. This allows the assembly code to be coded once for both architectures.
>
> How would one do this in D inline assembly?
>
> Thanks and Regards
> Dibyendu

TBH I wonder if this is not worth a enhancement (or even a DIP)
to have in asm blocks a special alias syntax...

{
    asm
    {
        version(...)
        {
           alias First = RDI;
           alias Second = RSI;
           // ...
        }
        else
        {
           alias First = RCX;
           alias Second = RDX;
        }
        mov First, Second;
        call aFunctionWithOneParam; // called with 2nd parent param as 1st param
    }
}

since the whole mixin solution make the custom asm unreadable just because of this problem.

And Even maybe some special identifiers since extern(...) may lead to problems...

On Monday, 13 November 2017 at 18:40:42 UTC, Basile B. wrote:
> On Sunday, 12 November 2017 at 11:01:39 UTC, Dibyendu Majumdar wrote:
>> [...]
>
> TBH I wonder if this is not worth a enhancement (or even a DIP)
> to have in asm blocks a special alias syntax...
>
> {
>     asm
>     {
>         version(...)
>         {
>            alias First = RDI;
>            alias Second = RSI;
>            // ...
>         }
>         else
>         {
>            alias First = RCX;
>            alias Second = RDX;
>         }
>         mov First, Second;
>         call aFunctionWithOneParam; // called with 2nd parent param as 1st param
>     }
> }
>
> since the whole mixin solution make the custom asm unreadable just because of this problem.
>
> And Even maybe some special identifiers since extern(...) may lead to problems...

Hmmm being the fact that "First" might be XMM0 i actually think the predefined identifiers is clearly not a solution.

"alias" in asm blocks still stands though

On Monday, 13 November 2017 at 18:40:42 UTC, Basile B. wrote:
> TBH I wonder if this is not worth a enhancement (or even a DIP)
> to have in asm blocks a special alias syntax...
>
> {
>     asm
>     {
>         version(...)
>         {
>            alias First = RDI;
>            alias Second = RSI;
>            // ...
>         }
>         else
>         {
>            alias First = RCX;
>            alias Second = RDX;
>         }
>         mov First, Second;
>         call aFunctionWithOneParam; // called with 2nd parent param as 1st param
>     }
> }

Something that happen quite frequently is duplicating very similar blocks of assembly between x86 32-bit and 64-bit. However in almost all cases the differences are small and if "version" blocks would be accepted, it would be enough.

>> On Sunday, 12 November 2017 at 22:20:46 UTC, Dibyendu Majumdar
>>
>> no in naked mode you have to save and restore by hand.

Note that in Win64 even if not naked, you'll have to save/restore some registers like XMMx with x >= 6.

>
> Another question - how can I tell DMD to no generate the frame pointer?

    naked;


However with naked; you have the problem of respecting the various ABI out there.

On Sunday, 12 November 2017 at 22:40:06 UTC, Dibyendu Majumdar wrote:
>>> On Sunday, 12 November 2017 at 22:00:58 UTC, Basile B. wrote:
>> no in naked mode you have to save and restore by hand.
>
> So how does one manually generate the .pdata and .xdata sections?
> Are you saying that this is what I would need to do?
>
> Another question - how can I tell DMD to no generate the frame pointer?
>

Hi, any further info on this? I am not talking here of the assembly push/pop instructions, rather the .pdata and .xdata sections needed on Win64.

Thanks and Regards
Dibyendu

On Monday, 13 November 2017 at 18:40:42 UTC, Basile B. wrote:

> TBH I wonder if this is not worth a enhancement (or even a DIP)
> to have in asm blocks a special alias syntax...
>
> {
>     asm
>     {
>         version(...)
>         {
>            alias First = RDI;
>            alias Second = RSI;
>            // ...
>         }
>         else
>         {
>            alias First = RCX;
>            alias Second = RDX;
>         }
>         mov First, Second;
>         call aFunctionWithOneParam; // called with 2nd parent param as 1st param
>     }
> }
>
> since the whole mixin solution make the custom asm unreadable just because of this problem.
>

Hi, that would be nice but I won't be holding my breath for such a feature to appear. I have a simple solution - I will just run it past a C pre-processor or maybe a custom one.

Regards
Dibyendu