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, 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 I contribute in a way that >>> gets us >>> both where we want to go? >> >> >> I don't recall what you've suggested in this vein that was very unpopular >> - can you please post an example? > > > 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 serious programmer will write code that > way. It worked in 80's when we had an uart with three registers 8 bit each. > Now an usb or ethernet peripheral may have 100 registers 32 bit each. > > There are workarounds: > - disable optimization. the code works but is 3 times bigger and slower > - GDC marks shared variables as volatile. This works mostly but is > unstandard and unstable and may be removed at any time. > - Have an separate templated data type which has its own operators. While > this seems to work, it is a little complicated way to do things. > > ---- > There are some areas that might be developed. > > There are not many people here that work with microcontollers besides Mike > and I. Many people make just web services. This is ok, the business is > there. If bare metal is a goal for D then it is impostant that we processor > people do not feel ourselves as second class people. Our needs and concerns > should at least be noticed and respected by leaders. > > More practioal thing is the runtime library. Mike, Adam and some others have > started with empty runtime and added only what they need. This does not get > very far because mamy real D features need runtime functions. I may the only > one to start with full runtime and remove anything that does not work. I > have many D features working now, like exceptions. > > The runtime needs: > - NoSystem should be a supported platform and not a build failure. The build > system should leave out files and features that are not available. > - Unrelated things should be split in separate files and unnecessary imports > should be removed. Object.d is pulling in most of the library with its > imports. Imports that are used only in unittests should be in unittest > blocks. I know this is worked on. > - Runtime library functions should not use gc and free all resources they > use. I know this is also being worked on. >
Talk is cheap, need more actions. https://github.com/D-Programming-Language/dmd/pull/4367 https://github.com/D-Programming-Language/dlang.org/pull/881 Iain.