On 20/06/12 16:37, Manu wrote:
On 20 June 2012 17:15, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 20/06/12 13:22, Manu wrote:
I find optimisers are very good at code simplification, assuming
that
you massage the code/expressions to neatly match
On 21 June 2012 04:06, Bernard Helyer b.hel...@gmail.com wrote:
On Thursday, 21 June 2012 at 00:02:58 UTC, Walter Bright wrote:
On 6/20/2012 4:26 AM, Bernard Helyer wrote:
I was sputtering with rage. Sputtering!
Look Dave, I can see you're really upset about this. I honestly think you
On 20 June 2012 21:16, Alex Rønne Petersen a...@lycus.org wrote:
On 20-06-2012 21:48, Joseph Rushton Wakeling wrote:
On 20/06/12 20:35, Alex Rønne Petersen wrote:
And x86 inline assembler... on ARM? I don't think I follow.
If I understand http://dlang.org/iasm.html correctly, the idea is
On 2012-06-19 21:14, Russel Winder wrote:
I never used V1 (though I do have the Tango book) so enforcing V2 will
nto be a problem. Actually this means I can delete 65% of the SCons D
tool :-)
You can use the Tango book with D2.
3) For anyone who has submitted patches for Mingw and
Le 19/06/2012 22:58, Manu a écrit :
Thinking more about the implications of removing the inline asm, what
would REALLY roxors, would be a keyword to insist a variable is
represented by a register, and by extension, to associate it with a
specific register:
register int x; //
Le 20/06/2012 04:34, Walter Bright a écrit :
I don't think we need to worry about that. Implementers tend to follow
existing practice unless there is a very, very good reason.
Did you ever heard of a company named microsoft ?
On 20 June 2012 10:42, deadalnix deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an inline
assembler.
Better yet, this could use the 'new' attribute syntax, which most agree
will support arguments:
@register(rsp) int x;
Le 20/06/2012 09:58, Manu a écrit :
On 20 June 2012 10:42, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an inline
assembler.
Better yet, this could use the
Inline assembly has been relatively useless in GCC for years.
Inline asm
interferes with the optimisers ability to do a good job, which
basically
makes use of inline assembly self-defeating.
The only time I ever need to use inline-asm is to interface an
arch feature
that has no API. As long as
On 20 June 2012 11:14, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 09:58, Manu a écrit :
On 20 June 2012 10:42, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 22:58, Manu a écrit :
This would almost entirely eliminate the usefulness of an
On 20 June 2012 09:32, Tobias Pankrath tob...@pankrath.net wrote:
Inline assembly has been relatively useless in GCC for years. Inline asm
interferes with the optimisers ability to do a good job, which basically
makes use of inline assembly self-defeating.
The only time I ever need to use
On 20 June 2012 03:58, Walter Bright newshou...@digitalmars.com wrote:
Do a grep for asm across the druntime library sources. Can you
justify all
of that with some other scheme?
I think almost all the blocks I just browsed through could be easily
written
with nothing more than the
On 20 June 2012 11:32, Tobias Pankrath tob...@pankrath.net wrote:
Inline assembly has been relatively useless in GCC for years. Inline asm
interferes with the optimisers ability to do a good job, which basically
makes use of inline assembly self-defeating.
The only time I ever need to use
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on
/ the compiler version they want to use.
1) D Inline Asm and naked function support is raising far too
On 20/06/12 03:01, Alex Rønne Petersen wrote:
On 20-06-2012 02:58, Timon Gehr wrote:
On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
On 20-06-2012 01:55, Timon Gehr wrote:
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM,
On 20/06/12 00:55, Manu wrote:
On 20 June 2012 01:07, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
On 6/19/2012 1:58 PM, Manu wrote:
I find a thorough suite of architecture intrinsics are usually
the fastest and
cleanest way to
On 20 June 2012 13:51, Don Clugston d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on
/ the compiler version they want to use.
On 20 June 2012 13:59, Don Clugston d...@nospam.com wrote:
You and I seem to be from different planets. I have almost never written
as asm function which was suitable for inlining.
Take a look at std.internal.math.biguintX86.d
I do not know how to write that code without inline asm.
It's because the compiler doesn't understand assembly code. It
has no
knowledge of what it actually does, and as a result, just
treats it as a
black box.
But this is not set in stone. If I teach a compiler how to
optimize intrinsics, can't I teach him to understand and optimize
a (maybe
On Wednesday, 20 June 2012 at 02:35:10 UTC, Walter Bright wrote:
On 6/19/2012 6:06 PM, Alex Rønne Petersen wrote:
On 20-06-2012 03:01, Walter Bright wrote:
On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
GDC can certainly define its D calling
On 2012-06-20 12:51, Don Clugston wrote:
You seem to be conflating a couple of unrelated issues here.
One is the calling convention. The other is inline asm.
Comments in the thread about asm is mostly used for short things which
get inlined leave me completely baffled, as it is completely
On 20 June 2012 14:19, Tobias Pankrath tob...@pankrath.net wrote:
It's because the compiler doesn't understand assembly code. It has no
knowledge of what it actually does, and as a result, just treats it as a
black box.
But this is not set in stone. If I teach a compiler how to optimize
Jacob Carlborg:
You do understand that the GCC-style inline assembly will still
be available?
Are DMD and LDC2 going to accept that GCC-style inline assembly?
Bye,
bearophile
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post
the main
issues here that most affect D
Le 20/06/2012 13:04, Manu a écrit :
Case 1 has no alternative to inline asm. I've thrown out some crazy
ideas to think about (but nobody seems to like them). I still think it
could be addressed though.
Case 2; I'm not convinced. These such long functions are the type I'm
generally interested in
On 20 June 2012 14:44, Don Clugston d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 19/06/12 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going
On 20 June 2012 15:30, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 13:04, Manu a écrit :
Case 1 has no alternative to inline asm. I've thrown out some crazy
ideas to think about (but nobody seems to like them). I still think it
could be addressed though.
Case 2; I'm not convinced.
On 19/06/12 19:19, Iain Buclaw wrote:
Had round one of the code review process, so I'm going to post the main issues
here that most affect D users / the platforms they want to run on / the compiler
version they want to use.
A somewhat different take on these issues -- we've several times now
Le 20/06/2012 14:51, Manu a écrit :
On 20 June 2012 14:44, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com
mailto:d...@nospam.com
On 20 June 2012 14:01, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 19/06/12 19:19, Iain Buclaw wrote:
Had round one of the code review process, so I'm going to post the main
issues
here that most affect D users / the platforms they want to run on / the
compiler
version
On 20/06/12 14:31, Iain Buclaw wrote:
Hands are tied, sorry.
Is this planned as a short-term change for which a long-term solution will be
developed, or is it likely to be a permanent split with DMD?
On 20/06/12 13:22, Manu wrote:
On 20 June 2012 13:59, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
You and I seem to be from different planets. I have almost never
written as asm function which was suitable for inlining.
Take a look at std.internal.math.biguintX86.d
On 20 June 2012 17:15, Don Clugston d...@nospam.com wrote:
On 20/06/12 13:22, Manu wrote:
I find optimisers are very good at code simplification, assuming that
you massage the code/expressions to neatly match any architectural quirks.
I also appreciate that good x86 code is possibly the
On 20/06/12 14:51, Manu wrote:
On 20 June 2012 14:44, Don Clugston d...@nospam.com
mailto:d...@nospam.com wrote:
On 20/06/12 13:04, Manu wrote:
On 20 June 2012 13:51, Don Clugston d...@nospam.com
mailto:d...@nospam.com
mailto:d...@nospam.com mailto:d...@nospam.com
On 20 June 2012 15:07, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 20/06/12 14:31, Iain Buclaw wrote:
Hands are tied, sorry.
Is this planned as a short-term change for which a long-term solution will
be developed, or is it likely to be a permanent split with DMD?
Likely
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw ibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on /
the compiler version they want to use.
1) D Inline Asm and naked
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the language. So, if gdc doesn't support it, it's not a fully compliant D
On 20 June 2012 17:00, Brad Anderson e...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw ibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on /
the
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the
On 20 June 2012 17:08, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the
On 20-06-2012 18:08, Jonathan M Davis wrote:
On Wednesday, June 20, 2012 13:33:53 Jacob Carlborg wrote:
You do understand that the GCC-style inline assembly will still be
available?
But inline assembler with the syntax that dmd uses is supposed to be part of
the language. So, if gdc doesn't
On 20 June 2012 17:23, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.com wrote:
Hi,
Had round one of the code review process, so I'm
Le 20/06/2012 18:40, Iain Buclaw a écrit :
On 20 June 2012 17:23, deadalnixdeadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.netwrote:
On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclawibuc...@ubuntu.comwrote:
Hi,
Had
On 20 June 2012 17:44, deadalnix deadal...@gmail.com wrote:
Le 20/06/2012 18:40, Iain Buclaw a écrit :
On 20 June 2012 17:23, deadalnixdeadal...@gmail.com wrote:
Le 20/06/2012 18:18, Iain Buclaw a écrit :
On 20 June 2012 17:00, Brad Andersone...@gnuk.net wrote:
On Tue, Jun 19, 2012
On Wednesday, 20 June 2012 at 16:09:14 UTC, Jonathan M Davis
wrote:
But inline assembler with the syntax that dmd uses is supposed
to be part of
the language. So, if gdc doesn't support it, it's not a fully
compliant D
compiler.
I am not too sure about that: In my opinion, your description
On 20/06/12 18:10, David Nadlinger wrote:
I am not too sure about that: In my opinion, your description of the problem
would be accurate if some compiler implemented asm {}, but with a different
syntax or different semantics. But GDC simply does not (resp. will not)
implement D-style inline
On 20-06-2012 21:08, Joseph Rushton Wakeling wrote:
On 20/06/12 18:10, David Nadlinger wrote:
I am not too sure about that: In my opinion, your description of the
problem
would be accurate if some compiler implemented asm {}, but with a
different
syntax or different semantics. But GDC simply
On 20/06/12 20:35, Alex Rønne Petersen wrote:
And x86 inline assembler... on ARM? I don't think I follow.
If I understand http://dlang.org/iasm.html correctly, the idea is that D should
have an inline assembler for each target architecture.
AFAICS what's desired is that you should be able
On 20-06-2012 21:48, Joseph Rushton Wakeling wrote:
On 20/06/12 20:35, Alex Rønne Petersen wrote:
And x86 inline assembler... on ARM? I don't think I follow.
If I understand http://dlang.org/iasm.html correctly, the idea is that D
should have an inline assembler for each target architecture.
On Wednesday, 20 June 2012 at 19:08:43 UTC, Joseph Rushton
Wakeling wrote:
Reading http://dlang.org/iasm.html I don't have the impression
that the inline assembler is an optional part of the D spec or
not guaranteed to be available -- it's very deliberately
intended to be there.
… yet code
On 6/20/2012 4:26 AM, Bernard Helyer wrote:
I was sputtering with rage. Sputtering!
Look Dave, I can see you're really upset about this. I honestly think you ought
to sit down calmly, take a stress pill, and think things over. I know I've made
some very poor decisions recently, but I can
On Tuesday, 19 June 2012 at 18:19:01 UTC, Iain Buclaw wrote:
1) D Inline Asm and naked function support is raising far too
many alarm bells. So would just be easier to remove it and
avoid all the other comments on why we need middle-end and
backend headers in gdc.
I'll give my opinion. I
On Thursday, 21 June 2012 at 00:02:58 UTC, Walter Bright wrote:
On 6/20/2012 4:26 AM, Bernard Helyer wrote:
I was sputtering with rage. Sputtering!
Look Dave, I can see you're really upset about this. I honestly
think you ought to sit down calmly, take a stress pill, and
think things over.
Hi,
Had round one of the code review process, so I'm going to post
the main issues here that most affect D users / the platforms
they want to run on / the compiler version they want to use.
1) D Inline Asm and naked function support is raising far too
many alarm bells. So would just be
On 19-06-2012 20:19, Iain Buclaw wrote:
Hi,
Had round one of the code review process, so I'm going to post the main
issues here that most affect D users / the platforms they want to run on
/ the compiler version they want to use.
1) D Inline Asm and naked function support is raising far too
Iain Buclaw:
Most discussion I would imagine be on the decision to remove D
inline assembler support from gdc. So, nay sayers, do your
worst, but unfortunately there is a +1 here for removal.
I suggest to try to do the opposite, that it to try to increase
the current conformance of GDC to
On 19-06-2012 20:44, bearophile wrote:
Iain Buclaw:
Most discussion I would imagine be on the decision to remove D inline
assembler support from gdc. So, nay sayers, do your worst, but
unfortunately there is a +1 here for removal.
I suggest to try to do the opposite, that it to try to
On 19 June 2012 19:44, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Most discussion I would imagine be on the decision to remove D inline
assembler support from gdc. So, nay sayers, do your worst, but
unfortunately there is a +1 here for removal.
I suggest to try to do the
On 19 June 2012 19:51, Alex Rønne Petersen a...@lycus.org wrote:
On 19-06-2012 20:44, bearophile wrote:
Iain Buclaw:
Most discussion I would imagine be on the decision to remove D inline
assembler support from gdc. So, nay sayers, do your worst, but
unfortunately there is a +1 here for
Alex Rønne Petersen:
Further, I doubt the GCC maintainers would actually approve of
doing this.
I know nothing about how GCC maintainers do their work. Can you
explain why they have accepted a D front-end but refuse a change
like that? Are they believing that D is a kind of re-syntaxed
Iain Buclaw:
Does D *really* require a new calling convention?
Also does it *really* require naked support?
I guess the answers are yes and yes.
I think naked support is a bad idea
Maybe he/she's wrong, and it's a good idea. Where are the deep
discussions that justify his/her words?
On Tue, 2012-06-19 at 20:19 +0200, Iain Buclaw wrote:
[…]
1) D Inline Asm and naked function support is raising far too
many alarm bells. So would just be easier to remove it and avoid
all the other comments on why we need middle-end and backend
headers in gdc.
I can do without inline
Alex Rønne Petersen:
Because the guest wants to rearrange the host's home.
D better have a good reason to do so. So far, I have seen none.
Lot of time ago I have suggested to Walter to look at the D
design searching for features that are hard to implement on
normal back-ends (at that time
On 19-06-2012 21:17, bearophile wrote:
Alex Rønne Petersen:
Because the guest wants to rearrange the host's home.
D better have a good reason to do so. So far, I have seen none.
Lot of time ago I have suggested to Walter to look at the D design
searching for features that are hard to
On 6/19/2012 11:19 AM, Iain Buclaw wrote:
1) D Inline Asm and naked function support is raising far too many alarm bells.
So would just be easier to remove it and avoid all the other comments on why we
need middle-end and backend headers in gdc.
I'm not clear on why the inline assembler is a
On 6/19/2012 11:57 AM, Iain Buclaw wrote:
To quote from one of the i386 backend maintainers:
---
Does D *really* require a new calling convention?
No, but the idea was to allow D to innovate on calling conventions without
disturbing code that needed to interface with C.
Also does it
On Tuesday, 19 June 2012 at 20:04:12 UTC, Walter Bright wrote:
On 6/19/2012 11:57 AM, Iain Buclaw wrote:
To quote from one of the i386 backend maintainers:
---
Does D *really* require a new calling convention?
No, but the idea was to allow D to innovate on calling
conventions without
Iain Buclaw:
From what I gathered from further discussion, it made sense for
embedded platforms, such as ARM, but not x86.
Why?
If this whole discussion wants to go somewhere, and not just be a
waste of everyone time like similar past discussions on such
topics, it needs a *much larger*
On 19 June 2012 21:19, Iain Buclaw ibuc...@ubuntu.com wrote:
1) D Inline Asm and naked function support is raising far too many alarm
bells. So would just be easier to remove it and avoid all the other
comments on why we need middle-end and backend headers in gdc.
Inline assembly has been
1) D Inline Asm and naked function support is raising far too many alarm
bells. So would just be easier to remove it and avoid all the other
comments on why we need middle-end and backend headers in gdc.
And the C++ frontend doesn't need these headers for its inline assembler
Le 19/06/2012 20:51, Alex Rønne Petersen a écrit :
On 19-06-2012 20:44, bearophile wrote:
Iain Buclaw:
Most discussion I would imagine be on the decision to remove D inline
assembler support from gdc. So, nay sayers, do your worst, but
unfortunately there is a +1 here for removal.
I suggest
Plus, gcc asm syntax is horrible, and DMD's is really nice.
yep, ATT vs. Intel syntax :)
On 19 June 2012 23:03, Walter Bright newshou...@digitalmars.com wrote:
On 6/19/2012 11:57 AM, Iain Buclaw wrote:
To quote from one of the i386 backend maintainers:
---
Does D *really* require a new calling convention?
No, but the idea was to allow D to innovate on calling conventions
Le 19/06/2012 22:08, Iain Buclaw a écrit :
From what I gathered from further discussion, it made sense for
embedded platforms, such as ARM, but not x86.
It has proven to be useful to me, not only for performances reasons, but
also for low level manipulations.
It don't see what make ARM
On 19 June 2012 23:59, deadalnix deadal...@gmail.com wrote:
Le 19/06/2012 22:08, Iain Buclaw a écrit :
From what I gathered from further discussion, it made sense for
embedded platforms, such as ARM, but not x86.
It has proven to be useful to me, not only for performances reasons, but
Le 19/06/2012 23:22, Manu a écrit :
If you had the register alias feature I described above, would you be
ale to write such low-level manipulations using intrinsics?
I think I would be able to rewrite all x86 asm blocks I've ever written
using that feature.
No, I couldn't. Such code involved
On 6/19/2012 1:08 PM, Iain Buclaw wrote:
On Tuesday, 19 June 2012 at 20:04:12 UTC, Walter Bright wrote:
Naked support allows people to write max efficient assembler without needing
to exit the language and use the (often miserable) standalone assembler.
From what I gathered from further
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow D to innovate on calling
conventions without disturbing code that needed to
interface with C.
The idea is nice, but ideas aren't enough. Where are the benchmarks that show a
performance improvement over the C calling
On 6/19/2012 1:58 PM, Manu wrote:
I find a thorough suite of architecture intrinsics are usually the fastest and
cleanest way to the best possible code, although 'naked' may be handy in this
circumstance too...
Do a grep for naked across the druntime library sources. For example, its use
in
On 20 June 2012 00:41, deadalnix deadal...@gmail.com wrote:
Le 19/06/2012 23:22, Manu a écrit :
If you had the register alias feature I described above, would you be
ale to write such low-level manipulations using intrinsics?
I think I would be able to rewrite all x86 asm blocks I've ever
Le 19/06/2012 23:54, Manu a écrit :
On 20 June 2012 00:41, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 23:22, Manu a écrit :
If you had the register alias feature I described above, would
you be
ale to write such low-level
On 19-06-2012 22:56, Trass3r wrote:
Plus, gcc asm syntax is horrible, and DMD's is really nice.
yep, ATT vs. Intel syntax :)
Please be informed that GCC inline asm supports Intel syntax...
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
On 19-06-2012 22:40, Manu wrote:
On 19 June 2012 21:19, Iain Buclaw ibuc...@ubuntu.com
mailto:ibuc...@ubuntu.com wrote:
1) D Inline Asm and naked function support is raising far too many
alarm bells. So would just be easier to remove it and avoid all the
other comments on why we
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow D to innovate on calling
conventions without disturbing code that needed to
interface with C.
The idea is nice, but ideas aren't enough. Where are the benchmarks
that show a
Please be informed that GCC inline asm supports Intel syntax...
With -masm=intel.
On 19-06-2012 23:22, Manu wrote:
On 19 June 2012 23:59, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
Le 19/06/2012 22:08, Iain Buclaw a écrit :
From what I gathered from further discussion, it made sense for
embedded platforms, such as ARM, but not x86.
On 20-06-2012 00:48, Trass3r wrote:
Please be informed that GCC inline asm supports Intel syntax...
With -masm=intel.
No, you can tell the inline assembler to use Intel syntax from inside
code. Iain showed me how on IRC at some point, but I forget the specifics.
--
Alex Rønne Petersen
On 20 June 2012 01:07, Walter Bright newshou...@digitalmars.com wrote:
On 6/19/2012 1:58 PM, Manu wrote:
I find a thorough suite of architecture intrinsics are usually the
fastest and
cleanest way to the best possible code, although 'naked' may be handy in
this
circumstance too...
Do a
On 19-06-2012 22:51, Trass3r wrote:
1) D Inline Asm and naked function support is raising far too many
alarm bells. So would just be easier to remove it and avoid all the
other comments on why we need middle-end and backend headers in gdc.
And the C++ frontend doesn't need these headers for
On 20 June 2012 01:37, deadalnix deadal...@gmail.com wrote:
Walter gave you examples. You'll find many others in druntime.
Here is something I wrote recently that use this again :
http://www.deadalnix.me/2012/**03/24/get-an-exception-from-a-**
On 19 June 2012 23:51, Alex Rønne Petersen a...@lycus.org wrote:
On 20-06-2012 00:48, Trass3r wrote:
Please be informed that GCC inline asm supports Intel syntax...
With -masm=intel.
No, you can tell the inline assembler to use Intel syntax from inside code.
Iain showed me how on IRC at
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow D to innovate on calling
conventions without disturbing code that needed to
interface with C.
The idea is nice, but ideas aren't
On 20-06-2012 01:55, Timon Gehr wrote:
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow D to innovate on calling
conventions without disturbing code that needed to
interface with
Manu:
Properly implemented multiple-return-values being the killer
app here!
Using ALL the argument registers for returning multiple values
aswell ;)
Well, if D has a specific calling convention, it's better for it
to give a lot back.
Regarding the LLVM back-end for Haskell, it has required
On 6/19/2012 3:55 PM, Manu wrote:
On 20 June 2012 01:07, Walter Bright newshou...@digitalmars.com
Do a grep for naked across the druntime library sources. For example, its
use in druntime/src/rt/alloca.d, where it is very much needed, as alloca()
is one of those magic functions.
I
On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
On 20-06-2012 01:55, Timon Gehr wrote:
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow D to innovate on calling
conventions
On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
GDC can certainly define its D calling convention to match GCC's. It's
an implementation defined thing, not a language defined one.
Then let's please rename it to the DMD ABI instead of calling it the D
On 20-06-2012 02:58, Timon Gehr wrote:
On 06/20/2012 02:04 AM, Alex Rønne Petersen wrote:
On 20-06-2012 01:55, Timon Gehr wrote:
On 06/20/2012 12:47 AM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
On 6/19/2012 1:36 PM, bearophile wrote:
No, but the idea was to allow
On 6/19/2012 4:23 PM, Manu wrote:
That code could all be done with the register alias I described, and
__push/__pop intrinsics.
Push/pop intrinsics won't work reliably, because on 16 byte aligned stack
machines the compiler must emit stack alignment instructions at various points.
With
On 20-06-2012 03:01, Walter Bright wrote:
On 6/19/2012 3:47 PM, Alex Rønne Petersen wrote:
On 19-06-2012 23:52, Walter Bright wrote:
GDC can certainly define its D calling convention to match GCC's. It's
an implementation defined thing, not a language defined one.
Then let's please rename it
1 - 100 of 102 matches
Mail list logo
