Am Sat, 31 Jan 2015 22:37:19 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are genuinely interested, are you committed? And if so,
what direction would you like to take?
On 1 February 2015 at 11:28, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sat, 31 Jan 2015 22:37:19 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are
On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are genuinely interested, are you committed? And if
so, what direction
would you like to take? So far, my ideas have been
On 2/1/2015 2:21 AM, eles wrote:
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.
Thank you.
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):
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 anything but your own idea of library functions. You rejected anything
anybody said. No
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):
On 1 February 2015 at 09:38, Timo Sintonen via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are genuinely interested,
Iain Buclaw via Digitalmars-d wrote in message
news:mailman.5711.1422808332.9932.digitalmar...@puremagic.com...
Only if optimisation passes removes the promise the compiler gives to
the user. I'll have to check whether or not the proposed
implementation in gdc is even viable vs. having a 'C
Andrei Alexandrescu wrote in message news:malii6$iho$2...@digitalmars.com...
Interesting. I naïvely believe it would simplify rather than complicate
the compiler. -- Andrei
That's what we thought about moving the AA implementation into the library!
On 2/1/15 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.
What features do Rust and Nim provide for such?
- NoSystem should be a supported platform and not a build failure. The
build system should
On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu
wrote:
On 2/1/15 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.
What features do Rust and Nim provide for such?
Andrei
I was not the
On 1 February 2015 at 16:32, Iain Buclaw ibuc...@gdcproject.org wrote:
On 1 February 2015 at 16:22, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/15 8:09 AM, Timo Sintonen wrote:
On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
On
On 1 February 2015 at 16:58, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Iain Buclaw via Digitalmars-d wrote in message
news:mailman.5711.1422808332.9932.digitalmar...@puremagic.com...
Only if optimisation passes removes the promise the compiler gives to
the user.
On 2/1/15 8:09 AM, Timo Sintonen wrote:
On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
On 2/1/15 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.
What features do Rust and Nim
On 1 February 2015 at 16:22, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/15 8:09 AM, Timo Sintonen wrote:
On Sunday, 1 February 2015 at 15:28:25 UTC, Andrei Alexandrescu wrote:
On 2/1/15 1:38 AM, Timo Sintonen wrote:
The one of major issues is: how to
On 2/1/15 3:28 AM, Johannes Pfau wrote:
IIRC he also proposed moving more of TypeInfo implementation to the
runtime so TypeInfo layout can be modified by the runtime or even
completely avoided by not implementing it in the runtime. The main
response was that it complicates compiler code too much
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 the language? I'm not sure of anything else that
has been repeatedly asked for without any good
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 job. They are compiler intrinsics that result in single
instructions. They support 8, 16, 32
On 2/1/2015 2:35 PM, Dicebot wrote:
On Sunday, 1 February 2015 at 21:47:26 UTC, Walter Bright 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
On 2/1/2015 8:09 AM, Timo Sintonen wrote:
I just pointed out that d had no way to access registers properly.
volatileLoad() and volatileStore() do the job correctly.
DMD and GDC
optimize very heavily and may cache, reorder and remove any access they think is
not needed.
This is
On 2/1/2015 8:32 AM, Iain Buclaw via Digitalmars-d wrote:
Only if optimisation passes removes the promise the compiler gives to
the user. I'll have to check whether or not the proposed
implementation in gdc is even viable vs. having a 'C volatile' type.
dmd actually translates those
On 2/1/2015 5:05 AM, Mike wrote:
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.
Thanks
On 1 Feb 2015 21:55, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/1/2015 8:32 AM, Iain Buclaw via Digitalmars-d wrote:
Only if optimisation passes removes the promise the compiler gives to
the user. I'll have to check whether or not the proposed
implementation in
On 2/1/2015 3:28 AM, Johannes Pfau wrote:
He got some very direct responses that told him that if an OS doesn't
have thread-support etc there's no use to run D on that. Responses like
that obviously demotivate people.
From myself or Andrei? I don't recall such.
There's nothing inherent to D
On Sunday, 1 February 2015 at 21:58:19 UTC, Walter Bright wrote:
There's nothing inherent to D or druntime that requires a
multithreaded operating system. After all, a single threaded OS
is a multithreaded operating system that simply returns an
error when a call to create a new thread is
On 2/1/15 1:57 PM, Walter Bright wrote:
On 2/1/2015 3:28 AM, Johannes Pfau wrote:
He got some very direct responses that told him that if an OS doesn't
have thread-support etc there's no use to run D on that. Responses like
that obviously demotivate people.
From myself or Andrei? I don't
On Sunday, 1 February 2015 at 21:47:26 UTC, Walter Bright 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 the language? I'm not sure of
On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu
wrote:
Yah, I must chime in here. I'm a bit surprised by Mike's
conclusion that he's been rejected.
Forgive me if that's the conclusion I conveyed. I said my ideas
were unpopular, and if one follows the links to the threads I
On 2/1/2015 4:05 PM, Mike wrote:
Agreed, but in the current druntime implementation, by the time the program
reaches main, 2 threads have already been initiated. There is also some runtime
and code-size overhead with TLS, even if one is building a single-threaded
executable. I need to look into
On 2/1/2015 8:35 PM, Mike wrote:
I'm with you, but if the runtime port only supports a single
thread, I don't want to force users of my libraries to have to
decorate their state with __gshared, as it's redundant. They
should be able to use the idiomatic D they see in D's learning
material.
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?
It would allow naming a memory address, similar to using .org in assembly.
eg
pragma(address, 0x0025)
shared ubyte PORTB;
static
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 lot of stuff that Walter and I
On Monday, 2 February 2015 at 01:17:52 UTC, Walter Bright wrote:
You can use __gshared to not get TLS,
Yes, that is what we are doing.
and a freestanding implementation doesn't necessarily imply no
threads.
Indeed.
There are also interrupt service routines that can be thought of
as short
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 lot of stuff that Walter and I
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?
It would allow naming a memory address, similar to using .org in assembly.
eg
pragma(address,
On 2 Feb 2015 05:50, 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 do?
On 1/31/2015 9:21 PM, Mike wrote:
Is D's core team genuinely interested in this domain?
Yes.
If you are genuinely interested, are you committed? And if so, what direction
would you like to take? So far, my ideas have been very unpopular and I'm
growing weary fighting the current. How can
On Sunday, 1 February 2015 at 05:21:15 UTC, Mike wrote:
...
[2] - Why D is not a Systems Programming Language -
https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
I don't have much to add but this is one of the better critiques
of D I've seen.
This is related to the recent publication of D's H1 2015
Priorities [1], but I suspect this post could create a few
tangents, so I decided to post it under its own thread.
IMO D has high potential for kernel programming, embedded
systems, and other bare-metal varieties where high-level
101 - 140 of 140 matches
Mail list logo
