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 <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 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 easier to remove it and avoid
all the other
comments on why we need middle-end and backend headers
in gdc.
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
wrong.
There are two uses for asm, and they are very different:
(1) Functionality. This happens when there are gaps in the
language,
and you get an abstraction inversion. You can address these with
intrinsics.
(2) Speed. High-speed, all-asm functions. These _always_
include a loop.
You seem to be focusing on (1), but case (2) is completely
different.
Case (2) cannot be replaced with intrinsics. For example,
you can't
write asm code using MSVC intrinsics (because the compiler
rewrites
your code).
Currently, D is the best way to write (2). It is much, much
better
than an external assembler.
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 aswell, and have the most experience
with. But
in my experience, they're almost always best written with
intrinsics.
If they're small enough to be inlined, then you can't afford not
to use
intrinsics. If they are truly big functions, then you begin to
sacrifice
readability and maintain-ability, and certainly limit the number of
programmers that can maintain the code.
I don't agree with that. In the situations I'm used to, using
intrinsics would not make it easier to read, and would definitely
not make it easier to maintain. I find it inconceivable that
somebody could understand the processor well enough to maintain the
code, and yet not understand asm.
These functions of yours are 100% asm, that's not really what I would
usually call 'inline asm'. That's really just 'asm' :)
You are being picky here.
Yes, this is 100% asm. But still, 100% asm is inline asm. It is asm
within D code.
