On 07/01/14 03:50, Andrei Alexandrescu wrote:
> On 1/6/14 4:22 AM, Mike wrote:
>> On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
>>> I'm trying to do the same, trying to compile OS free code but I
>>> haven't so far been successful because D requires the runtime and then
>>> also Phobos. Compared to C/C++ where you can create pretty advanced
>>> stand alone code without even include any standard libraries, this
>>> because much of C++ is part of the compiler.
>>
>> I created a bare-metal freestanding (OS Free) hello world program and
>> wrote a wiki about it here
>> (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22)
> [snip]
>
> Sounds like a good topic for a DConf talk. You may want to consider submitting one.

Yes, please.  It's not my personal area of work, but I'd be _really_ interested in seeing a good talk on embedded/from the ground up D -- and it will certainly be of professional interest to friends and colleagues of mine.

Am Tue, 7 Jan 2014 22:08:54 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> > >Even the switch...case statement seems to be, at least partially, implemented in the runtime
> > 
> > Yea, for strings. My thing did a stupid loop for string cases :P
> 
> Isn't that what the druntime string switch function does too? :-P Last I checked, it was also using a linear search through the cases.
> 

But IIRC druntime does some UTF normalization or something on strings or was that only for foreach over strings? D's 'UTF support' is a little to heavy for small runtimes. We need to make that opt-out for the runtime as I suggested in this reply:

http://forum.dlang.org/thread/fdsovuxnffmnpqhfmpts@forum.dlang.org?page=6#post-lajpgk:242jkc:241:40digitalmars.com

Am Wed, 08 Jan 2014 13:31:07 +0000
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> On Wednesday, 8 January 2014 at 07:57:29 UTC, Jacob Carlborg wrote:
> > Even if the struct isn't used or void-initialized?
> 
> Yeah.

The compiler can not know that a struct isn't used/void initialized. With separate compilation TypeInfo is output in object A.o and could be used from any other object. So only the linker actually knows for sure if the TypeInfo is used (There are exceptions where even the linker can't know that. Think of dynamic libraries).

There are 2 ways to solve this:
* Disable TypeInfo globally, everywhere (useful for embedded systems)
* Disable TypeInfo for specific types using some kind of annotation in
  the source code (pragma, UDA). This way the compiler knows if a type
  has TypeInfo or not and can complain if it'd need TypeInfo

On Wednesday, 8 January 2014 at 15:05:56 UTC, Johannes Pfau wrote:
> IIRC Andrei wants _d_newclass to be independent of ClassInfo anyway (by making it a template).

me too

> Runtime variadic arguments need typeinfo IIRC. We'd have to ban calling those functions with -fno-typeinfo or if any of the arguments

...you know, they don't strictly *need* the data. Most variadic args are checked by doing if args[1] == typeid(int)... which is just a magic number comparison.

The actual classes and other info aren't needed. (Indeed, I think the classes aren't needed anyway since we can get that info through __traits anyway nowadays. In fact in my minimal.zip thing I have a template that makes typeinfo objects out of trait info to prove it.)

On Wednesday, 8 January 2014 at 15:21:21 UTC, Johannes Pfau wrote:
> But IIRC druntime does some UTF normalization or something on strings or was that only for foreach over strings?

No, all it does is if you ask for foreach(dchar c; string){}, it will decode the multi-byte sequences. This does not require druntime, the compiler just outputs the code for it.

Decoding the multi byte sequences isn't much code, it is just some loads, shifts, and bit masks. Fairly lightweight.

Am Wed, 08 Jan 2014 15:59:25 +0000
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> On Wednesday, 8 January 2014 at 15:21:21 UTC, Johannes Pfau wrote:
> > But IIRC druntime does some UTF normalization or something on strings or was that only for foreach over strings?
> 
> No, all it does is if you ask for foreach(dchar c; string){}, it will decode the multi-byte sequences. This does not require druntime, the compiler just outputs the code for it.

Are all the aApplay methods deprecated then? See https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aApply.d

which also imports rt.util.utf.

> 
> Decoding the multi byte sequences isn't much code, it is just some loads, shifts, and bit masks. Fairly lightweight.

But it is _some_ code. It's always a matter of perspective, but on a 8bit AVR with 4-16KB for code you probably don't want to implement these functions in the runtime. Instead you just want the compiler to complain if someone does foreach(dchar, "string"). If this is really needed on small systems it's always possible to implement a range to do this:

foreach(dchar x; decode("string"))


Don't get me wrong, I think this is just fine in normal D, but in embedded D it would be nice if the runtime could disable that feature.

On Wednesday, 8 January 2014 at 16:22:55 UTC, Johannes Pfau wrote:
> Are all the aApplay methods deprecated then? See
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aApply.d

Oh, oops, you are right, my link command was pulling that in. Here's the correct thing:

test.d:(.text._D4test9write_rawFxAaZv+0x39): undefined reference to `_aApplycd1'


> But it is _some_ code.

Yeah, and since you're right about it needing a runtime function, as long as you use the correct linker command the function will not be found.


I like the link errors more than compile errors btw because that makes it easy to opt-in to these things if you do want them: simply implement the missing function.

My question is what do all these TypeInfo and ModuleInfo have to do with operating systems? Assuming that TypeInfo and ModuleInfo has really nothing to do with the OS, I see no problem with it. Sure it is nice to be able to remove it for certain embedded system where size is critical but for many embedded systems this is not necessary. Why remove key parts of the language when it is the OS dependency that is the problem?

My view is that there is no clear distinction what is independent of the operating system and what is operating system dependent in the runtime. What is part of the langauge and what is not?

On Wednesday, 8 January 2014 at 15:05:56 UTC, Johannes Pfau wrote:
> I think there are three steps to make TypeInfo completely optional
>
> * -fno-typeinfo as a global switch instructing the compiler that it
>   _never_ has typeinfo and should never output typeinfo. In this case
>   all files must be compiled consistently with -fno-typeinfo or without
>   it
>   Useful to disable all TypeInfo generation even if the runtime has
>   typeinfo support
> * pragma(notypeinfo)/@attribute(notypeinfo) as in LDC
>   Useful to exclude typeinfo for specific types
> * A way for the runtime to say 'I don't support TypeInfo'
>   Basically introducing 'core.config' with 'enum
>   RuntimeSupportsTypeInfo = false;'. If the compiler finds this
>   declaration it should automatically use '-fno-typeinfo'

This has been an interesting discussion, and has cause me to come full circle with a different perspective.

First, I want to dispell a potential myth:  "If we don't elminate TypeInfo stuff we'll have code bloat"
This is not true if compiling with -ffunction-section, -fdata-sections, and linking with --gc-sections.  All the TypeInfo stuff will eventually just get stripped out by the linker, as long as it's not used by the program.  However, the compilers will have to generated code that can be safely --gc'ed.  GDC, at the moment, doesn't.  I need to minimize my code and report an issue on this.  It's first on my list, so please stand by.  Discussion here (http://forum.dlang.org/post/wrekpqefiswstqhhrhoh@forum.dlang.org).

As long as the TypeInfo and other unused stuff can be safely --gc'd, D will be suitable for the tiniest of microcontrollers.

"So what's the problem?", you might ask.
The problem is really convenience.  I want to make a simple 10-line "Hello World" with a struct containing 1 measly property, and I have to create 1000 lines of runtime stuff just to get it to compile.  And worst of all, none of that runtime stuff has any hope of every being called, and --gc-sections discards it anyway.  How unfortunate!

Actually, for the aforementioned contrived example, it's only about 150 lines in GDC at the moment, but LDC appears to be much more (LDC folks, I'll make an issue report soon.  It's second on my list).

So, why would one want to make a "Hello Word" program with a single struct containing 1 measly property?  Answer: to learn.  But in the end, after one learns the runtime and adds all of the features they want, what will the end up with?... A 10,000 line runtime with all the TypeInfo stuff and more...and they'll be really happy with it.  And worst of all, the -fno-typeinfo switch that they were using while they were learning, was removed from their makefile in the first month of study.

"So, what's the REAL problem?", you might ask.
Answer: Lack of information about the runtime. e.g. no porting guide and a tightly-coupled hairball of d runtime with very little modularity, and very little platform, hardware, and feature abstraction.  I now think that parts of this current conversation would not even exist had this information existed.

There doesn't seem to be much interest from the runtime folks in doing something about this, so I intend to.  The porting guide is 3rd on my list.  And it's going to stink, because I don't know what I'm doing yet.  But maybe people irritated by the smell will help clean it up.

I think the -fno-typeinfo switch and the other proposed changes will be quite useful for the student of D and the D runtime, but I think they will only be used temporarily in their initial study.  I'm not voting against it, but I'm beginning to see it as not-so-important.  Maybe others have different needs for it than I, and it may be useful to them.

I'm quite thankful however, for the engligtening discussion, and the willingness to be so accomodating.  Thank you!

>> I think the best logical steps to go down, is that you should write a
>> replacement for the core library functions that the compiler
>> implicitly calls (_d_arrayliteralX, _d_arraycopy, _d_newclass,
>> _d_newitemT, etc), but omit using the TypeInfo parameter.  Once you
>> feel that it is ready, then we can add a switch into the compiler
>> that:
>> 1) Doesn't generate typeinfo
>> 2) Passes a null pointer as the typeinfo parameter to the Druntime
>> library calls.
>> 
>
>> Object _d_newclass(const ClassInfo ci)  ->  Object _d_newclass()
>> 
> IIRC Andrei wants _d_newclass to be independent of ClassInfo anyway (by
> making it a template). I think this came up when we talked about
> replacing 'new' with a library template or in a custom allocator
> discussion or something.

A templated _d_newclass, and possibly other runtime hooks would help greatly with the tight-coupling of the runtime.  It's not fourth on my list, yet, but it could use an issue report.

On 2014-01-08 16:25, Johannes Pfau wrote:

> The compiler can not know that a struct isn't used/void initialized.
> With separate compilation TypeInfo is output in object A.o and could be
> used from any other object. So only the linker actually knows for sure
> if the TypeInfo is used (There are exceptions where even the linker
> can't know that. Think of dynamic libraries).

Right, separate compilation always ruins the day :(

-- 
/Jacob Carlborg