Re: H1 2015 Priorities and Bare-Metal Programming
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? 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? Mike once complained that the runtime heavily relies on some high-level OS features not available on embedded devices (e.g. threads). That's OK if you actually have an OS, but druntime should be modular enough to run on systems without thread support. 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. 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 for little benefit. Obviously bare-metal programmers might disagree on the little benefit part and as Mike points out rust seems to do similar things.
Re: H1 2015 Priorities and Bare-Metal Programming
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 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? Mike once complained that the runtime heavily relies on some high-level OS features not available on embedded devices (e.g. threads). That's OK if you actually have an OS, but druntime should be modular enough to run on systems without thread support. The core library part needs some love in this respect. But I feel at least the rt and gcc library in GDC allow easier transition. For instance, I'm still happy at how gcc.gthreads is handled and how you can control the thread support at configure time - despite being only used in rt.monitor_ and rt.criticial_. https://github.com/D-Programming-GDC/GDC/blob/61682dd6adada34bc5bbff5903954a6af45cca92/libphobos/configure.ac#L342 https://github.com/D-Programming-GDC/GDC/tree/master/libphobos/libdruntime/gcc/gthreads Though it's clearly not enough, and I think there should be a push for more configurations here: https://github.com/ibuclaw/GDC/blob/9e03425dd5b3229d9333837631d19ad2d5c9b150/libphobos/libdruntime/gcc/config.d.in Iain
Re: H1 2015 Priorities and Bare-Metal Programming
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. 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 These are for GDC 2.065 and some of these may have changed when GDC 2.066 is out. In addition, I still need my own build system to select files and to compile with correct processor options. My skills are not enough to modify the original build system.
Re: H1 2015 Priorities and Bare-Metal Programming
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.
Re: H1 2015 Priorities and Bare-Metal Programming
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): https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
Re: H1 2015 Priorities and Bare-Metal Programming
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 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. 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 and 64 bit loads and stores. 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. I don't see the need for any of these workarounds. The compiler intrinsics are volatile, i.e. they are not optimized away even when optimization is turned on. 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. 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 The link does not work. I have added https://issues.dlang.org/show_bug.cgi?id=14100 and have also added the bare-metal keyword. Please enumerate the issues you're having, file them on bugzilla, and tag them with bare-metal.
Re: H1 2015 Priorities and Bare-Metal Programming
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): https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default And, for info, pasted here: This file is not a changelog. Instead, this file documents changes that are needed to the current gdc libdruntime sources. (2.065 and 4.10 series gdc/gcc) The files are in the order they were needed when testing core/stdc/stdlib.d 49 default value for RAND_MAX instead of assert core/memory 84-85,123 changed private imports to public gcstub/gc.d 31 removed import stdio 134 removed thread_init object.d 30 removed import minfo 132-142removed factory (moduleinfo is not used) 562renamed GC.free gc_free (core.memory not used) 604-657removed associative arrays 858-873removed module related code 1561-1732 removed moduleinfo 1733-1932 removed monitor 1933-2283 removed assicoative arrays 2257,2262 changed comment to /* */ core/exception.d 14 removed import stdio 593-596,610-613,627-630,639-642 removed module related functions rt/lifetime.d 246,278,310 removed synchronized 1222-122removed monitor call rt/adi.d 46-134 removed _adReverseChar (because utf is not supported) 95-96 changed comment to // 320-360 removed _adSortChar and _adSortWchar because of several missing functions core/time.d (optional file) 23 removed import stdc.time 24 removed import stdio 2125 dummy retval for the function PS I have no connection with the OP.
Re: H1 2015 Priorities and Bare-Metal Programming
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.
Re: H1 2015 Priorities and Bare-Metal Programming
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 volatile' type. How could it not be? It's just *(volatile T*)ptr = value; - which gcc ir can obviously express.
Re: H1 2015 Priorities and Bare-Metal Programming
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!
Re: H1 2015 Priorities and Bare-Metal Programming
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 leave out files and features that are not available. I really like this notion that not defining a system (or defining a special one) builds a minimal freestanding implementation. Andrei
Re: H1 2015 Priorities and Bare-Metal Programming
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 one who compared the languages and I have never used rust or nim. I just pointed out that d had no way to access registers properly. DMD and GDC optimize very heavily and may cache, reorder and remove any access they think is not needed. Other languages may not have such optimizations and registers can be accessed just with normal memory oprations.
Re: H1 2015 Priorities and Bare-Metal Programming
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 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 one who compared the languages and I have never used rust or nim. I just pointed out that d had no way to access registers properly. DMD and GDC optimize very heavily and may cache, reorder and remove any access they think is not needed. Other languages may not have such optimizations and registers can be accessed just with normal memory oprations. How do volatileLoad() and volatileStore() in core.bitop fail to meet such needs? -- Andrei 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. Iain. I believe the litmus test was to create a library struct Volatile(T) type.
Re: H1 2015 Priorities and Bare-Metal Programming
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. I'll have to check whether or not the proposed implementation in gdc is even viable vs. having a 'C volatile' type. How could it not be? It's just *(volatile T*)ptr = value; - which gcc ir can obviously express. Depends on how you represent it. :) I believe the correct way would be mem_ref[(volatile T*) ptr] = value; Miss a propagation of volatile or side_effects flag setting though, then *poof* the volatility is gone. Iain.
Re: H1 2015 Priorities and Bare-Metal Programming
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 provide for such? Andrei I was not the one who compared the languages and I have never used rust or nim. I just pointed out that d had no way to access registers properly. DMD and GDC optimize very heavily and may cache, reorder and remove any access they think is not needed. Other languages may not have such optimizations and registers can be accessed just with normal memory oprations. How do volatileLoad() and volatileStore() in core.bitop fail to meet such needs? -- Andrei
Re: H1 2015 Priorities and Bare-Metal Programming
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 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 one who compared the languages and I have never used rust or nim. I just pointed out that d had no way to access registers properly. DMD and GDC optimize very heavily and may cache, reorder and remove any access they think is not needed. Other languages may not have such optimizations and registers can be accessed just with normal memory oprations. How do volatileLoad() and volatileStore() in core.bitop fail to meet such needs? -- Andrei 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. Iain.
Re: H1 2015 Priorities and Bare-Metal Programming
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 for little benefit. Interesting. I naïvely believe it would simplify rather than complicate the compiler. -- Andrei
Re: H1 2015 Priorities and Bare-Metal Programming
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 counterarguments. Because http://wiki.dlang.org/DIP56 generated nothing but controversy.
Re: H1 2015 Priorities and Bare-Metal Programming
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 and 64 bit loads and stores. I think everybody agreed that these low-level primitives can't be used in end-user code. I apparently missed that discussion. (In any case, dealing with memory mapped I/O is not a usual programming task, I expect a programmer doing it will be more sophisticated.) We can generate nice wrappers (nicer than C code), which perform as well as C code, but only with force-inline _and_ enabled optimizations (we essentially need heavy constant folding). The compiler intrinsics participate in all optimizations. We also need a pragma(address) to complement pragma(mangle). What would that do? * Using only part of druntime is ugly. The one thing most people would probably like to strip out is the GC, but keep exception handling, threads, ... But the GC is everywhere: core.demangle doesn't work without, backtraces, exceptions, threads. Right now you either use all of druntime or nothing but it's not possible to use parts of druntime only, it's not modular enough. De-Modularity is one of those things that one has to continually fight, like mildew in the shower. Turn your back on it for a moment, and interdependence creeps back in.
Re: H1 2015 Priorities and Bare-Metal Programming
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 of the language? I'm not sure of anything else that has been repeatedly asked for without any good counterarguments. Because http://wiki.dlang.org/DIP56 generated nothing but controversy. It is not really the best wording with many people disagreed with what I wanted and I didn't consider anything else Not agreeing with something != not considering it
Re: H1 2015 Priorities and Bare-Metal Programming
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 specifically not the case with compiler intrinsics volatileLoad() and volatileStore(). Other languages may not have such optimizations and registers can be accessed just with normal memory oprations. The trouble with those is when memory mapped registers have specific behaviors based on how and when read/write cycles occur. Many instructions are implicitly read-modify-write, and may not offer sufficient control. volatileLoad() and volatileStore() make the read/write operations and cycles explicit, even in the presence of aggressive optimizations.
Re: H1 2015 Priorities and Bare-Metal Programming
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 intrinsics into volatile C accesses. I presume gdc and ldc could do the same.
Re: H1 2015 Priorities and Bare-Metal Programming
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 for doing this. This is great material. I'll respond more in depth later.
Re: H1 2015 Priorities and Bare-Metal Programming
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 gdc is even viable vs. having a 'C volatile' type. dmd actually translates those intrinsics into volatile C accesses. I presume gdc and ldc could do the same. For whatever reason, the PR I've got used artificial functions to solve the problem. Volatile accesses should work, it's just an implementers note to remember to propagate volatile from type to expression, and don't forget to mark it as having side effects. The work you have to do just to prevent the compiler from optimising. :)
Re: H1 2015 Priorities and Bare-Metal Programming
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 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 initiated. 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 for little benefit. Obviously bare-metal programmers might disagree on the little benefit part and as Mike points out rust seems to do similar things. We did something similar with the GC info, i.e. RTinfo. I think the same technique could be use for TypeInfo.
Re: H1 2015 Priorities and Bare-Metal Programming
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 initiated. 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 this in more detail though before I start spouting ideas. But I certainly welcome the dialogue. 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 for little benefit. Obviously bare-metal programmers might disagree on the little benefit part and as Mike points out rust seems to do similar things. We did something similar with the GC info, i.e. RTinfo. I think the same technique could be use for TypeInfo. I think Adam may have it right with Issue 12270 [1]. But I reject the notion that TypeInfo is a baked-in feature of the language, and if one want to eat the oatmeal cookie, they have to eat the raisins too. Mike [1] - Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270
Re: H1 2015 Priorities and Bare-Metal Programming
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 recall such. Yah, I must chime in here. I'm a bit surprised by Mike's conclusion that he's been rejected. I assume Mike is Michael V. Franklin who gave the talk at https://www.youtube.com/watch?v=o5m0m_ZG9e8. I think that's an awesome talk and awesome work. Now when I saw his list of grievances today, I was bummed that it didn't include a bunch of stuff that I can act on. It's just not my specialty, and I can't spread myself too thin. I know Walter is a good match for that, and I'm glad he acted on it. 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 would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't. The vision document also doesn't include things we believe are implied. For example D should remain an efficient, systems-level language. To the extent D prevents systems-level work from getting done, we should fix it to allow that to happen. Again, I'm glad folks like Walter and Iain have an eye on that. Andrei
Re: H1 2015 Priorities and Bare-Metal Programming
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 anything else that has been repeatedly asked for without any good counterarguments. Because http://wiki.dlang.org/DIP56 generated nothing but controversy. It is not really the best wording with many people disagreed with what I wanted and I didn't consider anything else
Re: H1 2015 Priorities and Bare-Metal Programming
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 posted, you'll see that indeed they are. They were indeed criticized, but it is the lack of interest that is most discouraging. I don't necessarily feel rejected. Rather, I see that D is heavily biased towards a few specific domains, and I think D has more potential than that. So, I suggest the stewards of the language guard against any trend to make the language too domain- or platform-specific. I also said at the start of this thread that I'm ok with abandoning my ideas, as long as the core team expresses interest and a way forward that I can get on board with. I assume Mike is Michael V. Franklin who gave the talk at https://www.youtube.com/watch?v=o5m0m_ZG9e8. Actually, I was so excited about D, I changed my name to Michael D. Franklin: https://archive.org/details/dconf2014-day02-talk07 There's a lot of stuff that Walter and I would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't. The vision document also doesn't include things we believe are implied. For example D should remain an efficient, systems-level language. To the extent D prevents systems-level work from getting done, we should fix it to allow that to happen. Again, I'm glad folks like Walter and Iain have an eye on that. This is exactly the information I hoped to elicit in this thread. If there is interest in hardware programming, let's discuss a way forward. If the core team already has its hands full, that's fine too. Perhaps, it's best for me to reallocate myself elsewhere and revisit D at a later time. But I don't want to remain on the fence. Mike
Re: H1 2015 Priorities and Bare-Metal Programming
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 this in more detail though before I start spouting ideas. But I certainly welcome the dialogue. You can use __gshared to not get TLS, and a freestanding implementation doesn't necessarily imply no threads. Back in C land, I have some experience in making code that is buildable for both single and multi thread. The result wasn't worth it (bugs and complexity) - it was far better to always build for multi thread and have a runtime adapt itself for single thread dynamically.
Re: H1 2015 Priorities and Bare-Metal Programming
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. Perhaps I can solve this in my runtime implementation and/or linker scripts, but I need to study the implementation more. Another problem I forgot to mention is someone would inevitably try to link together a single thread build with a multi thread build, and then would be flummoxed by the problems it caused. Just go with __gshared.
Re: H1 2015 Priorities and Bare-Metal Programming
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 assert(PORTB == cast(ubyte*)0x0025); This is a much nicer version of C's #define PORTB (*(volatile unsigned char *)0x0025)
Re: H1 2015 Priorities and Bare-Metal Programming
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 would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't. Added to Wiki.
Re: H1 2015 Priorities and Bare-Metal Programming
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 lived threads. But the overhead of TLS is not appropriate for an ISR that demands low latency. `shared`, on the other hand, might be more appropriate. Perhaps a compiler error should be emitted if an ISR attempts to access state not decorated with `shared`. But then the language needs some way to identify ISRs, yes? it was far better to always build for multi thread and have a runtime adapt itself for single thread dynamically. 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. Perhaps I can solve this in my runtime implementation and/or linker scripts, but I need to study the implementation more. Mike
Re: H1 2015 Priorities and Bare-Metal Programming
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 would like to see happen that's not in the document. The document itself includes things that he and I actually believe we can work on and make happen. (In the case of vibe.d, we made sure we asked Sönke.) It doesn't include awesome things that others can do without our help - and it shouldn't. Yes, this needs to be emphasized, as it isn't obvious that you limited it only to stuff that you and Walter can personally enable. Perhaps you can expand the wiki page with a section for stuff that you two would like to see, but cannot personally enable. Historically, the D community has been horrible at communicating goals like this, with all current efforts buried in miles of mailing list threads that few outsiders are ever going to wade through, if that. By putting these goals on the wiki, even if you can't personally enable them, someone might see a goal, decide they'd like to have that too, and start working on it, secure in the knowledge that it's wanted and is likely to be merged if certain quality standards are met. I suggest you add another clearly labeled section with such goals, what you would like to see happen but cannot work on and make happen. The community might pick those up and run with them without you.
Re: H1 2015 Priorities and Bare-Metal Programming
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, 0x0025)
shared ubyte PORTB;
static assert(PORTB == cast(ubyte*)0x0025);
This is a much nicer version of C's
#define PORTB (*(volatile unsigned char *)0x0025)
That's what I suspected :-)
struct Ports {
static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025, value); }
}
...
Ports.B = 7;
foo(Ports.B);
gets the job done. Of course, you could take it further and make a template out
of it:
auto Ports = Port!(ubyte, 0x0025);
Re: H1 2015 Priorities and Bare-Metal Programming
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?
It would allow naming a memory address, similar to using .org in
assembly.
eg
pragma(address, 0x0025)
shared ubyte PORTB;
static assert(PORTB == cast(ubyte*)0x0025);
This is a much nicer version of C's
#define PORTB (*(volatile unsigned char *)0x0025)
That's what I suspected :-)
struct Ports {
static ubyte B() { return volatileLoad(cast(ubyte *)0x0025); }
static void B(ubyte value) { volatileStore(cast(ubyte *)0x0025,
value); }
}
...
Ports.B = 7;
foo(Ports.B);
gets the job done. Of course, you could take it further and make a
template out of it:
Where is the @property? :)
Iain.
Re: H1 2015 Priorities and Bare-Metal Programming
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?
Re: H1 2015 Priorities and Bare-Metal Programming
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.
H1 2015 Priorities and Bare-Metal Programming
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 language features are often not needed or even wanted (but sometimes used). D has some fantastic features for low-level programming with great power and convenience, but it is currently heavily biased towards platforms with a full-featured, resource abundant operating system, and some of it's high-level features get in the way. Periodically, users pop into the forum, ask questions this, give it a try, and then leave [2]. There has been the occasional suggestion for a -minimalD compiler flag or some other twist, but IMO that's not a very elegant or appropriate solution. I think Rust is headed in a better direction with it's minimal runtime philosophy [3] and features like #![no_std], #![feature(lang_items)], #[lang = whatever], and extern rust-intrinsic [4]. I'm not suggesting D mimic Rust's approach, but rather learn from it, and provide an attractive alternative that jives with D's way of doing things. However, when I read Foster library additions over language changes, and raise the bar on language changes, I suspect changes to accommodate this kind of programming will be viewed as shuffling the deck. So, I'm currently on the fence with D. Rust and Nim are showing great promise in this domain, Rust has already implemented supporting features (as mentioned above), and Rust's Zinc project [5] is really catching on. Is D's core team genuinely interested in this domain? 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? If you're not particularly interested in this domain, that's OK. Perhaps you are interested, but not at this time. Perhaps you are only interested in mobile and mico-PC platforms that have full-featured operating systems, but not resource constrained bare-metal platforms. Whatever the case, please let it be known. Thanks in advance for your constructive comments, Mike [1] - 2015 H1 Vision - http://forum.dlang.org/post/majurl$2457$1...@digitalmars.com [2] - Why D is not a Systems Programming Language - https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md [3] - Rust Programming Language - http://www.rust-lang.org/ [4] - Writing Safe Unsafe and Low-Level Code in Rust - http://doc.rust-lang.org/0.11.0/guide-unsafe.html [5] - Zinc, the bare metal stack for rust - https://github.com/hackndev/zinc
