Martin,

This is a bit of a tangent, but I would like to know what your thoughts are on this: http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org

The problem is that when we use an unimplemented feature of D, the best we can hope for is to generate a linker error.  I proposed this idea as a way to make the conversation between the user and their druntime implementation more polished.  The runtime implementation, through its .di files informs the compiler and user what is and isn't supported so the user can get friendly compile-time errors and the compiler can make better assumptions about codegen.

Mike

On Thursday, 30 April 2015 at 11:30:33 UTC, Mike wrote:

>
> Starting from zero appeals to my way of thinking.  I've made several attempts at this both on the PC and for microcontrollers, so please allow me to offer my thoughts on the idea:
>
> While this may seem simple to achieve, I think it will raise a few questions that will need answering.
>
> * Can ModuleInfo be leveraged, without introducing overhead, to call module constructors and static constructors?  They might be useful for hardware initialization.

I think we should omit moduleinfo totally and so we can not have module constructors. I think pointers to static constructors are available in a certain section that I have not in my link script. Adding this section should make them available.

> * Is dynamic memory allocation a requirement of D, or a library feature?
We should agree whether we are making only yet another C compiler or do we want the D compiler. The ability to use object oriented features was the reason I started with D. I think we do npot need full gc but I want to create objects at least at start. they will live trough the program so I have no need to delete then.
I think it is possible to have the memory and object management things as set of files that may optionally compiled in or left out.  There must be better and smaller malloc programs than the one I use now.

> * Does D need the C runtime, or can it init on its own?
We should not depend on any libc. If we need anything from libc we must require/provide a multilib libc set that has been compiled with the correct compiler flags.

> * Should the C standard library bindings be part of the runtime, or exist as an external Deimos library?  Either way they can still be used by the runtime, I'm just suggesting that they should be encapsulated.
The bindings do not take space in the library but what are we doing with bindings if we do not have libc? I think it would be better to have a separate libc port project that contains the library and bindings.

> * What will be done about TypeInfo for now?  It's causing me some serious code-bloat problems.  See http://forum.dlang.org/post/quemhwpgijwmqtpxukiv@forum.dlang.org
I hope the compiler devs can tell us if it is possible to remove typeinfo totally and what language features we will lose then.

> * Is data and bss initialization part of  the runtime, or delegated to toolchain, silicon, and BSP vendors?

In C the data initialization is made before main. The copying is target independent but may depend on build environment, like what symbols the linker script provides. There is no general rule if any hardware specific init is needed at this point, before or after.
One thing that has not been mentioned yet is that D is using TLS by default. Tdata and tbss can be combined to global data and bss. However, it is not hard to make śeparate sections for them and be prepared to multithreaded system.

On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:
> On 04/30/2015 08:43 AM, Timo Sintonen wrote:
>> Printf is a little tricky. It is actually a file operation to stdout and
>> that is actually a syscall to kernel.
>
> No, you usually have to implement some hook for outputting yourself,
> e.g. putc or write, printf solely takes care of the formatting.

I repeat here that there are several output devices in a board at the same time like serial port and lcd display. Printf can not be bound to one device at compile time.
It is not hard to take the formatter out of printf and make it a separate interface that can be connected to different outputs. this way we do not need the libc dummies. I think this is more the D and object oriented way. A hook sounds too much C for me.

Even better would be a CTFE formatter. There was discussion about this last year. Anybody knows the state?

On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
>
> Most asserts on microcontrollers I've seen are just implemented as while(1){}
> -But one could probably also trigger the debugger (BKPT), HardFault or RESET if necessary.
> Perhaps the default could be while(1){} and then version(ASSERT_BKPT) could be used to add a breakpoint before that while(1){}. Thus --version=ASSERT_BKPT could be specified on the command-line.
> Would it be possible to 'extend' an existing assert; eg. the user might want to be notified via the U(S)ART ?

In a desktop computer it is easy to return to the system. A flying aeroplane can not stop its engines and wait the pilot to reboot...

We do have the 'weak' attribute now. Just make a weak default handler that stops. Then the application designer can override it with whatever the application needs.

Am Fri, 01 May 2015 06:57:07 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> I think we should omit moduleinfo totally and so we can not have module constructors. I think pointers to static constructors are available in a certain section that I have not in my link script. Adding this section should make them available.

C-like constructors. I've got some old code which allows attaching a
@attribute("cctor") to a extern(C) function to make it a C-constructor.
That code could be revived quickly if it's useful.

Outputting normal D module ctors as C-ctors is  possible but 'hacky': First, the calling convention doesn't match. In order to be compatible C-constructors should stay extern(C). Now extern(D/C) are actually the same for all GDC supported architectures, but still. There's also the issue that it's a semantic change as you can no longer rely on cycle detection.

TLDR: I'd prefer using @cctor extern(C) void foo() {} instead of normal
d module ctors.

Bonus points: You can have more than one @cctor per module.

