GSOC Idea.

[Johannes Pfau via Digitalmars-d]

Am Thu, 3 Mar 2016 16:14:24 +1300
schrieb Rikki Cattermole <alphaglosined at 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: 
> http://www.dx.com/p/cortex-m3-stm32f103c8t6-stm32-development-board-w-swd-socket-st-link-v2-programmer-emulator-395848#.VterNJx97IU
> 
> 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.