Hi,

I wrote a page in the wiki for basic information on how to use D on AVR 8-bit, using LLVM and LDC.

https://wiki.dlang.org/D_on_AVR

With BetterC everything seems to be working fine, now it's time to create a framework for using D on microcontrollers!

On Wednesday, 27 November 2019 at 14:35:53 UTC, Ernesto Castellotti wrote:
> I wrote a page in the wiki for basic information on how to use D on AVR 8-bit, using LLVM and LDC.

Nice! We should compile this option into upstream ldc so the binaries just work too for maximum convenience.

On Wed, Nov 27, 2019 at 02:35:53PM +0000, Ernesto Castellotti via Digitalmars-d-announce wrote:
> Hi,
> 
> I wrote a page in the wiki for basic information on how to use D on AVR 8-bit, using LLVM and LDC.
> 
> https://wiki.dlang.org/D_on_AVR
> 
> With BetterC everything seems to be working fine, now it's time to create a framework for using D on microcontrollers!

According to Walter (cf. https://digitalmars.com/articles/hits.pdf, slide 5), D was designed with the assumption of running on a 32-bit or higher CPU.  How is this handled in the AVR case?  Or is this strictly only for betterC? (Even with -betterC I'm having some trouble imagining how basic D features might work on an 8-bit controller.)

Not questioning your work -- I think this is awesome -- but just curious about the practical implications of writing D for an 8-bit environment.


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble again.

On Wednesday, 27 November 2019 at 18:25:47 UTC, H. S. Teoh wrote:
> On Wed, Nov 27, 2019 at 02:35:53PM +0000, Ernesto Castellotti via Digitalmars-d-announce wrote:
>> Hi,
>> 
>> I wrote a page in the wiki for basic information on how to use D on AVR 8-bit, using LLVM and LDC.
>> 
>> https://wiki.dlang.org/D_on_AVR
>> 
>> With BetterC everything seems to be working fine, now it's time to create a framework for using D on microcontrollers!
>
> According to Walter (cf. https://digitalmars.com/articles/hits.pdf, slide 5), D was designed with the assumption of running on a 32-bit or higher CPU.  How is this handled in the AVR case?  Or is this strictly only for betterC? (Even with -betterC I'm having some trouble imagining how basic D features might work on an 8-bit controller.)
>
> Not questioning your work -- I think this is awesome -- but just curious about the practical implications of writing D for an 8-bit environment.
>
>
> T

The support to targets that use 16 bits as a pointer size has already been added to LDC (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR support is present (AVR uses 16 bit pointers).
Obviously not all the language works with AVR, however with BetterC there are no problems.
But the support to druntime and phobos is non-existent, honestly I don't think it's a big problem, I am of the opinion that it is better to have a separate library to develop on AVR.
Most of the modules in phobos are useless for the classic AVR work, or they are inadequate because they use GC or depend on an operating system.
In my opinion, nobody really wants to use them.

On 11/27/2019 6:35 AM, Ernesto Castellotti wrote:
> With BetterC everything seems to be working fine, now it's time to create a framework for using D on microcontrollers!

Yay!

On Wednesday, 27 November 2019 at 19:30:15 UTC, Ernesto Castellotti wrote:
>
> The support to targets that use 16 bits as a pointer size has already been added to LDC (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR support is present (AVR uses 16 bit pointers).

Don't you run into trouble with the fact that the defualt integer size is 32 bits?

On Thursday, 28 November 2019 at 08:31:36 UTC, Dukc wrote:
> On Wednesday, 27 November 2019 at 19:30:15 UTC, Ernesto Castellotti wrote:
>>
>> The support to targets that use 16 bits as a pointer size has already been added to LDC (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR support is present (AVR uses 16 bit pointers).
>
> Don't you run into trouble with the fact that the defualt integer size is 32 bits?
In LDC, the integers size depends on the target architecture.

https://github.com/ldc-developers/ldc/blob/0a1a40ebc7ee29b02a6e92daa389e3c5611f086f/gen/tollvm.cpp#L259

On Thu, Nov 28, 2019 at 05:18:59PM +0000, Ernesto Castellotti via Digitalmars-d-announce wrote:
> On Thursday, 28 November 2019 at 08:31:36 UTC, Dukc wrote:
> > On Wednesday, 27 November 2019 at 19:30:15 UTC, Ernesto Castellotti wrote:
> > > 
> > > The support to targets that use 16 bits as a pointer size has
> > > already been added to LDC
> > > (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR
> > > support is present (AVR uses 16 bit pointers).
> > 
> > Don't you run into trouble with the fact that the defualt integer size is 32 bits?
> In LDC, the integers size depends on the target architecture.
> 
> https://github.com/ldc-developers/ldc/blob/0a1a40ebc7ee29b02a6e92daa389e3c5611f086f/gen/tollvm.cpp#L259

Isn't this only for size_t?  Because 'int' in D is always 32-bit according to the spec. I can't imagine LDC would deliberately violate the spec this way.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??

On Thursday, 28 November 2019 at 17:37:31 UTC, H. S. Teoh wrote:
> On Thu, Nov 28, 2019 at 05:18:59PM +0000, Ernesto Castellotti via Digitalmars-d-announce wrote:
>> On Thursday, 28 November 2019 at 08:31:36 UTC, Dukc wrote:
>> > On Wednesday, 27 November 2019 at 19:30:15 UTC, Ernesto Castellotti wrote:
>> > > 
>> > > The support to targets that use 16 bits as a pointer size has
>> > > already been added to LDC
>> > > (https://github.com/ldc-developers/ldc/pull/2194), so minimal AVR
>> > > support is present (AVR uses 16 bit pointers).
>> > 
>> > Don't you run into trouble with the fact that the defualt integer size is 32 bits?
>> In LDC, the integers size depends on the target architecture.
>> 
>> https://github.com/ldc-developers/ldc/blob/0a1a40ebc7ee29b02a6e92daa389e3c5611f086f/gen/tollvm.cpp#L259
>
> Isn't this only for size_t?  Because 'int' in D is always 32-bit according to the spec. I can't imagine LDC would deliberately violate the spec this way.
>
>
> T

Yes LDC sets size_t for the platform, not violating the spec.
int in D is 32-bit as you said, that if you compare it with the size of the types of AVR-GCC it would be long,
This is not a problem, just use the type aliases like those in core.stdc.stdint to work around

On Thursday, 28 November 2019 at 18:40:17 UTC, Ernesto Castellotti wrote:
> Yes LDC sets size_t for the platform, not violating the spec.
> int in D is 32-bit as you said, that if you compare it with the size of the types of AVR-GCC it would be long,
> This is not a problem, just use the type aliases like those in core.stdc.stdint to work around

Doesn't D promote all arithmetic operations to 32bit even if the operands are 16 bit?