www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GSOC Idea.

reply Marco <marcoc.r outlook.com> writes:
Hi, I am Marco, a CS student at UCL. This is both a presentation 
post and also post where I ask some suggestions about an idea for 
a GSOC project.

I am a first year student and I do now that I may be too 
inexperienced for such difficult projects, but my willingness to 
learn is big. I am very fascinated by the world of compilers. Due 
to this fact I would really appreciate to be selected this summer 
and to work on a project for the D Lang.

My main idea is to port the D Lang to the arduino environment. I 
do know that in past there has been a proposed project for GSOC 
very similar to this idea, but I can't find any actual 
implementation of this idea on the Internet.

Would the task be too difficult? Or with constant hard work would 
be doable?

Thank you in advance.

(In the case that I will not be selected in the GSOC programme, I 
will probably continue to be an active member of the development 
of the D Lang, due to my real interest for it. So this post is my 
first step in this community)
Mar 02 2016
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 03/03/16 9:21 AM, Marco wrote:

 Hi, I am Marco, a CS student at UCL. This is both a presentation post
 and also post where I ask some suggestions about an idea for a GSOC
 project.

 I am a first year student and I do now that I may be too inexperienced
 for such difficult projects, but my willingness to learn is big. I am
 very fascinated by the world of compilers. Due to this fact I would
 really appreciate to be selected this summer and to work on a project
 for the D Lang.

 My main idea is to port the D Lang to the arduino environment. I do know
 that in past there has been a proposed project for GSOC very similar to
 this idea, but I can't find any actual implementation of this idea on
 the Internet.

 Would the task be too difficult? Or with constant hard work would be
 doable?

 Thank you in advance.

 (In the case that I will not be selected in the GSOC programme, I will
 probably continue to be an active member of the development of the D
 Lang, due to my real interest for it. So this post is my first step in
 this community)


Half a year ago Jens Bauer was offering Cortex-M's for free for anyone 
who wanted one. They would probably be better then Arduino for targeting.

Here is one I'm wanting to get: 


Fairly cheap and yes you can use STM32's with Arduino.


You will need to basically rebuild druntime from scratch and use either 
ldc or gdc. Unless of course you want to add an ARM target to dmd which 
would be very appreciated (but incredibly a lot harder).
Mar 02 2016
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 3 Mar 2016 16:14:24 +1300
schrieb Rikki Cattermole <alphaglosined gmail.com>:


 On 03/03/16 9:21 AM, Marco wrote:

 Hi, I am Marco, a CS student at UCL. This is both a presentation
 post and also post where I ask some suggestions about an idea for a
 GSOC project.

 I am a first year student and I do now that I may be too
 inexperienced for such difficult projects, but my willingness to
 learn is big. I am very fascinated by the world of compilers. Due
 to this fact I would really appreciate to be selected this summer
 and to work on a project for the D Lang.

 My main idea is to port the D Lang to the arduino environment. I do
 know that in past there has been a proposed project for GSOC very
 similar to this idea, but I can't find any actual implementation of
 this idea on the Internet.

 Would the task be too difficult? Or with constant hard work would be
 doable?

 Thank you in advance.

 (In the case that I will not be selected in the GSOC programme, I
 will probably continue to be an active member of the development of
 the D Lang, due to my real interest for it. So this post is my
 first step in this community)  


 
 Half a year ago Jens Bauer was offering Cortex-M's for free for
 anyone who wanted one. They would probably be better then Arduino for
 targeting.
 


The arduino Due uses a Cortex M3, so arduino could mean ARM or AVR.
GDC can target AVR devices with minimal changes. The main problem
is that you really can't use druntime / typeinfo on such small devices
and that some features (e.g. simply using structs) require
TypeInfo. I have some outdated commits here to disable the TypeInfo
stuff:
https://github.com/D-Programming-microD/GDC/commits/microD

