On 7/5/25 1:06 AM, confuzzled wrote:
ulong rdtsc() {
ulong result;
uint* res = cast(uint*) &result;
asm {
rdtsc; // Puts result in edx:eax
// Cast our ulong's address to a 32-bit integer pointer
// and move the register values into the corre
Good day all,
What is the proper way to assign to accomplish this?
ulong rdtsc() {
ulong result;
uint* res = cast(uint*) &result;
asm {
rdtsc; // Puts result in edx:eax
// Cast our ulong's address to a 32-bit integer pointer
// and move the regist
’. :-)
The idea would be that the user could run this to sanity-check
her understanding of the sometimes arcane GDC asm code
outputs/inputs/clobbers syntax, and see what her asm code’s
constraints are actually going to do rather than what she
thinks it’s going to do. Clearly I can’t readily start
-check
her understanding of the sometimes arcane GDC asm code
outputs/inputs/clobbers syntax, and see what her asm code’s
constraints are actually going to do rather than what she thinks
it’s going to do. Clearly I can’t readily start parsing the asm
body itself, I would just inspect the meta info
On 1/29/23 14:19, max haughton wrote:
> it is not trivial to find where the *end* of a
> function is
I suspected as much and did run ...
> objdump
... to fool myself into thinking that 0xc3 was . Well, arguments
e.g. pointer values can have 0xc3 bytes in them. So, yes, I am fooled! :)
Ali
pointers
cannot be dereferenced. What do?
Furthermore, I would like to be able to do the same for an
`asm` statement.
The function pointer can be casted to a pointer type. It is worth
saying, however, that it is not trivial to find where the *end*
of a function is. In X86 it's not even t
n; true; ++p) {
writefln!" %02x"(*p);
if (*p == end) {
break;
}
}
}
(It can be written more elegantly as a range expression.)
> Furthermore, I would like to be able to do the same for an `asm`
statement.
I don't know how to get the address of asm blocks.
Ali
o be able to do the same for an `asm`
statement.
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote:
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote:
As for now, I know no compiler that can do that.
GCC can do it. Somewhat notoriously, LTO can lead to bugs from
underspecified asm constraints following cross-TU
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote:
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote:
As for now, I know no compiler that can do that.
GCC can do it. Somewhat notoriously,
you meant "infamously" ?
LTO can lead to bugs from underspe
On Friday, 12 November 2021 at 15:10:19 UTC, max haughton wrote:
Not always. The attribute is intended for naked asm since
inlining could be completely wrong in this case.
Got that! Thanks for the info!
On Friday, 12 November 2021 at 11:32:16 UTC, rempas wrote:
On Thursday, 11 November 2021 at 19:22:33 UTC, max haughton
wrote:
There's an attribute to tell it the function is safe to inline.
And can't you do that with inline asm?
Not always. The attribute is intended for naked
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote:
GCC can do it. Somewhat notoriously, LTO can lead to bugs from
underspecified asm constraints following cross-TU inlining.
That's really interesting to hear! Do we have any cases where
this happened to software that was use
On Thursday, 11 November 2021 at 19:22:33 UTC, max haughton wrote:
There's an attribute to tell it the function is safe to inline.
And can't you do that with inline asm?
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote:
As for now, I know no compiler that can do that.
GCC can do it. Somewhat notoriously, LTO can lead to bugs from
underspecified asm constraints following cross-TU inlining.
On Thursday, 11 November 2021 at 17:29:33 UTC, rempas wrote:
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote:
Yes, this is still the case. A particularity of DMD inliner is
that it does its job in the front-end, so inlining asm is
totally impossible. Then, even if inlining was
On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote:
Yes, this is still the case. A particularity of DMD inliner is
that it does its job in the front-end, so inlining asm is
totally impossible. Then, even if inlining was done in the
backend inlining of asm would not be guaranteed
On Thursday, 11 November 2021 at 12:05:14 UTC, Adam D Ruppe wrote:
You really shouldn't expect dmd to inline *anything*.
Or to optimize anything for that matter. That isn't its
strength.
Oh yeah! I just thought to ask anyway! Thanks a lot for your time!
case. A particularity of DMD inliner is
that it does its job in the front-end, so inlining asm is totally
impossible. Then, even if inlining was done in the backend
inlining of asm would not be guaranteed because the byte code is
generated at a very late stag, which causes problem with the
reg
On Thursday, 11 November 2021 at 08:58:43 UTC, rempas wrote:
I've seen from
[this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case?
You really shouldn't expect dm
I've seen from
[this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case?
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
You know that asm is to be avoided whenever possible, but
unfortunately, AFAIK intel-intrinsics doesn't fit the usual
'don't worry, simply compile all your code with an appropriate
-mattr/-mcpu option' recommend
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
Compiling with `-O -mtriple=i686-linux-gnu -mcpu=i686` (=> no
SSE2 by default) shows that the inlined version inside
`wrapper()` is the mega slow one, so the extra instructions
aren't applied transitively unfortunately.
Erm sorry should ha
On Monday, 19 July 2021 at 16:44:35 UTC, Guillaume Piolat wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn&#
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn't follow
consistent VEX encoding compared to normal compiler o
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'd be 'they'? GCC breaking
their syntax is IMO unimaginabl
On Monday, 19 July 2021 at 11:39:02 UTC, Basile B. wrote:
And what about the `extern(C)` issue ? Does it make sense to be
used when the parameters are int4 ?
The original inline asm was buggy and only 'worked' by accident
(not using the 2nd input operand at all...) with extern(D)
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'
, which is passed
as operand **$1**
$0 is actually the output operand, $1 is `a`, and $2 is `b`.
[...]
Note: inline asm syntax and resulting asm in AT&T syntax, *not*
Intel syntax.
yeah thnaks for the precision, I totally forgot about that.
And what about the `extern(C)` issue ? Does it ma
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember Johan
saying they will break compatibilty in the near future...
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
```
int4 _mm_add_int4(int4 a, int4 b)
{
int4 r;
asm { "paddd %1, %2; movdqa %2, %0" : "=x" (r) : "x" (a),
"x" (b); }
return r;
}
```
This wo
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
OK that's what I feared. It's very easy to get that wrong.
Thankfully I haven't used __asm a lot.
the output operand, $1 is `a`, and $2 is `b`.
The official docs are here, but IMO not very user-friendly:
https://llvm.org/docs/LangRef.html#inline-assembler-expressions
I recommend using GDC/GCC inline asm instead, where you'll find
more examples. For the given paddd example, I'd have
On Sunday, 18 July 2021 at 18:48:47 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat
wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when in
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when inline and optimized.
Registers are spilled to stack.
A minor concern is what happens when the enclosing function is
e
On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when inline and optimized.
Registers are spilled to stack.
A mino
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
Yeah I can confirm it's aweful. Took me hours to understand how
to use it a bit (my PL has [an
interface](https://styx-lang.gitlab.io/styx/primary_expressions.html#asmexpression) for LLVM asm)
You need to add a "x" to
On Sunday, 18 July 2021 at 11:42:24 UTC, Guillaume Piolat wrote:
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4(&q
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4("paddd $1,$0","=x,x",a, b);
If you know
absence of
something doesn’t hit you in the eye as an expression of the
programmer’s intent I suppose, absence of pure just could mean
the author forgot to put it in. I see your point though. The
value of volatile I saw as in documentation.
When the baseline for asm is volatile, I don't
expression of the
programmer’s intent I suppose, absence of pure just could mean
the author forgot to put it in. I see your point though. The
value of volatile I saw as in documentation.
When the baseline for asm is volatile, I don't think it's
entirely surprising to consider pure as a cance
On Thursday, 30 July 2020 at 07:05:39 UTC, Iain Buclaw wrote:
On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
I read recently that all asm in D is regarded as ‘volatile’ in
the GCC sense, which I take to mean that it is assume to
potentially have side effects, and so cannot be
On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
I read recently that all asm in D is regarded as ‘volatile’ in
the GCC sense, which I take to mean that it is assume to
potentially have side effects, and so cannot be optimised away
to nothing by the compiler despite the lack of any
On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote:
What do others think? If others agree, how could a very small
DIP be set in motion ?
Hello,
LDC lets you do optimizable assembly with ldc.llvmasm.__asm
Better yet, you can also create IR directly with
ldc.llvmasm.__ir_pure
This w
I read recently that all asm in D is regarded as ‘volatile’ in
the GCC sense, which I take to mean that it is assume to
potentially have side effects, and so cannot be optimised away to
nothing by the compiler despite the lack of any outputs.
I would like to be able to either use the asm
i need ASM or is there a easy way to implement it ?
Easiest way is to use GFM's[1] 128bit integers.
[1]:http://code.dlang.org/packages/gfm
i need ASM or is there a easy way to implement it ?
https://forum.dlang.org/post/[email protected]
I want to translate this c code into d (build with ldc), so I can
use -flto and inline with other code.
uint64_t _wymum(uint64_t A, uint64_t B){
__uint128_t r = A ;
r *= B;
return (r>>64)^r;
}
Do i need ASM or is there a easy way to implement it ?
On Tuesday, 18 June 2019 at 17:10:50 UTC, Adam D. Ruppe wrote:
On Tuesday, 18 June 2019 at 17:09:48 UTC, Adam D. Ruppe wrote:
pop EAX;
errr you can see my 32 bit bias here (forgive me, I'm old), but
you know what i mean :)
Thank you, quite clever.
There is also the "$" symbol that is relate
On Tuesday, 18 June 2019 at 17:09:48 UTC, Adam D. Ruppe wrote:
pop EAX;
errr you can see my 32 bit bias here (forgive me, I'm old), but
you know what i mean :)
On Tuesday, 18 June 2019 at 16:56:18 UTC, Stefanos Baziotis wrote:
I can't do for example:
lea RAX, [RIP+something];
Generally, RIP does not seem to be available.
The general trick in x86 assembly for this is
call next;
next:
pop EAX;
The call instruction pushes RIP to the stack (for a fut
I can't do for example:
lea RAX, [RIP+something];
Generally, RIP does not seem to be available.
igh`.
struct Result {
ulong low;
ulong high;
}
Result unsignedMultiply(ulong x, ulong y) {
version(D_InlineAsm_X86_64) asm {
naked;
mov RAX, R8;
mul RDX;
mov qword ptr [RCX], RAX;
mov qword ptr [RCX +
(Result* result) {
version(D_InlineAsm_X86_64) asm {
naked;
mov [RAX + 0], 0x80;
mov [RAX + 8], 0xff;
ret;
}
}
do so
online via run.dlang.io (https://run.dlang.io/is/rhsDBF); just
select LDC and add `-mtriple=x86_64-pc-windows-msvc` to
generate Win64 assembly.
Note that run.dlang.io displays AT&T-style asm, not the Intel
one. You can use LDC offline via `-output-s
-x86-asm-syntax=intel` to generate
ger return values work. The
obvious answer of "RAX or EAX contains a pointer" is either not
working or my asm is wrong. (The latter is certainly a
possibility.)
The MS docs are complete IIRC. The pointer to the pre-allocated
result of your 16-bytes struct is passed in RCX.
If unsure, j
how return values of 8 bytes and fewer work, but
haven't explained how larger return values work. The obvious
answer of "RAX or EAX contains a pointer" is either not working
or my asm is wrong. (The latter is certainly a possibility.)
// Returns 128 (0x80)
ulong re
On Thursday, 15 November 2018 at 21:07:51 UTC, pineapple wrote:
Is there a way to access this pointer?
It is passed as.. I think the final argument to the function.
(unless it is the first, do a quick test to find out).
Also, the calling convention documentation there doesn't
mention anythi
On Thursday, 15 November 2018 at 21:00:10 UTC, Adam D. Ruppe
wrote:
It would be part of the abi:
https://dlang.org/spec/abi.html#function_calling_conventions
though it references C so you might need to look that up too.
That's helpful, thank you!
For other sized structs and static arrays, the
On Thursday, 15 November 2018 at 20:57:59 UTC, pineapple wrote:
My issue is that I can't figure out how to access a function's
arguments from within inline asm or how to ensure that the
correct value is returned. I haven't found a single piece of
documentation about this so far
I've managed to get a few functions working before mostly by
copying whatever Phobos was doing for a similar purpose, but now
that I'm trying to do something different I am really hitting a
wall.
My issue is that I can't figure out how to access a function's
arguments fr
On Monday, 1 October 2018 at 10:45:25 UTC, Basile B. wrote:
On Monday, 1 October 2018 at 09:24:47 UTC, Basile B. wrote:
On Monday, 1 October 2018 at 08:14:07 UTC, dokutoku wrote:
I get a compiler error when I try to put non-ASCII characters
in a string literal in the inline assembler.
Is this
On Monday, 1 October 2018 at 09:24:47 UTC, Basile B. wrote:
On Monday, 1 October 2018 at 08:14:07 UTC, dokutoku wrote:
I get a compiler error when I try to put non-ASCII characters
in a string literal in the inline assembler.
Is this part of the specifications?
It's not clear, see https://dl
On Monday, 1 October 2018 at 08:14:07 UTC, dokutoku wrote:
I get a compiler error when I try to put non-ASCII characters
in a string literal in the inline assembler.
Is this part of the specifications?
It's not clear, see https://dlang.org/spec/iasm.html#raw_data:
"if an operand is a string
I get a compiler error when I try to put non-ASCII characters in
a string literal in the inline assembler.
Is this part of the specifications?
On Sunday, 30 September 2018 at 12:32:08 UTC, kinke wrote:
1) `asm {}` is supported by DMD and LDC, but not by GDC.
Good to know.
Guess I will be targeting DMD and LDC then.
4) For x86_64, there are 2 (completely different) ABIs, Win64
and the System V one. Specs can be found online.
In
, ref
MyStruct s3, ref MyStruct s4)
{
asm
{
naked;
mov RCX, MyStruct.i.offsetof[RCX];
mov RDX, MyStruct.i.offsetof[RDX];
mov RSI, MyStruct.i.offsetof[RSI];
mov RDI, MyStruct.i.offsetof[RDI];
callwrite4Int;
On Sunday, 30 September 2018 at 10:46:33 UTC, Sjoerd Nijboer
wrote:
I'm kinda puzzled.
I'm having trouble getting started with inline asm in D.
Suppowse I have the following:
void Foo(MyStrunct* first_arg, MyStrunct* second_arg)
{
asm
{
naked;
v
disassembler.
After playing a bit:
Without all the save/restore BS:
module runnable;
import std.stdio;
alias write4Int = writeln!(int,int,int,int);
struct MyStruct{int i;}
extern(D) void foo(ref MyStruct s1, ref MyStruct s2, ref MyStruct
s3, ref MyStruct s4)
{
asm
{
naked
On Sunday, 30 September 2018 at 10:46:33 UTC, Sjoerd Nijboer
wrote:
I'm kinda puzzled.
I'm having trouble getting started with inline asm in D.
Suppowse I have the following:
void Foo(MyStrunct* first_arg, MyStrunct* second_arg)
{
asm
{
naked;
v
I'm kinda puzzled.
I'm having trouble getting started with inline asm in D.
Suppowse I have the following:
void Foo(MyStrunct* first_arg, MyStrunct* second_arg)
{
asm
{
naked;
version(X86)
{
/* Do something with the content
Okay, cool, thanks for the information. The main reason for
using D versus Java for me at the moment is that array slices
allow me avoid lots of intermediate buffers that Java is forcing
me to use.
Also the line count is about 2/3 of Java. Further I can directly
embed any assembly language I n
stdio;
// Linux AMD64
float* test(float *x,ulong y){
asm{
naked;
align 16;
mov RAX,RDI;
ret;
}
}
void main(){
float[] f=new float[16];
writeln(&f[0]);
float* a=test(&f[0],7);
writeln(
On Saturday, 18 August 2018 at 04:16:11 UTC, Sean O'Connor wrote:
What calling convention is used for assembly language in Linux
AMD64?
Normally the parameters go in fixed order into designated
registers.
import std.stdio;
// Linux AMD64
float* test(float *x,ulong y){
What calling convention is used for assembly language in Linux
AMD64?
Normally the parameters go in fixed order into designated
registers.
import std.stdio;
// Linux AMD64
float* test(float *x,ulong y){
asm{
naked;
align 16;
mov RAX,RDI
) and states that it matches the C calling convention on
all other platforms [but note that the args are actually
reversed].
Is the inline asm portable between compilers?
LDC supports the DMD-style inline asm too, GDC doesn't.
Thanks!
all other platforms [but note that the args are actually
reversed].
Is the inline asm portable between compilers?
LDC supports the DMD-style inline asm too, GDC doesn't.
Given this...
int mulDiv64(int a, int b, int c)
{
asm
{
movEAX,a;
imul b;
idiv c;
}
}
which computes a*b/c, with the intermediate value in 64 bit. It
returns value that is left in EAX.
Is this stuff documented somewhere? I mean I found the page on
On Sunday, 5 November 2017 at 14:25:24 UTC, user1234 wrote:
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote:
[...]
Hmmm it was just the amount of nops.
---
import std.stdio;
alias Proc = size_t function();
size_t allInnOne()
{
asm pure nothrow
{
naked
On Sunday, 5 November 2017 at 14:27:18 UTC, Eugene Wissner wrote:
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote:
[...]
One of the problems is that "naked" is missing in your
assembly. If you write
asm pure nothrow
{
naked;
mov RAX, 1;
ret;
nop;n
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote:
[...]
Hmmm it was just the amount of nops.
---
import std.stdio;
alias Proc = size_t function();
size_t allInnOne()
{
asm pure nothrow
{
naked;
mov RAX, 1;
ret;
nop;nop;
mov RAX, 2
On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote:
Hello, try this:
---
import std.stdio;
alias Proc = size_t function();
size_t allInnOne()
{
asm pure nothrow
{
mov RAX, 1;
ret;
nop;nop;nop;nop;nop;nop;nop;
mov RAX, 2;
ret
Hello, try this:
---
import std.stdio;
alias Proc = size_t function();
size_t allInnOne()
{
asm pure nothrow
{
mov RAX, 1;
ret;
nop;nop;nop;nop;nop;nop;nop;
mov RAX, 2;
ret;
}
}
void main()
{
Proc proc1 = &allInnOne;
Proc p
On Saturday, 16 July 2016 at 21:16:29 UTC, Andrew Godfrey wrote:
COM is a model; in practice people pick the parts they need,
and often still call it "COM".
No need to rename what has a name:
https://en.wikipedia.org/wiki/Interface-based_programming
On Saturday, 16 July 2016 at 20:31:25 UTC, Adam Sansier wrote:
Yet you are wrong. Regardless what the asio standard does right
or wrong, it uses COM, correct? Is asio not well established?
Yes it is. Hence it proves that not all COM is as you think it
is.
The component must comply with the CO
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote:
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
Um, no, I revived it so that people searching for answers
wouldn't be led astray by idiots who pretend to know
everything.
My word is not COM specification of course, ther
On Thursday, 14 July 2016 at 00:51:16 UTC, ethgeh wrote:
On Wednesday, 13 July 2016 at 23:06:44 UTC, flamencofantasy
wrote:
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy
wrote:
On Wednesday, 13 July 2016 at 20:39:00 U
On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote:
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
Um, no, I revived it so that people searching for answers
wouldn't be led astray by idiots who pretend to know
everything.
My word is not COM specification of course, ther
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
Um, no, I revived it so that people searching for answers
wouldn't be led astray by idiots who pretend to know everything.
My word is not COM specification of course, there's the official
documentation and tons of books about COM,
On Wednesday, 13 July 2016 at 23:06:44 UTC, flamencofantasy wrote:
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy
wrote:
On Wednesday, 13 July 2016 at 20:39:00 UTC, Adam Sansier
wrote:
[...]
You revived this thread
On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy
wrote:
On Wednesday, 13 July 2016 at 20:39:00 UTC, Adam Sansier wrote:
On Sunday, 24 April 2011 at 22:09:24 UTC, Kagamin wrote:
Andrej Mitrovic Wrote:
But trying to use
On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy wrote:
On Wednesday, 13 July 2016 at 20:39:00 UTC, Adam Sansier wrote:
On Sunday, 24 April 2011 at 22:09:24 UTC, Kagamin wrote:
Andrej Mitrovic Wrote:
But trying to use functions which take parameters will fail
with an access violati
On Wednesday, 13 July 2016 at 20:39:00 UTC, Adam Sansier wrote:
On Sunday, 24 April 2011 at 22:09:24 UTC, Kagamin wrote:
Andrej Mitrovic Wrote:
But trying to use functions which take parameters will fail
with an access violation, probably because D uses stdcall for
COM methods, while these AS
On Sunday, 24 April 2011 at 22:09:24 UTC, Kagamin wrote:
Andrej Mitrovic Wrote:
But trying to use functions which take parameters will fail
with an access violation, probably because D uses stdcall for
COM methods, while these ASIO COM methods need to be called
with 'thiscall' convention.
C
On Tuesday, 31 May 2016 at 18:52:16 UTC, Marco Leise wrote:
The 'this' pointer is usually in some register already. On
Linux 32-bit for example it is in EAX, on Linux 64-bit is in
RDI.
The AX register seems like a bad choice, since you require the
AX/DX registers when you do multiplication a
Am Fri, 27 May 2016 10:16:48 +
schrieb Era Scarecrow :
> On Friday, 27 May 2016 at 10:14:31 UTC, Era Scarecrow wrote:
> > inc dword ptr [EAX+Foo.x.offsetof];
>
>
> So just tested it, and it didn't hang, meaning all unittests
> also passed.
>
> Fin
relative access of parameters and
stack variables works by copying everything to the stack
that's in registers when you have an asm block in the
function. Using var[EBP] or just plain var will then
dereference that memory location.
--
Marco
On Saturday, 28 May 2016 at 10:10:19 UTC, ZombineDev wrote:
The great thing about D's UFCS is that it allows exactly that:
Also, you can implement inc() in terms of ulong[2] - void
inc(ref ulong[2] w), which makes it applicable for other types,
with the same memory representation. E.g. cent
thing like this!
//contains plain portable version
struct base {}
version(X86) {
struct inherited : base {
//only adds or replaces functions, no data changes
//all asm injection is known to be 32bit x86
}
}
version(X86_64) {
...
}
Truthfully going with my ex
1 - 100 of 206 matches
Mail list logo
