www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: narrowed down the problem area

reply K.Wilson <phizzzt yahoo.com> writes:
I just finished initial support for x86-64 output with the ldc compiler (dmdfe
attached to llvm backend) and wanted to do some timings, so I used the ray
tracing code mentioned in this old thread. I compiled things with the same
optimization flags mentioned in the thread and came up with these averages over
6 runs on an AMD x86-64 machine running Fedora Core Linux.

llvm-g++4.0.1   5.76
ldc-rev736      6.68
g++4.1.2        6.72
gdc0.24         7.45
g++4.3.1        7.66
dmd1.030        14.52

Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).

I just thought I would let people know that ldc is coming along and performs
quite well, at this point. And it has some x86-64 support now ;)

Thanks,
K.Wilson


bearophile Wrote:


 Sergey Gromov:

 D program is refactored so that all struct manipulations happen in-place, 
 without passing and returning by value.  GDC has troubles inlining 
 static opCalls for some reason.



 Yep, you seem to have re-invented a fixed-size version of my TinyVector (I
have added static opCalls yesterday, but I may have to remove them again).
 
 

 Microsoft's compiler produces FP/math code about 25% shorter than 
 GCC/GDC in average



 Nice.
 Thank you for your experiments.
 
 Timings of your code (that has a bug, see downs for a fixed version) on Win,
Pentium3, best of 3 runs, image 256x256:
 
 D DMD v.1.025:
 bud -clean -O -release -inline rayD.d
 15.8 seconds (memory deallocation too)
 
 C++ MinGW based on GCC 4.2.1:
 g++ -O3 -s rayCpp.cpp -o rayCpp0
 9.42 s (memory deallocation too)
 
 C++ MinGW (the same):
 g++ -pipe -O3 -s -ffast-math -fomit-frame-pointer rayCpp.cpp -o rayCpp1
 8.89 s (memory deallocation too)
 
 C++ MinGW (the same):
 g++ -pipe -O3 -s -ffast-math -fomit-frame-pointer -fprofile-generate
rayCpp.cpp -o rayCpp2
 g++ -pipe -O3 -s -ffast-math -fomit-frame-pointer -fprofile-use rayCpp.cpp -o
rayCpp2
 8.72 s (memory deallocation too)
 
 I haven't tried GDC yet.
 
 Bye,
 bearophile
Oct 27 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 28, 2008 at 2:26 PM, K.Wilson <phizzzt yahoo.com> wrote:

 I just finished initial support for x86-64 output with the ldc compiler (dmdfe
attached to llvm backend) and wanted to do some timings, so I used the ray
tracing code mentioned in this old thread. I compiled things with the same
optimization flags mentioned in the thread and came up with these averages over
6 runs on an AMD x86-64 machine running Fedora Core Linux.

 llvm-g++4.0.1   5.76
 ldc-rev736      6.68
 g++4.1.2        6.72
 gdc0.24         7.45
 g++4.3.1        7.66
 dmd1.030        14.52

 Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).

 I just thought I would let people know that ldc is coming along and performs
quite well, at this point. And it has some x86-64 support now ;)



Faaaaan Tastic!

So how is Windows support coming along?  Does it build smoothly with MinGW now?

--bb
Oct 27 2008
parent reply K.Wilson <phizzzt yahoo.com> writes:
Bill Baxter Wrote:


 On Tue, Oct 28, 2008 at 2:26 PM, K.Wilson <phizzzt yahoo.com> wrote:

 I just finished initial support for x86-64 output with the ldc compiler (dmdfe
attached to llvm backend) and wanted to do some timings, so I used the ray
tracing code mentioned in this old thread. I compiled things with the same
optimization flags mentioned in the thread and came up with these averages over
6 runs on an AMD x86-64 machine running Fedora Core Linux.

 llvm-g++4.0.1   5.76
 ldc-rev736      6.68
 g++4.1.2        6.72
 gdc0.24         7.45
 g++4.3.1        7.66
 dmd1.030        14.52

 Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).

 I just thought I would let people know that ldc is coming along and performs
quite well, at this point. And it has some x86-64 support now ;)



 Faaaaan Tastic!
 
 So how is Windows support coming along?  Does it build smoothly with MinGW now?
 
 --bb



Hey Bill,

