On 5 May 2015 at 19:38, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> I would probably split the runtime into at least two, probably three parts:
>
> * Compiler support library (object.d, gcc/*.d, exception
>   implementation) (module rt/ no module name)
> * Higher level library (portable, micro)
> * Hardware specific library (not portable, avr/ stm/)
>
> I think some basic portability between microcontrollers is useful. The compiler support library should be only a few 100 lines of code and should be without external dependencies. This way it's also useful for very small platforms (8bit) or use-cases where you inject code into other processes. It's trivial to port: we should have an ansi-c port and native ports should be implementable in 1-2 hours.
>

It should also be possible for compilations to succeed without rt/typeinfo - and for the compiler to not assume they exist (Type::builtinTypeInfo).

On Tuesday, 5 May 2015 at 18:13:03 UTC, Iain Buclaw wrote:

>
> It should also be possible for compilations to succeed without
> rt/typeinfo - and for the compiler to not assume they exist
> (Type::builtinTypeInfo).

That would also be most welcome.

On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
> Am Tue, 05 May 2015 08:41:13 -0700
> schrieb Dan Olson <zans.is.for.cans@yahoo.com>:
>
>> Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> writes:
>> 
>> > If the cost is too much (ie: there is no heap), then we should be
>> > able to stop emutls from kicking in by preventing the D frontend
>> > from returning true on isThreadLocal calls.
>> 
>> Iain, I think something like this would be good in GDC.  Makes it so
>> much easier to compile for no thread environments.
>
> I'm not really sure about this. It's trivial to implement but it
> generates a semantic difference which harms code portability (e.g. if
> you have code where you want a global variable, don't mark it as
> __gshared and then move to an environment with threads).

I'm coming around and feeling inclined to agree with this.  One of the things I want to avoid is creatIng an embedded dialect of the D.  I hope D for microcontrollers, kernels and such looks very much like the idiomatic D in the application programming domain.

What I would like to see, however, is a friendly compiler error like "This platform does not support thread-local storage.  Please decorate your global variables with __gshared." rather than "undefined reference '_d_get_address'" from the linker.


Mike

Maybe it's stupid question, but is there any chance to get D on AVR(8/16 bit)?

Am Wed, 06 May 2015 04:47:53 +0000
schrieb "Suliman" <evermind@live.ru>:

> Maybe it's stupid question, but is there any chance to get D on AVR(8/16 bit)?

Yes! I've written small D test programs for AVR.

The only problem could be far pointers. However, far pointers are very rare in AVR code and it's hard to find documentation. It seems there's no compiler support for far pointers and everything is implemented in the library[1]. In that case there's no issue for D.

[1] http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

Am Wed, 06 May 2015 02:44:53 +0000
schrieb "Mike" <none@none.com>:

> On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
> > Am Tue, 05 May 2015 08:41:13 -0700
> > schrieb Dan Olson <zans.is.for.cans@yahoo.com>:
> >
> >> Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> writes:
> >> 
> >> > If the cost is too much (ie: there is no heap), then we
> >> > should be
> >> > able to stop emutls from kicking in by preventing the D
> >> > frontend
> >> > from returning true on isThreadLocal calls.
> >> 
> >> Iain, I think something like this would be good in GDC.  Makes
> >> it so
> >> much easier to compile for no thread environments.
> >
> > I'm not really sure about this. It's trivial to implement but it
> > generates a semantic difference which harms code portability
> > (e.g. if
> > you have code where you want a global variable, don't mark it as
> > __gshared and then move to an environment with threads).
> 
> I'm coming around and feeling inclined to agree with this.  One of the things I want to avoid is creatIng an embedded dialect of the D.  I hope D for microcontrollers, kernels and such looks very much like the idiomatic D in the application programming domain.
> 
> What I would like to see, however, is a friendly compiler error like "This platform does not support thread-local storage. Please decorate your global variables with __gshared." rather than "undefined reference '_d_get_address'" from the linker.
> 
> 
> Mike

That's easy: https://github.com/D-Programming-microD/GDC/commit/d5677e03f40f4eb548e520728c5071a0b4445d24

(Well, the error message could be a little bit friendlier ;-)

>Yes! I've written small D test programs for AVR.
you mean 8-bit AVR? It's very cool! Could you show sources code example?

On Wednesday, 6 May 2015 at 07:20:38 UTC, Johannes Pfau wrote:

>> 
>> What I would like to see, however, is a friendly compiler error like "This platform does not support thread-local storage.  Please decorate your global variables with __gshared." rather than "undefined reference '_d_get_address'" from the linker.
>> 
>> 
>> Mike
>
> That's easy:
> https://github.com/D-Programming-microD/GDC/commit/d5677e03f40f4eb548e520728c5071a0b4445d24
>
> (Well, the error message could be a little bit friendlier ;-)

You know, that fork of yours has some really interesting stuff in it :0

The -ftls-support option would be really great, but I'd call it -fno-tls :)

I think such an option would be most useful at configure-time.  That is, if GDC is configured with --disable-tls or --disable-threads, then -fno-tls is ON by default.  That way it's more a definition of the target platform than user choice.

And now that I think of it, tying some of those compiler options to the configure options might be a better way to define platform support rather than reading .di files or enums from a special "configuration" module.

Mike

On Tuesday, 5 May 2015 at 08:13:21 UTC, Mike wrote:
> On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote:
>
>>
>>> LDC Folks:  https://github.com/ldc-developers/ldc/issues/781 is
>>> currently preventing me from supporting LDC with this runtime.
>>
>> I looked at this and found a workaround and noted it in the above issue
>> link.
>
> Many Thanks!
>
> I've gotten further thanks to your help, but now I'm stuck on
> https://github.com/ldc-developers/ldc/issues/925.
>
> Mike

I've gotten even further thanks to everyone's help, but LDC is still giving me a little grief.  Take a look at these undefined references (abbreviated for this forum):

(_D10TypeInfo_l6__vtblZ+0x8): undef ref `_D6object8TypeInfo8toStringMxFNaNbNfZAya'
(_D10TypeInfo_l6__vtblZ+0x10): undef ref `_D6object8TypeInfo6toHashMxFNbNeZm'
(_D10TypeInfo_l6__vtblZ+0x18): undef ref `_D6object8TypeInfo5opCmpMFC6ObjectZi'
(_D10TypeInfo_l6__vtblZ+0x20): undef ref `_D6object8TypeInfo8opEqualsMFC6ObjectZb'
(_D10TypeInfo_l6__vtblZ+0x28): undef ref `_D6object8TypeInfo7getHashMxFNbNexPvZm'
(_D10TypeInfo_l6__vtblZ+0x30): undef ref `_D6object8TypeInfo6equalsMxFxPvxPvZb'
(_D10TypeInfo_l6__vtblZ+0x38): undef ref `_D6object8TypeInfo7compareMxFxPvxPvZi'
(_D10TypeInfo_l6__vtblZ+0x40): undef ref `_D6object8TypeInfo5tsizeMxFNaNbNdNiNfZm'
(_D10TypeInfo_l6__vtblZ+0x48): undef ref `_D6object8TypeInfo4swapMxFPvPvZv'
(_D10TypeInfo_l6__vtblZ+0x50): undef ref `_D6object8TypeInfo4nextMNgFNaNbNdNiZNgC8TypeInfo'
(_D10TypeInfo_l6__vtblZ+0x58): undef ref `_D6object8TypeInfo4initMxFNaNbNiNfZAxv'
(_D10TypeInfo_l6__vtblZ+0x60): undef ref `_D6object8TypeInfo5flagsMxFNaNbNdNiNfZk'
(_D10TypeInfo_l6__vtblZ+0x68): undef ref `_D6object8TypeInfo5offTiMxFZAxS6object14OffsetTypeInfo'
(_D10TypeInfo_l6__vtblZ+0x70): undef ref `_D6object8TypeInfo7destroyMxFPvZv'
(_D10TypeInfo_l6__vtblZ+0x78): undef ref `_D6object8TypeInfo8postblitMxFPvZv'
(_D10TypeInfo_l6__vtblZ+0x80): undef ref `_D6object8TypeInfo6talignMxFNaNbNdNiNfZm'
(_D10TypeInfo_l6__vtblZ+0x88): undef ref `_D6object8TypeInfo8argTypesMFNbNfJC8TypeInfoJC8TypeInfoZi'
(_D10TypeInfo_l6__vtblZ+0x90): undef ref `_D6object8TypeInfo6rtInfoMxFNaNbNdNiNfZPyv'
 In function `_D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv':
(.text._D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv[_D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv]+0x1c): undef ref `_D3std5stdio6stdoutS3std5stdio4File'
(.text._D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv[_D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv]+0x41): undef ref `fprintf'
(.text._D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv[_D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv]+0x81): undef ref `_D3std9exception14__T7enforceTbZ7enforceFNaNfbLAxaAyamZb'
 In function `_Dmain':
(.text._Dmain+0x36): undef ref `memset'
(_D27TypeInfo_S4main10TestStruct6__initZ[_D27TypeInfo_S4main10TestStruct6__initZ]+0x70): undef ref `_D10TypeInfo_g6__initZ'
(_D4main9TestClass6__vtblZ+0x8): undef ref `_D6object6Object8toStringMFZAya'
(_D4main9TestClass6__vtblZ+0x10): undef ref `_D6object6Object6toHashMFNbNeZm'
(_D4main9TestClass6__vtblZ+0x18): undef ref `_D6object6Object5opCmpMFC6ObjectZi'
(_D4main9TestClass6__vtblZ+0x20): undef ref `_D6object6Object8opEqualsMFC6ObjectZb'
(_D12TypeInfo_Axm6__initZ[_D12TypeInfo_Axm6__initZ]+0x0): undef ref `_D14TypeInfo_Array6__vtblZ'
(_D11TypeInfo_xm6__initZ[_D11TypeInfo_xm6__initZ]+0x10): undef ref `_D10TypeInfo_m6__initZ'
(_D11TypeInfo_ya6__initZ[_D11TypeInfo_ya6__initZ]+0x10): undef ref `_D10TypeInfo_a6__initZ'
(_D12TypeInfo_xAa6__initZ[_D12TypeInfo_xAa6__initZ]+0x10): undef ref `_D12TypeInfo_Axa6__initZ'
(_D11TypeInfo_xb6__initZ[_D11TypeInfo_xb6__initZ]+0x10): undef ref `_D10TypeInfo_b6__initZ'
(_D11TypeInfo_xi6__initZ[_D11TypeInfo_xi6__initZ]+0x10): undef ref `_D10TypeInfo_i6__initZ'
(_D11TypeInfo_xa6__initZ[_D11TypeInfo_xa6__initZ]+0x10): undef ref `_D10TypeInfo_a6__initZ'
(_D11TypeInfo_xh6__initZ[_D11TypeInfo_xh6__initZ]+0x10): undef ref `_D10TypeInfo_h6__initZ'
(_D11TypeInfo_xk6__initZ[_D11TypeInfo_xk6__initZ]+0x10): undef ref `_D10TypeInfo_k6__initZ'
(_D13TypeInfo_xAya6__initZ[_D13TypeInfo_xAya6__initZ]+0x10): undef ref `_D12TypeInfo_Aya6__initZ'

This is far more than what I get with DMD and GDC.  You can see why TypeInfo is a major pain, and as far as I can tell, I don't have any code that needs it.

But what's most surprising is the call to fprintf for std.writeln, even though my implementation is actually a system call in assembly:  https://github.com/JinShil/minimal_druntime_experiment/blob/master/source/ports/posix/linux/phobos/phobosPort.d#L6

I'm compiling with: ldc2 -c -defaultlib=  -release

Are there any compiler flags I can add to help trim the fat?

Thanks,
Mike

Am Wed, 06 May 2015 07:44:03 +0000
schrieb "Suliman" <evermind@live.ru>:

> >Yes! I've written small D test programs for AVR.
> you mean 8-bit AVR? It's very cool! Could you show sources code example?

Yes [1] [2] [3]. Only Hello-World / proof of concept kind of code for now. There are no fundamental issues, just a lack of time to finish this. I've focused on small and optimized codegen rather than nice examples for now. It also uses the avr-libc instead of custom startup code (because of lack of time).

The next step is generating all the register wrappers. It's a very tedious task but I've got a script 90% ready to parse the register tables out of the Atmel pdfs. The output should still be checked manually though. Unfortunately I don't have time to work on this for now, but I'll get back to it at some point ;-)

[1]
https://github.com/D-Programming-microD/avr-playground/blob/master/src/test.d
[2]
https://github.com/D-Programming-microD/avr-playground/blob/master/src/util/delay.d
[3] (mixin generator is ready but not yet on github)
https://github.com/D-Programming-microD/avr-playground/blob/master/src/util/mmio.d