and some proof of concept code:
https://github.com/D-Programming-microD/avr-playground/blob/master/src/test.d


 Marco as I've programmed AVR devices before, but never used arduino:
when you say 'arduino environment', do you want to port D to the
arduino hardware / boards or do you also want to interface to arduino
software libraries? Running D programs on Arduino hardware shouldn't be
very difficult, but interfacing Arduino software libraries could be.
IIRC some of the libraries are in C++ and we only have limited C++
interop. And the parts that are in C probably use lots of macros and
macros can't be used from D.




 Here is one I'm wanting to get: 

 
 Fairly cheap and yes you can use STM32's with Arduino.
 
 
 You will need to basically rebuild druntime from scratch and use
 either ldc or gdc. Unless of course you want to add an ARM target to
 dmd which would be very appreciated (but incredibly a lot harder).


to summarize:

* Interfacing with Arduino software: medium to difficult
* Rewriting IO / register access from scratch in D: easy-medium: proof
  of concepts for low level access exist (here:
  https://github.com/D-Programming-microD/avr-playground/blob/master/src/util/mmio.d)
  and Mike had a class based concept. The boring part is generating
  code for all registers. I've got some old code which parses Atmel AVR
  datasheets which could be used for this task.

* Then there's the question whether you base the D port on a C library
  (avr libc) which is easier and allows for C/C++ interop, or whether
  you write the startup files in D as well. Both approaches have been
  used before, but I'd go for the simpler C-library approach first.

* Once low-level access to the registers is available, defining a
  high-level interface is an interesting task. How do you implement
  board configuration (e.g. system clock speed). Could we implement
  some higher level GPIO abstraction / USART abstraction which could
  even allow future libraries for higher-level protocols (such as
  onewire) to work efficiently on different architectures without
  porting efforts? Do we implement interrupts in any way? And the all
  these abstractions need to be efficient in code size and computation
  overhead.

* GDC on ARM: Should already work without changes. You probably want
  druntime on ARM based devices anyway, so TypeInfo is less of a
  problem and there's some existing work from Timo in this area:
  https://bitbucket.org/timosi/minlibd
* GDC on AVR: Requires some minimal changes to the
  GDC compiler. I could take care of that. If we can't get some feature
  upstream early enough, we can always work with patched compilers.
  We need to work without druntime here, which requires some more
  compiler changes for TypeInfo stuff. We'll probably have to work with
  a patched compiler for that, as I don't think we can upstream these
  changes fast enough (should go to DMD first, then GDC).

TLDR: You don't really have to work on the compiler for this project,
but there's some low-level D code that needs to be written. Once
the basics are working, engineering a nice & efficient way to access
hardware peripherals is an interesting task. It's an interesting idea
and would help the D ecosystem a lot. I think it's a ambitious, but
doable task. And this project is actually easy to scale:
1) Start with Hello-World code
2) add Low-Level peripheral access
3) add high level wrappers for Timers, PWM*, ...
4) maybe even write a minimal OS.*

Where the project could be stopped after any phase.

* It's kinda difficult to do most stuff efficiently on AVR without a
  minimal OS: You'll have to use interrupt based code for efficient
  code, but you don't want to do this in an ad-hoc style. Some
  solutions include setting flags in interrupts, then checking the flags
  in the main loop and executing tasks based on the interrupt flags.
  However, this is probably really out of scope for this project.
Mar 03 2016
parent reply Marco <marcoc.r outlook.com> writes:
On Thursday, 3 March 2016 at 09:29:38 UTC, Johannes Pfau wrote:

 Am Thu, 3 Mar 2016 16:14:24 +1300
 schrieb Rikki Cattermole <alphaglosined gmail.com>:

 [...]



 The arduino Due uses a Cortex M3, so arduino could mean ARM or 
 AVR.
 GDC can target AVR devices with minimal changes. The main 
 problem
 is that you really can't use druntime / typeinfo on such small 
 devices
 and that some features (e.g. simply using structs) require
 TypeInfo. I have some outdated commits here to disable the 
 TypeInfo
 stuff:
 https://github.com/D-Programming-microD/GDC/commits/microD

 [...]