On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
> On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
>> On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
>>> Thus I would expect the hook to be somewhere in vfprintf ?
>>
>> As Timo said, eventually, what printf needs is the `write` syscall.  The C library needs to be ported to the hardware in question.  That requires implementing all the syscalls the the C library needs:  `write` for printf, `sbrk` for malloc, etc... (http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c) Sometimes the toolchain vendors provide this, sometimes the programmer has to do it.
>
> Uhm, in that case, why not supply a weakref dummy, eg. functions that can be overridden.
> Thus stat, open, fstat, lseek, read, write, isatty, close, link and unlink just do nothing at all.
> If the MCU has a file-system, then it can implement those as strong refs.
> Same about gettimeofday, getpid, execve, fork, kill - Often there's only a single thread and no possibility for loading and executing a named program.
> -So it should be fairly easy to change newlib 'requirements' to 'optional'. :)
>
> I feel like trying this out, perhaps when the new light comes. ;)

Please do not make yet another c compiler. Make a D compiler.
File system support can be an option that can be selected. A file in D is an object. Try to think object oriented way.

On Friday, 1 May 2015 at 07:30:03 UTC, Timo Sintonen wrote:
> On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
>>
>> Most asserts on microcontrollers I've seen are just implemented as while(1){}
>> -But one could probably also trigger the debugger (BKPT), HardFault or RESET if necessary.
>> Perhaps the default could be while(1){} and then version(ASSERT_BKPT) could be used to add a breakpoint before that while(1){}. Thus --version=ASSERT_BKPT could be specified on the command-line.
>> Would it be possible to 'extend' an existing assert; eg. the user might want to be notified via the U(S)ART ?
>
> In a desktop computer it is easy to return to the system. A flying aeroplane can not stop its engines and wait the pilot to reboot...

The 'assert' is intended for debugging, right ?
If not enabling --version=ASSERT_LOOP, --version=ASSERT_BKPT, --version=ASSERT_RESET or any other version, then assert should simply default to an empty funciton.

Personally, I never ever used assert myself. I always handle the situation by making sure my data were in range; if they aren't, I correct them.

> We do have the 'weak' attribute now. Just make a weak default handler that stops. Then the application designer can override it with whatever the application needs.

Yes, of course. Why didn't I think of this ? :)

On Friday, 1 May 2015 at 07:44:49 UTC, Timo Sintonen wrote:
> On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
>> On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
>>> On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
>>>> Thus I would expect the hook to be somewhere in vfprintf ?
>>> Sometimes the toolchain vendors provide this, sometimes the programmer has to do it.
>>
>> Uhm, in that case, why not supply a weakref dummy, eg. functions that can be overridden.
{snip}
>> -So it should be fairly easy to change newlib 'requirements' to 'optional'. :)
>>
>> I feel like trying this out, perhaps when the new light comes. ;)
>
> Please do not make yet another c compiler. Make a D compiler.
> File system support can be an option that can be selected. A file in D is an object. Try to think object oriented way.

That would do nicely, but I was merely thinking about crippling the library so it does 'nothing'.

If we were simply to supply 'fopen' instead of 'open', returning an object would be fairly straightforward.

A hacky open could return a pointer to an object, because the returned value is a 32-bit integer, which is the same size as a pointer and:
    "If successful, open() returns a non-negative integer, termed a file
    descriptor.  It returns -1 on failure, and sets errno to indicate the error."

-That means though, that the RAM *must* be in the area 0x00000000 ... 0x7fffffff in order to satisfy the "non-negative integer" statement.

But it's of course not "pretty", and it would not be portable to a 64-bit system, if open does not return a 64-bit integer on those systems.

We could also keep returning a 'file number', then have a function, which found the FILE* (which is an object) for this 'file number'. This would most likely limit the number of files one can keep open simultaneously. The limit could be changed during startup.

The problem with these two implementations is that I don't use files in microcontrollers, so there will be cases where it's insufficient. But being able to open more than 1000 files simultaneously does not make much sense on a microcontroller, which has 64K RAM or less.

If anyone has a better suggestion, I'm ears all over the place.. I mean I'm all ears. ;)

On Friday, 1 May 2015 at 09:49:51 UTC, Jens Bauer wrote:
> A hacky open could return a pointer to an object, because the returned value is a 32-bit integer, which is the same size as a pointer and:

... would introduce a lot of dangling pointer errors instead of 'error: file not open'...

On Friday, 1 May 2015 at 07:15:58 UTC, Timo Sintonen wrote:
> I repeat here that there are several output devices in a board at the same time like serial port and lcd display. Printf can not be bound to one device at compile time.
> It is not hard to take the formatter out of printf and make it a separate interface that can be connected to different outputs. this way we do not need the libc dummies. I think this is more the D and object oriented way. A hook sounds too much C for me.

You can use std.format to get printf-style formatting and then pass the string to where you want.


> Even better would be a CTFE formatter. There was discussion about this last year. Anybody knows the state?

There are quite a few people who want a CTFE formatter, I believe, but that also has the issue of causing a lot of code bloat. Remember also that you *can* use std.format.format at compile time:

enum str = "This is a %s".format("test");