H1 2015 Priorities and Bare-Metal Programming

[Iain Buclaw via Digitalmars-d]

On 1 February 2015 at 09:38, Timo Sintonen via Digitalmars-d
<digitalmars-d at 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.