On 3 February 2015 at 11:15, Iain Buclaw ibuc...@gdcproject.org wrote:
On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
If so, what corrective action is the user faced with:
The user can modify the code
On 2/3/15 9:05 PM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mar39k$hvh$1...@digitalmars.com...
I think the best route here - and the most in-the-spirit-of-D - is to
provide introspection on whether a function is being inlined or not.
Then we can always have in libraries:
Andrei Alexandrescu wrote in message news:mar39k$hvh$1...@digitalmars.com...
I think the best route here - and the most in-the-spirit-of-D - is to
provide introspection on whether a function is being inlined or not. Then
we can always have in libraries:
bool uart(ubyte b)
{
static
On Tuesday, 3 February 2015 at 22:41:30 UTC, Jonathan M Davis
wrote:
Well, as far as I can tell, that's pretty much exactly what
Walter meant by
hot and cold - how likely they are to be called, with the
idea that the
compiler could then use that information to better optimize -
be it inlining
On Tue, Feb 03, 2015 at 09:53:37PM +1100, Daniel Murphy via Digitalmars-d wrote:
Walter Bright wrote in message news:maq7f1$2hka$1...@digitalmars.com...
[...]
It's like the old joke where a captain is asked by a colonel how he'd
get a flagpole raised. The captain replied with a detailed set of
On 2/3/15 12:17 AM, Johannes Pfau wrote:
Well I see that you're not even considering adding a simple pragma to
help embedded programming. In that case I see absolutely no reason to
continue working on that. You guys say we lack expertise so we cannot
help directly and you're in search of
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
If so, what corrective action is the user faced with:
The user can modify the code to allow it to be inlined. There are a huge number
of constructs that cause dmd's inliner to completely give up. If a function
_must_ be inlined, the compiler needs to
V Mon, 02 Feb 2015 21:53:43 +
Dicebot via Digitalmars-d digitalmars-d@puremagic.com napsáno:
On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote:
On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
Walter seems to dislike forced inlining for various reasons,
Am Mon, 02 Feb 2015 15:44:21 -0800
schrieb Walter Bright newshou...@digitalmars.com:
Also it's a conceptually nice way for typed registers: You can read
it as: I've got a Register of type PORT which is an extern variable
located add a fixed address. PORT abstract away volatile access.
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
The user can modify the code to allow it to be inlined. There are a huge number
of constructs that cause dmd's inliner to completely give up. If a function
_must_ be inlined, the compiler needs to give an error if it fails.
A separate message with a
On 3 February 2015 at 08:28, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
If so, what corrective action is the user faced with:
The user can modify the code to allow it to be inlined. There are a huge
number
of constructs that
On Tuesday, 3 February 2015 at 09:36:57 UTC, Walter Bright wrote:
On 2/3/2015 1:11 AM, Mike wrote:
All things being equal, will there be any difference between
the resulting
binaries for each of these scenarios?
No.
Another way of putting it: Does pragma(inline, true) simply
allow the
On Tuesday, 3 February 2015 at 11:33:35 UTC, Mike wrote:
I don't like hot/cold as it does not convey the effect.
Yeah, I believe LLVM has a register saving calling convention
that is cold_cc, so cold would be more suited for functions
that are almost never called.
Am Tue, 03 Feb 2015 07:09:10 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 2/3/15 12:17 AM, Johannes Pfau wrote:
Well I see that you're not even considering adding a simple pragma
to help embedded programming. In that case I see absolutely no
reason to continue
On Monday, 2 February 2015 at 23:29:26 UTC, Walter Bright wrote:
Now, when it can't inline, do you expect the compiler to
produce an error message?
Just to add support:
Yes, exactly that.
If so, what corrective action is the user faced with:
Change the function so it can be inlined, or
On 2/2/15 5:34 PM, Jonathan M Davis via Digitalmars-d wrote:
On Monday, February 02, 2015 13:01:28 Walter Bright via Digitalmars-d wrote:
On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
I'm pretty sure the only controversy is that you want it to be a
pragma, everyone else wants it to be an
On Tuesday, 3 February 2015 at 10:36:08 UTC, Walter Bright wrote:
Obviously, inlining functions with loops tend to have lower
payoffs anyway, because the loop time swamps the function call
overhead.
I feel a bit awkward disagreeing with you about a topic like
this, because of your obviously
On Tuesday, 3 February 2015 at 18:16:20 UTC, Andrei Alexandrescu
wrote:
static assert(__traits(inlined),
Inlining of uart() must be supported.);
This is unworkable:
1. You want to be able to turn off inlining for debugging.
2. You would have to wait with evaluating static_assert
On Tuesday, 3 February 2015 at 08:31:24 UTC, Walter Bright wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
The user can modify the code to allow it to be inlined. There
are a huge number
of constructs that cause dmd's inliner to completely give up.
If a function
_must_ be inlined, the
On 2015-02-03 05:05, Daniel Murphy wrote:
Walter Bright wrote in message news:maq8ao$2idu$1...@digitalmars.com...
Yup. I understand the concern that a compiler would opt out of
inlining those if it legally could, but I just cannot see that
happening in reality. Modern compilers have been
On 2/3/15 9:29 AM, Dicebot wrote:
On Tuesday, 3 February 2015 at 08:31:24 UTC, Walter Bright wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
The user can modify the code to allow it to be inlined. There are a
huge number
of constructs that cause dmd's inliner to completely give up. If a
On Tuesday, 3 February 2015 at 18:16:20 UTC, Andrei Alexandrescu
wrote:
I think the best route here - and the most in-the-spirit-of-D -
is to provide introspection on whether a function is being
inlined or not. Then we can always have in libraries:
bool uart(ubyte b)
{
static
On Tuesday, February 03, 2015 11:41:35 via Digitalmars-d wrote:
On Tuesday, 3 February 2015 at 11:33:35 UTC, Mike wrote:
I don't like hot/cold as it does not convey the effect.
Yeah, I believe LLVM has a register saving calling convention
that is cold_cc, so cold would be more suited for
On 2015-02-03 at 18:53, captaindet wrote:
i am a simple user writing mostly programs to crunch my scientific data. i'd
like to move my C code to D. but i deal with GBs of data that i have to sieve
through many times. in C, i have lots of repeating integer stunts in the inner
loop that must be
Some perspective from a Rust developer:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004272.html
On Tuesday, 3 February 2015 at 09:36:57 UTC, Walter Bright wrote:
On 2/3/2015 1:11 AM, Mike wrote:
All things being equal, will there be any difference between
the resulting
binaries for each of these scenarios?
No.
Another way of putting it: Does pragma(inline, true) simply
allow the
Walter Bright wrote in message news:maq0rp$2ar8$1...@digitalmars.com...
I'd like to reexamine those assumptions, and do a little rewinding.
The compiler offers a -inline switch, which will inline everything it can.
Performance oriented code will use that switch.
So why doesn't the compiler
On 03.02.15 10:35, Walter Bright wrote:
On 2/3/2015 1:11 AM, Mike wrote:
Another way of putting it: Does pragma(inline, true) simply allow the
user to
compiler parts of their source file with -inline?
Yes.
Eh, yes :)
I see now, errors/warnings are invasive compared to this simple,
Walter Bright wrote in message news:maq8ao$2idu$1...@digitalmars.com...
Yup. I understand the concern that a compiler would opt out of inlining
those if it legally could, but I just cannot see that happening in
reality. Modern compilers have been inlining for 25 years now, and they're
not
Walter Bright wrote in message news:maq7ra$2huu$1...@digitalmars.com...
To not inline trivial functions when presented with forceinline would
indeed be perverse, and while legally possible as I've said before no
compiler writer would do that. Even dmd (!) has no trouble at all inlining
Walter Bright wrote in message news:maq7f1$2hka$1...@digitalmars.com...
On 2/3/2015 1:49 AM, Daniel Murphy wrote:
This doesn't make sense to me, because even if a function is 'hot' it
still
shouldn't be inlined if inlining is turned off.
'hot' can be interpreted to be inline even if
On 2/1/2015 9:48 PM, Walter Bright wrote:
On 2/1/2015 9:21 PM, Daniel Murphy wrote:
struct Ports {
static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025, value); }
}
A somewhat more refined version:
Tobias Pankrath wrote in message
news:cumpcsdbtreytdxxc...@forum.dlang.org...
Besides this: Why should a compiler that has an inliner fail to inline a
function marked with force_inline? The result may be undesirable but it
should always work at least?
The inliner in dmd fails to inline
On Tuesday, 3 February 2015 at 10:10:43 UTC, Daniel Murphy wrote:
Tobias Pankrath wrote in message
news:cumpcsdbtreytdxxc...@forum.dlang.org...
Besides this: Why should a compiler that has an inliner fail
to inline a function marked with force_inline? The result may
be undesirable but it
Tobias Pankrath wrote in message
news:zdsqgbuoobnhnjrtp...@forum.dlang.org...
Why couldn't he just copy paste the functions code?
Why would he want to do that?
On Tuesday, 3 February 2015 at 10:15:38 UTC, Daniel Murphy wrote:
Tobias Pankrath wrote in message
news:zdsqgbuoobnhnjrtp...@forum.dlang.org...
Why couldn't he just copy paste the functions code?
Why would he want to do that?
Let me rephrase the question: Why should inlining a function
On 2/3/2015 1:49 AM, Daniel Murphy wrote:
This doesn't make sense to me, because even if a function is 'hot' it still
shouldn't be inlined if inlining is turned off.
'hot' can be interpreted to be inline even if inlining is turned off. (That is
what Manu wanted.)
There are literally
On 2/3/2015 1:56 AM, Daniel Murphy wrote:
I don't expect this to be a huge problem, because most functions marked with
forceinline would be trivial.
eg. setREG(ubyte val) { volatileStore(cast(ubyte*)0x1234, val); }
This function only exists to give a nicer interface to the register. If the
Tobias Pankrath wrote in message
news:vzgszrvcxxpethbdl...@forum.dlang.org...
Let me rephrase the question: Why should inlining a function be
impossible, if it can be done by a simple AST transformation?
It's not impossible, dmd's inliner just can't currently do it. The
transformation
On 2/3/2015 2:10 AM, Daniel Murphy wrote:
The inliner in dmd fails to inline many constructs, loops for example.
It will inline a loop if the function is called at the statement level. The
trouble with inlining a loop inside an expression is that is not expressible in
the expression tree
On 2/3/2015 1:11 AM, Mike wrote:
All things being equal, will there be any difference between the resulting
binaries for each of these scenarios?
No.
Another way of putting it: Does pragma(inline, true) simply allow the user to
compiler parts of their source file with -inline?
Yes.
On Tuesday, 3 February 2015 at 08:28:42 UTC, Walter Bright wrote:
The compiler offers a -inline switch, which will inline
everything it can. Performance oriented code will use that
switch.
pragma(inline,true) tells the compiler that this function is
'hot', and pragma(inline, false) that
Walter Bright wrote in message news:maq10s$2avu$1...@digitalmars.com...
A separate message with a pragmatic difficulty with your suggestion.
Different compilers will have different inlining capabilities. Different
versions of the same compiler may behave differently. This means that
Walter Bright wrote in message news:maq48d$2enr$1...@digitalmars.com...
Some perspective from a Rust developer:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004272.html
I think that's mostly an argument against misuse of forceinline.
On 2/2/2015 1:24 PM, Johannes Pfau wrote:
What's your argument?
That it still generates 2 instructions in the simplest case? That's an
X86 specific detail. On ARM and other RISC architectures there is a
difference between loading a literal (code into the instruction) or
loading a runtime value.
On 2/2/2015 10:44 AM, Iain Buclaw via Digitalmars-d wrote:
On 2 February 2015 at 17:43, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/15 9:23 AM, Iain Buclaw via Digitalmars-d wrote:
That code doesn't work with DMD.
http://goo.gl/hgsHg0
Has that been
Am Mon, 02 Feb 2015 13:15:13 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 9:15 AM, Johannes Pfau wrote:
It's also necessary that the compiler
knows after inlining that the address is a literal. Loading data
from fixed literal addresses produces different, more
On 2/2/2015 6:58 AM, Manu via Digitalmars-d wrote:
They need to be wrapped to be useful,
Wrapping them is a subjective matter of taste.
And before anyone says I don't know what I'm talking about, I used to write
embedded systems software. :-)
On 2/2/2015 9:06 AM, Johannes Pfau wrote:
_Dmain:
push rbp
movrbp,rsp
subrsp,0x10
movrax,0x5 ==
movQWORD PTR [rbp-0x8],rax
movecx,DWORD PTR [rax] == a register based load
The instruction it
Am Mon, 02 Feb 2015 12:39:28 -0500
schrieb Steven Schveighoffer schvei...@yahoo.com:
On 2/2/15 12:06 PM, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
Please try it before deciding it does not work.
I guess one ad hominem
On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
I'm pretty sure the only controversy is that you want it to be a
pragma, everyone else wants it to be an attribute.
That's correct.
My reasoning is simple - an attribute defines the semantics of the interface, a
pragma gives instructions to
On 2/2/2015 9:15 AM, Johannes Pfau wrote:
It's also necessary that the compiler
knows after inlining that the address is a literal. Loading data from
fixed literal addresses produces different, more efficient code than
loading from an runtime address. As the function code will generally be
On Monday, 2 February 2015 at 21:01:30 UTC, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 12:39:28 -0500
schrieb Steven Schveighoffer schvei...@yahoo.com:
On 2/2/15 12:06 PM, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
Please try it
On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote:
On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
Walter seems to dislike forced inlining for various reasons,
preferring
inlining as a hint at the most, and he probably has a point in
most
cases (let the compiler make the
On Mon, Feb 02, 2015 at 09:53:43PM +, Dicebot via Digitalmars-d wrote:
On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote:
On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
Walter seems to dislike forced inlining for various reasons,
preferring inlining as a hint at the
On 02/02/2015 12:56 PM, Timo Sintonen wrote:
Developers make things _for_ users.
Hear hear, That's a point I always feel deserves far more attention and
deliberate, conscious appreciation than it typically gets. (Just a
general observation of the overall software development world, not
On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/2/15 8:42 AM, Johannes Pfau wrote:
Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers.
So does
On 2/2/2015 2:34 PM, Jonathan M Davis via Digitalmars-d wrote:
That makes sense, though the one issue that I see with making it a pragma is
the fact that pragmas are supposed to be compiler-specific and not part of
the language (at least as I understand it), and I would expect that anyone
On Monday, 2 February 2015 at 23:29:26 UTC, Walter Bright wrote:
Now, when it can't inline, do you expect the compiler to
produce an error message?
Yes, this is the very point of such feature - telling that if
code can't be inlined, it is effectively unusable.
If so, what corrective action
On 03.02.15 00:29, Walter Bright wrote:
Now, when it can't inline, do you expect the compiler to produce an
error message?
Or warning?
Microcontroller programmers like to look at produced code, no need to
force them :)
On 2/2/2015 2:30 PM, Johannes Pfau wrote:
I does: if the backend can't know that a value is known at compile time
it cant use absolute addresses:
void test(ubyte* ptr)
{
volatileLoad(ptr); //Can't use literal addressing might be runtime
value
}
The context here is that
On 2/2/2015 1:53 PM, Dicebot wrote:
http://wiki.dlang.org/DIP56
Erm. Quoting the DIP: If a pragma specifies always inline, whether or not the
target function(s) are actually inlined is implementation defined, although the
implementation will be expected to inline it if practical.
This is
Am Mon, 02 Feb 2015 13:44:41 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 9:06 AM, Johannes Pfau wrote:
_Dmain:
push rbp
movrbp,rsp
subrsp,0x10
movrax,0x5 ==
movQWORD PTR [rbp-0x8],rax
mov
On Monday, February 02, 2015 13:01:28 Walter Bright via Digitalmars-d wrote:
On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
I'm pretty sure the only controversy is that you want it to be a
pragma, everyone else wants it to be an attribute.
That's correct.
My reasoning is simple - an
On 2/2/2015 1:39 AM, Johannes Pfau wrote:
No, it doesn't even come close.
* Ports.B += 7 doesn't work.
This should not be done with MMIO because the read and write cycles generated
are ill-defined and vary based on obscure backend details.
In order to implement it you need a
On 2 February 2015 at 10:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/2015 1:39 AM, Johannes Pfau wrote:
No, it doesn't even come close.
* Ports.B += 7 doesn't work.
This should not be done with MMIO because the read and write cycles
generated are
On 2/2/2015 1:24 AM, Johannes Pfau wrote:
Usually those people just don't use
volatile as long as their code works. Once it breaks they add volatile
everywhere till it works again.
Having a volatile type is not going to make things better for such people. In
fact, it may make things worse.
On Monday, 2 February 2015 at 09:22:41 UTC, Walter Bright wrote:
On 2/1/2015 11:16 PM, Iain Buclaw via Digitalmars-d wrote:
Where is the @property? :)
yeah, yeah !!
BTW, when D's property will finally be cleaned up?...
I did miss something, or there is still a -property flag out
there?
Am Sun, 01 Feb 2015 21:48:40 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/1/2015 9:21 PM, Daniel Murphy wrote:
Walter Bright wrote in message
news:mam6qe$15nu$1...@digitalmars.com...
We also need a pragma(address) to complement pragma(mangle).
What would that do?
Walter Bright wrote in message news:map18m$1dvv$1...@digitalmars.com...
Now, when it can't inline, do you expect the compiler to produce an error
message?
Yes.
If so, what corrective action is the user faced with:
The user can modify the code to allow it to be inlined. There are a huge
Just go with __gshared.
Or even better, avoid globals ;).
Johannes Pfau wrote in message news:maotpd$1ape$1...@digitalmars.com...
but if you instead write
@property ref Volatile!ubyte PORTA()
{
return *(cast(Volatile!(ubyte)*)0x05)
}
PORTA |= now calls a function behind the scenes. The backend does not
immediately know that PORTA is always 0x05.
On 2 Feb 2015 23:45, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/2015 2:30 PM, Johannes Pfau wrote:
I does: if the backend can't know that a value is known at compile time
it cant use absolute addresses:
void test(ubyte* ptr)
{
volatileLoad(ptr);
On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/2015 3:29 AM, weaselcat wrote:
On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau
wrote:
which perform as well as C code,
On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
I'm pretty sure the only controversy is that you want it to be a
pragma, everyone else wants it to be an attribute. I don't think
anyone has argued against a force_inline.
I also support pragma, but didn't agree with proposed semantics
On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/2015 3:29 AM, weaselcat wrote:
On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
which perform as well as C code, but only with force-inline
why is this still not part of
On 2 February 2015 at 20:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/2015 1:39 AM, Johannes Pfau wrote:
* You do need force-inline to produce halfway decent code
Nope. volatileLoad() and volatileStore() do not produce function calls.
They need to be
On 2/2/15 6:55 AM, Dicebot wrote:
On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote:
I'm pretty sure the only controversy is that you want it to be a
pragma, everyone else wants it to be an attribute. I don't think
anyone has argued against a force_inline.
I also support pragma, but
On 2/2/15 8:42 AM, Johannes Pfau wrote:
Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers.
So does the argument boil down to better inlining control and
enforcement? -- Andrei
Am Mon, 02 Feb 2015 02:57:28 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 1:39 AM, Johannes Pfau wrote:
No, it doesn't even come close.
* Ports.B += 7 doesn't work.
This should not be done with MMIO because the read and write cycles
generated are ill-defined and
On 2 February 2015 at 17:43, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/2/15 9:23 AM, Iain Buclaw via Digitalmars-d wrote:
That code doesn't work with DMD.
http://goo.gl/hgsHg0
Has that been filed yet? -- Andrei
Am Mon, 02 Feb 2015 08:55:59 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 2/2/15 8:42 AM, Johannes Pfau wrote:
Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers.
So does the argument boil down to better inlining control
On 2 February 2015 at 17:06, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 1:24 AM, Johannes Pfau wrote:
Usually those people just don't use
volatile as long as their code
On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/2/15 8:42 AM, Johannes Pfau wrote:
Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers.
So does the argument boil down to better inlining control and
On 2/2/15 12:06 PM, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
Please try it before deciding it does not work.
I guess one ad hominem wasn't enough?
Sorry, I'm not really vested in this discussion at all, but I don't
think
On Monday, 2 February 2015 at 16:55:59 UTC, Andrei Alexandrescu
wrote:
I think it's time to reopen that negotiation.
+1
So does the argument boil down to better inlining control and
enforcement? -- Andrei
If we reopen this I think we should start at the beginning and
not yet concentrate
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 1:24 AM, Johannes Pfau wrote:
Usually those people just don't use
volatile as long as their code works. Once it breaks they add
volatile everywhere till it works again.
Having a volatile
On 2/2/15 9:23 AM, Iain Buclaw via Digitalmars-d wrote:
That code doesn't work with DMD.
http://goo.gl/hgsHg0
Has that been filed yet? -- Andrei
On 2/2/15 9:06 AM, Johannes Pfau wrote:
I guess one ad hominem wasn't enough?
Please cool it will you? That doesn't quite qualify. -- Andrei
On 2 February 2015 at 05:48, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/2015 9:21 PM, Daniel Murphy wrote:
Walter Bright wrote in message news:mam6qe$15nu$1...@digitalmars.com...
We also need a pragma(address) to complement pragma(mangle).
What would that
On 2/2/15 9:15 AM, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 08:55:59 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 2/2/15 8:42 AM, Johannes Pfau wrote:
Again the problem is not volatileLoad/Store which
translate to single instructions it's wrappers.
So does the
On 2/1/15 8:41 PM, Joakim wrote:
On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu wrote:
There's something we need to explain about the vision document itself.
Do I want to see more of Mike's awesome work in D going forward? Yes.
Do I want to see D on mobile? Of course. There's a
On 2/1/2015 11:16 PM, Iain Buclaw via Digitalmars-d wrote:
Where is the @property? :)
yeah, yeah !!
Am Sun, 01 Feb 2015 13:45:24 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/1/2015 3:22 AM, Johannes Pfau wrote:
Am Sun, 01 Feb 2015 02:11:42 -0800
schrieb Walter Bright newshou...@digitalmars.com:
core.bitop.volatileLoad() and volatileStore() are implemented, and
do the
On Sunday, 1 February 2015 at 10:14:28 UTC, Walter Bright wrote:
Please post to bugzilla and tag the issue with bare-metal.
https://issues.dlang.org/show_bug.cgi?id=14101
Please have a look and correct if necessary.
On 2/1/2015 2:12 AM, eles wrote:
On Sunday, 1 February 2015 at 10:11:57 UTC, eles wrote:
The absolute minimum set of changes that I had to make can be seen here:
https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
corrected link (I think):
Am Sun, 01 Feb 2015 02:11:42 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/1/2015 1:38 AM, Timo Sintonen wrote:
The one of major issues is: how to access hardware. We need a
language feature to access hardware registers. This has been
discussed twice. Both time you rejected
On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
I don't recall what you've suggested in this vein that was very
unpopular - can you please post an example?
These are not in any particular order. They are just how I
remember them.
I don't care if everyone disagrees with
On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
So I'd say there are not too many language problems, the main
problem
is runtime/compiler interaction:
* If you don't want to use any runtime at all that's actually
the
easier part. We'd need to implement a little more of
On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote:
which perform as well as C code, but only with force-inline
why is this still not part of the language? I'm not sure of
anything else that has been repeatedly asked for without any good
counterarguments.
1 - 100 of 140 matches
Mail list logo