I didn't see your question the other day...the windows support is still not up
to par for x86-64 (whether trying to build in 32 or 64 bit mode). I couldn't
get things built on my machine for Windows (but I don't have VStudio 2008,
which is suggested because MinGW64 is not production quallity yet).

I think building for MinGW on x86 is somewhat supported and
running...exceptions and inline asm still have some issues...hopefully these
issues will be resolved quickly.

Thanks,
K.Wilson
Oct 29 2008
next sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
 So how is Windows support coming along?  Does it build smoothly with
 MinGW now?
 
 --bb



 I think building for MinGW on x86-32 is somewhat supported and
 running...exceptions and inline asm still have some issues...hopefully
 these issues will be resolved quickly.

 Thanks,
 K.Wilson



Exactly. Elrood has managed to compile a working LDC on x86-32 Windows using
MinGW (he even provided binaries at one point) and since he hasn't reported
otherwise, I'd expect that its still working. LLVM-Windows in particular
was broken in LLVM trunk sometimes, but now that we're using the
2.4-release branch, it should be more stable. 

However, in order for Windows LDC to make quick progress, we'd need more
Windows people who are willing to test, debug and fix things to try the
compiler.
Oct 30 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
K.Wilson wrote:

 Bill Baxter Wrote:
 

 On Tue, Oct 28, 2008 at 2:26 PM, K.Wilson <phizzzt yahoo.com> wrote:

 I just finished initial support for x86-64 output with the ldc compiler (dmdfe
attached to llvm backend) and wanted to do some timings, so I used the ray
tracing code mentioned in this old thread. I compiled things with the same
optimization flags mentioned in the thread and came up with these averages over
6 runs on an AMD x86-64 machine running Fedora Core Linux.

 llvm-g++4.0.1   5.76
 ldc-rev736      6.68
 g++4.1.2        6.72
 gdc0.24         7.45
 g++4.3.1        7.66
 dmd1.030        14.52

 Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).

 I just thought I would let people know that ldc is coming along and performs
quite well, at this point. And it has some x86-64 support now ;)




 So how is Windows support coming along?  Does it build smoothly with MinGW now?

 --bb



 Hey Bill,
 
 I didn't see your question the other day...the windows support is still not up
to par for x86-64 (whether trying to build in 32 or 64 bit mode). I couldn't
get things built on my machine for Windows (but I don't have VStudio 2008,
which is suggested because MinGW64 is not production quallity yet).
 
 I think building for MinGW on x86 is somewhat supported and
running...exceptions and inline asm still have some issues...hopefully these
issues will be resolved quickly.
 
 Thanks,
 K.Wilson



I was trying to get LDC going on Windows x64, but it's been slow going 
with school & everything else. I submitted a path that gets it 
_compiling_ on VS (the patch is out-of-date, but it shouldn't be too 
hard to bring it up to date), but last time I checked (a couple weeks 
ago...) it would fail an assertion. It will take a lot of knowledge 
about LLVM internals to get LDC usable on this architecture+OS. Then 
there's Windows IA64...
Oct 30 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
K. Wilson:

Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).<



Very nice. On Win in 100% of my programs and benchmarks llvm-gcc 2.3 turns out
slower or quite slower than GCC 4.3.1, but the ratio is never bigger than about
2 times slower. So it's curious to see an example of the opposite.



I just thought I would let people know that ldc is coming along and performs
quite well, at this point.<



I have read it compiles all Tango tests, this is a lot, because Tango is large
and complex.

--------

The LDC docs say:


One thing the D spec isn't clear about at all is how asm blocks mixed with
normal D code (for example code between two asm blocks) interacts.<
Currently 'naked' in D is treated as a compile time error in LDC. Reason for
this is that LLVM does not support directly controlling prologue/epilogue
generation. Also the documentation from the D spec on this topic is extremely
limited and doesn't mention anything about how normal D code in a naked
function works. In particular local (stack) variables are unclear, also
accessing named parameters etc.<



I think Walter has more or less said he's interested in seeing LDC grow, so I
presume such things can be asked to him, and he can give some answers that can
help LDC a lot.

Bye,
bearophile
Oct 28 2008
parent reply Don <nospam nospam.com.au> writes:
bearophile wrote:

 K. Wilson:

 Seems like the LLVM backend is doing well (though I have seen other timings
where g++4.x beats llvm-g++4.x, so take from this what you will).<



 Very nice. On Win in 100% of my programs and benchmarks llvm-gcc 2.3 turns out
