H1 2015 Priorities and Bare-Metal Programming

[Timo Sintonen via Digitalmars-d]

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.