On Sunday, 17 July 2016 at 06:23:34 UTC, Walter Bright wrote:
On 7/16/2016 11:10 PM, Adam Sansier wrote:
D is not consistent with C++ in asm and calling convention.
In general, it is a *lot* easier to debug inline asm issues if
you're willing to run obj2asm on the output and compare. No
need
On Sunday, 17 July 2016 at 06:27:46 UTC, Adam Sansier wrote:
On Sunday, 17 July 2016 at 06:23:34 UTC, Walter Bright wrote:
On 7/16/2016 11:10 PM, Adam Sansier wrote:
D is not consistent with C++ in asm and calling convention.
In general, it is a *lot* easier to debug inline asm issues if
you
On Sunday, 17 July 2016 at 06:23:34 UTC, Walter Bright wrote:
On 7/16/2016 11:10 PM, Adam Sansier wrote:
D is not consistent with C++ in asm and calling convention.
In general, it is a *lot* easier to debug inline asm issues if
you're willing to run obj2asm on the output and compare. No
need
I should point out that the code still doesn't work. It simply
doesn't crash. It seems to jump to another code location that
fails silently. I might not be fixing up the stack frame
correctly or or doing something D expects. Hard to no because
when I try to step over the `call` instruction it e
2. C++ defaults to dword ptr, D to word ptr. Copying and
pasting the code results in hard to find bugs.
It would seem to me that that D should default to the pointer
size for indirect accessing when pushing and popping.
push [3]
should push a size of void*.sizeof.
D is not consistent with C++ in asm and calling convention.
I have the exact same code in both C++ and D, the exact same
assembler code, but.
D's
enum VS = (void*).sizeof;
enum SA = 6;
enum OF = 0;
void createBuffers
I am trying to debug some really messed up code that makes no
sense. It calls in some code that doesn't seem to be using the
standard calling convention. The function definitions are exactly
the same in both D and C++.
->func(param1, param2, param3, param4);
The call stack setup by C++ before
Hi,
I have designed a class based system that involves
self-delegation instead of override.
It is similar to event based programming.
I have defined an event as a container type that holds
functions(or possibly delegates, but the desire is to avoid them).
class Base
{
alias EventMetho