slower or quite slower than GCC 4.3.1, but the ratio is never bigger than about
2 times slower. So it's curious to see an example of the opposite.
 
 

 I just thought I would let people know that ldc is coming along and performs
quite well, at this point.<



 I have read it compiles all Tango tests, this is a lot, because Tango is large
and complex.
 
 --------
 
 The LDC docs say:
 

 One thing the D spec isn't clear about at all is how asm blocks mixed with
normal D code (for example code between two asm blocks) interacts.<
 Currently 'naked' in D is treated as a compile time error in LDC. Reason for
this is that LLVM does not support directly controlling prologue/epilogue
generation. Also the documentation from the D spec on this topic is extremely
limited and doesn't mention anything about how normal D code in a naked
function works. In particular local (stack) variables are unclear, also
accessing named parameters etc.<






I can answer this.

'naked' in DMD is quite simple: almost nothing works.

Stack variables with 'naked' don't work. Parameters don't work, either. 
Nor do contracts. Here's why:

Regardless of whether 'naked' is specified or not, the compiler creates 
code exactly as if the function began with 'push EBP; mov EBP, ESP; ' 
and ended with 'pop EBP; '
If 'naked' is specified, it just doesn't put that prologue and epilogue in.
So the only way to use 'naked' is to manually keep track of where 
everything is on the stack, and index it off the stack pointer.

Why use 'naked' at all, then?
(1) so that you can use the EBP register;
(2) because non-naked asm doesn't work properly, either. If you pass an 
array into an asm function, you can't get the ".ptr" part of it, because 
the "ptr" conflicts with the asm "ptr" keyword. This is a big problem, 
since almost all asm functions that I write work on arrays.

I don't think that this is how naked asm _should_ work, though. It 
should allow you to reference parameters without adjusting the offsets 
assuming you're using EBP. So the following should work:

void nakedfunc(uint [] dest, uint [] src)
{
   asm {
     naked;
     mov ECX, dest.ptr[ESP];
   }
}

Since the spec says:
"If the [EBP] is omitted, it is assumed for local variables. If naked is 
used, this no longer holds."
True, it doesn't put in an [EBP], but it adjusts the offset assuming 
that a stack frame has been set up. And ".ptr" doesn't work.


Curious fact:
Whenever I'm naked, my body disappears!

void fkk()
{
    asm { naked; }
}

void main() { fkk(); }

--> generates a linker error. Fair enough, really. But kind of interesting.
Oct 28 2008
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Don wrote:

 bearophile wrote:

 The LDC docs say:


 One thing the D spec isn't clear about at all is how asm blocks mixed 
 with normal D code (for example code between two asm blocks) interacts.<
 Currently 'naked' in D is treated as a compile time error in LDC. 
 Reason for this is that LLVM does not support directly controlling 
 prologue/epilogue generation. Also the documentation from the D spec 
 on this topic is extremely limited and doesn't mention anything about 
 how normal D code in a naked function works. In particular local 
 (stack) variables are unclear, also accessing named parameters etc.<






 I can answer this.



Thank you very much. This will help me a lot implementing 'naked' in LDC :)


 
 'naked' in DMD is quite simple: almost nothing works.



:P


 
 Stack variables with 'naked' don't work. Parameters don't work, either. 
 Nor do contracts. Here's why:
 
 Regardless of whether 'naked' is specified or not, the compiler creates 
 code exactly as if the function began with 'push EBP; mov EBP, ESP; ' 
 and ended with 'pop EBP; '
 If 'naked' is specified, it just doesn't put that prologue and epilogue in.
 So the only way to use 'naked' is to manually keep track of where 
 everything is on the stack, and index it off the stack pointer.
 



This actually makes things quite simple, LLVM does frame pointer elimination by
default (we 
force it to emit one when normal inline asm is used though), so this condition
should just be 
changed to 'if (asmIsUsed && !isNaked) doEBP();'
There's a few other technical issues, mostly related to LLVM using an SSA form
and function 
arguments being l-values in D, but that's not really important here...


 Why use 'naked' at all, then?
 (1) so that you can use the EBP register;
 (2) because non-naked asm doesn't work properly, either. If you pass an 
 array into an asm function, you can't get the ".ptr" part of it, because 
 the "ptr" conflicts with the asm "ptr" keyword. This is a big problem, 
 since almost all asm functions that I write work on arrays.
 