Thank you for your detailed answers. Now I do understand that 
working with D and arduino maybe be out of my capability. I may 
now decide to work on porting a parser generator library to 
phobos. I do know that pegged is a parser generator in D. Can 
this new project be easier? I am also quite interested in 
parsing, so that would be a very good experience for me.

Sorry for being such a newbie, I hope you understand my 
willingness to learn.
Mar 03 2016
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 04/03/16 3:09 AM, Marco wrote:

 On Thursday, 3 March 2016 at 09:29:38 UTC, Johannes Pfau wrote:

 Am Thu, 3 Mar 2016 16:14:24 +1300
 schrieb Rikki Cattermole <alphaglosined gmail.com>:

 [...]



 The arduino Due uses a Cortex M3, so arduino could mean ARM or AVR.
 GDC can target AVR devices with minimal changes. The main problem
 is that you really can't use druntime / typeinfo on such small devices
 and that some features (e.g. simply using structs) require
 TypeInfo. I have some outdated commits here to disable the TypeInfo
 stuff:
 https://github.com/D-Programming-microD/GDC/commits/microD

 [...]


 Thank you for your detailed answers. Now I do understand that working
 with D and arduino maybe be out of my capability. I may now decide to
 work on porting a parser generator library to phobos. I do know that
 pegged is a parser generator in D. Can this new project be easier? I am
 also quite interested in parsing, so that would be a very good
 experience for me.

 Sorry for being such a newbie, I hope you understand my willingness to
 learn.


You may want to stay clear of CTFE which is how pegged works primarily.
Mar 03 2016
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 03 Mar 2016 14:09:33 +0000
schrieb Marco <marcoc.r outlook.com>:


 On Thursday, 3 March 2016 at 09:29:38 UTC, Johannes Pfau wrote:

 Am Thu, 3 Mar 2016 16:14:24 +1300
 schrieb Rikki Cattermole <alphaglosined gmail.com>:

 [...]  


 

 The arduino Due uses a Cortex M3, so arduino could mean ARM or 
 AVR.
 GDC can target AVR devices with minimal changes. The main 
 problem
 is that you really can't use druntime / typeinfo on such small 
 devices
 and that some features (e.g. simply using structs) require
 TypeInfo. I have some outdated commits here to disable the 
 TypeInfo
 stuff:
 https://github.com/D-Programming-microD/GDC/commits/microD

 [...]  


 
 Thank you for your detailed answers. Now I do understand that 
 working with D and arduino maybe be out of my capability. I may 
 now decide to work on porting a parser generator library to 
 phobos. I do know that pegged is a parser generator in D. Can 
 this new project be easier? I am also quite interested in 
 parsing, so that would be a very good experience for me.
 
 Sorry for being such a newbie, I hope you understand my 
 willingness to learn.


Sorry if my answer scared you away from that task :-) I think it's not
necessarily difficult, but as there's no finished/polished
D implementation for embedded devices yet it's pioneering work.
And as it affects many areas in the D ecosystem (compiler,druntime,dub)
and some low-level programming it's much easier for someone
already familiar with low-level D implementation details and/or
embedded programming.

I don't know anything about parser generators, so somebody else will
have to answer these questions. You should probably start a new thread
with an updated title for that though, to get some more attention.
Mar 04 2016
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2016-03-02 at 20:21 +0000, Marco via Digitalmars-d wrote:

 Hi, I am Marco, a CS student at UCL. This is both a presentation=C2=A0
 post and also post where I ask some suggestions about an idea for=C2=A0
 a GSOC project.


[=E2=80=A6]

Students from UCL definitely worth supporting. :-)

Did you have more of a think about what you might do in the D arena?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 16 2016