D: pay for what you use?

Thu Feb 13 13:36:59 PST 2014

On Thursday, 13 February 2014 at 21:35:27 UTC, tcak wrote:
> On Thursday, 13 February 2014 at 21:08:01 UTC, Mike wrote:
>> On Thursday, 13 February 2014 at 17:04:44 UTC, Rel wrote:
>>> 4) What compiler is better to use when I want to compile and 
>>> run D on "bare bones" (running code without operating 
>>> system)? Is it DMD? Or is it LDC? Or GDC?
>>
>> What's your target platform (x86, ARM, etc...)?  My platform 
>> is ARM Cortex-M bare metal.
>>
>> DMD doesn't support ARM.  LDC and GDC do to some extent.
>>
>> LCD crashed when I omitted some of the TypeInfo stuff.  A fix 
>> was created [1], but I'm waiting for it to be released in a 
>> binary with an ARM Thumb backend before I test it again.
>>
>> I'm currently using GDC, and am making good progress with it.  
>> I'm using the -fno-emit-moduleinfo switch and consider it 
>> essential for going minimal.
>>
>> My wiki describes everything I'm doing, and many of your 
>> questions will be answered there if you take the time to read 
>> through it [2].
>>
>>
>>> Hello! I really enjoy D and some brilliant concepts in the 
>>> language, like scope(exit) for example. But what I dislike 
>>> about D is the druntime, where each single function depends 
>>> on 100 other functions. I'd like to be able to develop system 
>>> level code in D (like windows drivers or linux kernel modules 
>>> or do osdev), but I can not do it, as D is very dependent on 
>>> the druntime. It would be great if D would have the same "pay 
>>> for what you use" way, as C/C++ do. So I'd like to ask 
>>> several questions:
>>
>> I'm doing just that.  My first step was to build a minimal 
>> "hello world" (no C, no runtime, no phobos).  I created a wiki 
>> post about it [3].  I've expanded on this in my repository's 
>> "hello world", and have been able to get it down to 56 bytes 
>> [4].
>>
>>>
>>> 1) Is it possible to fully disable exceptions? Generally I 
>>> tend not to use exceptions in C++ as well, as exception path 
>>> may take a whole lot of a time. Also returning error codes or 
>>> using something like Expected<T> is more readable in most 
>>> cases. Obviously I'm not going to use exceptions in my code, 
>>> and I won't be linking with code that throws/catches 
>>> exceptions.
>>>
>>
>> I don't think there's any way to prevent you from using 
>> exceptions except by not implementing the specific runtime 
>> hooks, and getting linker errors if you attempt to use 
>> exceptions.  I, for one, fully intend to use exceptions even 
>> though I'm targeting the most minimal of hardware.  I believe 
>> it is a useful idiom if used tastefully.
>>
>>> 2) Is it possible to fully disable runtime type information? 
>>> I understand that being able to get different information 
>>> about object type in the runtime may be very useful, but I've 
>>> never used it. However D compilers do generate RTTI-tables no 
>>> matter what with all class names, module names and etc.
>>
>> I use -ffunction-sections and -fdata-sections, in collusion 
>> with ld's --gc-sections to strip out stuff I'm not using.  
>> This can also be done with a custom linker script.  Again, my 
>> wiki describes this.
>>
>> To get GDC just to compile my code, I've had to stub out the 
>> TypeInfo stuff in object.d/di.  I have a 20 line object.d that 
>> allows me to declare structs [6].  With one or two more stubs, 
>> I can have classes with static properties.  I have the code, 
>> but I haven't checked it in yet.
>>
>> There was an excellent discussion about this on the forum [7].
>>  I encourage you to read it if you're really serious about 
>> your pursuit of this knowledge.
>>
>>>
>>> 3) Is it possible to fully disable garbage collection? 
>>> Sometimes having GC is a good thing, but I'd rather do manual 
>>> memory management or use automatic reference counting instead.
>>>
>>
>> If you throw away the runtime from the start, and pay as you 
>> go from there, yes.  That is the approach I have taken.  I 
>> have a malloc/free [8], and as far as I know its the only 
>> malloc written in D.  It's naive and not well tested, but 
>> working for what I need so far.
>>
>> I believe this could be used with the gcstub [14], but I 
>> haven't made it that far yet.
>>
>>>
>>> 5) Does anyone try to make a tiny druntime library? Did it 
>>> work out well for you? And can I have a look at it?
>>>
>>
>> Timo Sintonen's minlibd [9]
>> Vladimir Panteleev's SlimD [10]
>> Adam D. Ruppe's minimal D [11]
>> Daniel Murphy's microD [12]
>> Mine, which is hardly even started [13]
>>
>> Are there others?  Please let me know by posting a response.
>>
>>> PS I know that these kind of questions come out in the D 
>>> community from time to time, but there's a lot of things I'd 
>>> like to discuss on this subject, so I decided to make a new 
>>> thread... sorry...
>>
>> I wouldn't mind seeing more discussion and participation a 
>> bare metal D effort.  As you can tell by my verbose posts, I'm 
>> quite excited about it.
>>
>> Mike
>>
>> [1] https://github.com/ldc-developers/ldc/issues/551
>> [2] 
>> https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.0-Introduction
>> [3] 
>> http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22
>> [4] 
>> https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World! 
>> (watch the ending '!')
>> [5] http://wiki.dlang.org/Runtime_Hooks
>> [6] 
>> https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d
>> [7] 
>> http://forum.dlang.org/post/jynxfglpulguvqbivrms@forum.dlang.org
>> [8] 
>> https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/master/source/memory.d
>> [9] https://bitbucket.org/timosi/minlibd
>> [10] https://github.com/CyberShadow/SlimD
>> [11] http://arsdnet.net/dcode/minimal.zip
>> [12] https://github.com/yebblies/dmd/tree/microd
>> [13] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study
>> [14] 
>> https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
>
> I would like support for PIC 8bit/16bit/32bit as well, though 
> probably that will never happen. At least for 8bit and 16bit 
> PIC microprocessors.

* I meant PIC microcontrollers.