Could we work around this somehow ? Actually I'm not sure we even handle this
kind of thing 
properly yet (accessing aggregate fields in asm). I should test that :)


 I don't think that this is how naked asm _should_ work, though. It 
 should allow you to reference parameters without adjusting the offsets 
 assuming you're using EBP. So the following should work:
 
 void nakedfunc(uint [] dest, uint [] src)
 {
   asm {
     naked;
     mov ECX, dest.ptr[ESP];
   }
 }



So this should work since you've not modified ESP right? I'm not sure what
facilities LLVM 
currently has to get stack offsets of parameters before the actual native
codegen, probably 
none.. So this might be a bit difficult to implement in LDC, but again, I'm not
really aware of 
all that LLVM's inline asm can really do, since there is basically no
documentation, and we've 
only read so much of their source code :P


 
 Since the spec says:
 "If the [EBP] is omitted, it is assumed for local variables. If naked is 
 used, this no longer holds."
 True, it doesn't put in an [EBP], but it adjusts the offset assuming 
 that a stack frame has been set up. And ".ptr" doesn't work.
 



This .ptr issue certainly seems like something that should be fixed somehow :)


 
 Curious fact:
 Whenever I'm naked, my body disappears!
 
 void fkk()
 {
    asm { naked; }
 }
 
 void main() { fkk(); }
 
 --> generates a linker error. Fair enough, really. But kind of interesting.



This will not happen in LDC, it will just produce what it does without the
naked:

_D3bar3fooFZv:
                 ret

Again thanx for these explanations.
Maybe we'll have 'naked' soon in LDC after all :)

-Tomas
Oct 28 2008
parent Don <nospam nospam.com.au> writes:
Tomas Lindquist Olsen wrote:

 Don wrote:

 bearophile wrote:

 The LDC docs say:


 One thing the D spec isn't clear about at all is how asm blocks 
 mixed with normal D code (for example code between two asm blocks) 
 interacts.<
 Currently 'naked' in D is treated as a compile time error in LDC. 
 Reason for this is that LLVM does not support directly controlling 
 prologue/epilogue generation. Also the documentation from the D spec 
 on this topic is extremely limited and doesn't mention anything 
 about how normal D code in a naked function works. In particular 
 local (stack) variables are unclear, also accessing named parameters 
 etc.<






 I can answer this.



 Thank you very much. This will help me a lot implementing 'naked' in LDC :)
 

 'naked' in DMD is quite simple: almost nothing works.



 :P
 

 Stack variables with 'naked' don't work. Parameters don't work, 
 either. Nor do contracts. Here's why:

 Regardless of whether 'naked' is specified or not, the compiler 
 creates code exactly as if the function began with 'push EBP; mov EBP, 
 ESP; ' and ended with 'pop EBP; '
 If 'naked' is specified, it just doesn't put that prologue and 
 epilogue in.
 So the only way to use 'naked' is to manually keep track of where 
 everything is on the stack, and index it off the stack pointer.



 This actually makes things quite simple, LLVM does frame pointer 
 elimination by default (we force it to emit one when normal inline asm 
 is used though), so this condition should just be changed to 'if 
 (asmIsUsed && !isNaked) doEBP();'
 There's a few other technical issues, mostly related to LLVM using an 
 SSA form and function arguments being l-values in D, but that's not 
 really important here...
 

 Why use 'naked' at all, then?
 (1) so that you can use the EBP register;
 (2) because non-naked asm doesn't work properly, either. If you pass 
 an array into an asm function, you can't get the ".ptr" part of it, 
 because the "ptr" conflicts with the asm "ptr" keyword. This is a big 
 problem, since almost all asm functions that I write work on arrays.



 Could we work around this somehow ? Actually I'm not sure we even handle 
 this kind of thing properly yet (accessing aggregate fields in asm). I 
 should test that :)
 

 I don't think that this is how naked asm _should_ work, though. It 
 should allow you to reference parameters without adjusting the offsets 
 assuming you're using EBP. So the following should work:

 void nakedfunc(uint [] dest, uint [] src)
 {
   asm {
     naked;
     mov ECX, dest.ptr[ESP];
     ret 4*4;
   }
 }



 So this should work since you've not modified ESP right? 



Yes, it's your responsibility to make sure that ESP points to first 
parameter on the stack.

I'm not sure

 what facilities LLVM currently has to get stack offsets of parameters 
 before the actual native codegen, probably none.. So this might be a bit 
 difficult to implement in LDC, but again, I'm not really aware of all 
 that LLVM's inline asm can really do, since there is basically no 
 documentation, and we've only read so much of their source code :P



If it is only mov ECX, [ESP]param, then you can translate it to mov ECX, 
param.
In fact, it would be even better if you could write mov ECX, param.
If DMD would keep track of the number of pushes and pops that occured, 
it could do this too.

Here's the kind of nonsense I'm doing at the moment. I create a constant 
'LASTPARAM' which is the offset to the last parameter.
The compiler should really be helping with this. But at least it works...

void foo(uint [] dest, uint[] left, uint [] right)
{
     enum { LASTPARAM = 6*4 } // 4* pushes + local + return address.
     asm {
         naked;

         push ESI;
         push EDI;
         push EBX;
         push EBP;
         push EAX;    // local variable M
         mov EDI, [ESP + LASTPARAM + 4*5]; // dest.ptr
         mov EBX, [ESP + LASTPARAM + 4*2]; // left.length
         mov ESI, [ESP + LASTPARAM + 4*3];  // left.ptr
...
         mul int ptr [ESP]; // M
...
         pop EAX; // get rid of M
         pop EBP;
         pop EBX;
         pop EDI;
         pop ESI;
         ret 6*4;
    }
}





 

 Since the spec says:
 "If the [EBP] is omitted, it is assumed for local variables. If naked 
 is used, this no longer holds."
 True, it doesn't put in an [EBP], but it adjusts the offset assuming 
 that a stack frame has been set up. And ".ptr" doesn't work.



 This .ptr issue certainly seems like something that should be fixed 
 somehow :)
 

 Curious fact:
 Whenever I'm naked, my body disappears!

 void fkk()
 {
    asm { naked; }
 }

 void main() { fkk(); }

 --> generates a linker error. Fair enough, really. But kind of 
 interesting.



 This will not happen in LDC, it will just produce what it does without 
 the naked:
 
 _D3bar3fooFZv:
                 ret
 
 Again thanx for these explanations.
 Maybe we'll have 'naked' soon in LDC after all :)
 
 -Tomas
Oct 29 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Why use 'naked' at all, then?
 (1) so that you can use the EBP register;
 (2) because non-naked asm doesn't work properly, either. If you pass an 
 array into an asm function, you can't get the ".ptr" part of it, because 
 the "ptr" conflicts with the asm "ptr" keyword. This is a big problem, 
 since almost all asm functions that I write work on arrays.



(3) you want to write the entire function in assembler.
Oct 28 2008
parent reply Don <nospam nospam.com.au> writes:
Walter Bright wrote:

 Don wrote:

 Why use 'naked' at all, then?
 (1) so that you can use the EBP register;
 (2) because non-naked asm doesn't work properly, either. If you pass 
 an array into an asm function, you can't get the ".ptr" part of it, 
 because the "ptr" conflicts with the asm "ptr" keyword. This is a big 
 problem, since almost all asm functions that I write work on arrays.



 (3) you want to write the entire function in assembler.



I think it probably should be illegal to include any non-asm code in a 
function containing naked asm. It would certainly make the spec simpler!
In fact, I don't see how any other approach is really possible.
Oct 29 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Don wrote:

 Walter Bright wrote:

 Don wrote:

 Why use 'naked' at all, then?
 (1) so that you can use the EBP register;
 (2) because non-naked asm doesn't work properly, either. If you pass 
 an array into an asm function, you can't get the ".ptr" part of it, 
 because the "ptr" conflicts with the asm "ptr" keyword. This is a big 
 problem, since almost all asm functions that I write work on arrays.



 (3) you want to write the entire function in assembler.



 I think it probably should be illegal to include any non-asm code in a 
 function containing naked asm. It would certainly make the spec simpler!
 In fact, I don't see how any other approach is really possible.



Seems sensible to me. Walter, why is normal code even allowed ?
Oct 29 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 Don wrote:

 Walter Bright wrote:

 (3) you want to write the entire function in assembler.



 I think it probably should be illegal to include any non-asm code in a 
 function containing naked asm. It would certainly make the spec simpler!
 In fact, I don't see how any other approach is really possible.



 Seems sensible to me. Walter, why is normal code even allowed ?



You might want to build your own adjuster thunks.
Oct 30 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 Seems sensible to me. Walter, why is normal code even allowed ?



I should add that 'naked' is for people who don't mind getting intimate 
with how the compiler arranges things. Any code using it should expect 
it to not be portable, and be past the compiler wagging its finger at them.
Oct 30 2008
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Walter Bright wrote:

 I should add that 'naked' is for people who don't mind getting intimate
 with how the compiler arranges things. Any code using it should expect
 it to not be portable, and be past the compiler wagging its finger at
 them.



Here portable means 'portable between different compilers for the same
architecture'? 

I'm wondering because I thought the point of specifying inline assembler was
exactly to guarantee that kind of portability. So you would not consider a
compiler that does not implement naked, or handles it differently from DMD
to be breaking the D specification?
Oct 30 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christian Kamm wrote:

 Walter Bright wrote:

 I should add that 'naked' is for people who don't mind getting intimate
 with how the compiler arranges things. Any code using it should expect
 it to not be portable, and be past the compiler wagging its finger at
 them.



 Here portable means 'portable between different compilers for the same
 architecture'? 
 
 I'm wondering because I thought the point of specifying inline assembler was
 exactly to guarantee that kind of portability. So you would not consider a
 compiler that does not implement naked, or handles it differently from DMD
 to be breaking the D specification?



Since the stack prolog/epilog is not defined in the D ABI, a compiler is 
free to innovate in this area.

The reason to specify the inline assembler is to have a common ground on 
the assembler syntax.
Oct 30 2008
next sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
 Walter Bright wrote:
 I should add that 'naked' is for people who don't mind getting intimate
 with how the compiler arranges things. Any code using it should expect
 it to not be portable, and be past the compiler wagging its finger at
 them.



 Christian Kamm wrote:
 Here portable means 'portable between different compilers for the same
 architecture'?
 
 I'm wondering because I thought the point of specifying inline assembler
 was exactly to guarantee that kind of portability. So you would not
 consider a compiler that does not implement naked, or handles it
 differently from DMD to be breaking the D specification?



 Walter Bright wrote:
 Since the stack prolog/epilog is not defined in the D ABI, a compiler is
 free to innovate in this area.
 
 The reason to specify the inline assembler is to have a common ground on
 the assembler syntax.



Thanks for the clarification. We'll not worry about it too much then -
though I think that from the conversation with Don, Tomas now has a good
idea of what we'd need to do for them to behave similarly.
Oct 31 2008
prev sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:

 Christian Kamm wrote:

 Walter Bright wrote:

 I should add that 'naked' is for people who don't mind getting intimate
 with how the compiler arranges things. Any code using it should expect
 it to not be portable, and be past the compiler wagging its finger at
 them.



 Here portable means 'portable between different compilers for the same
 architecture'?
 I'm wondering because I thought the point of specifying inline 
 assembler was
 exactly to guarantee that kind of portability. So you would not 
 consider a
 compiler that does not implement naked, or handles it differently from 
 DMD
 to be breaking the D specification?



 Since the stack prolog/epilog is not defined in the D ABI, a compiler is 
 free to innovate in this area.



That's great, and should be in the documentation.
However, I don't think there's any reason for the prolog to interfere 
with an all-assembler naked function.
Accessing a stack parameter by name from inside a naked asm function 
should either be:
* defined as implementation-dependent; or
* assume nothing about the way the variable is referenced, and should be 
independent of the stack prolog. (This could also be achieved with 
another 'magic' constant, similar to LOCALSIZE, giving the size of the 
stack frame for that function; so that var+FRAMESIZE is constant, 
regardless of the vendor).
For now, you could add a line to the docs stating that "accessing stack 
params and variables from naked asm functions is not yet standardized".



 The reason to specify the inline assembler is to have a common ground on 
 the assembler syntax.
Nov 03 2008