www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ARM Cortex-M Microcontroller startup files

reply "Jens Bauer" <doctor who.no> writes:
Some of you already know that I've been working on startup files 
for STM32F4xx and LPC17xx.

Since a number of people have shown interest in these files, I've 
now merged those two repositories into one and improved it for 
adding more vendors.

What I'd like you to do, is to tell me which microcontrollers you 
want support for.
This means filing a feature request (eg. file an issue at GitHub 
telling me which device(s) you want added. If possible, please 
provide a URL to an existing library.
I've filed a feature request myself as an example (these are 
already in the works, so no need to file any STM32F3 request.)

The new repository:
https://github.com/jens-gpio/MCU

Example feature request:
https://github.com/jens-gpio/MCU/issues/1

The old repositories STM32F4xx and LPC17xx are dead (the README 
has been updated to point to the MCU repository)
Apr 26 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 26 April 2015 at 07:04:06 UTC, Jens Bauer wrote:

 Some of you already know that I've been working on startup 
 files for STM32F4xx and LPC17xx.

 Since a number of people have shown interest in these files, 
 I've now merged those two repositories into one and improved it 
 for adding more vendors.

 What I'd like you to do, is to tell me which microcontrollers 
 you want support for.
 This means filing a feature request (eg. file an issue at 
 GitHub telling me which device(s) you want added. If possible, 
 please provide a URL to an existing library.
 I've filed a feature request myself as an example (these are 
 already in the works, so no need to file any STM32F3 request.)

 The new repository:
 https://github.com/jens-gpio/MCU

 Example feature request:
 https://github.com/jens-gpio/MCU/issues/1

 The old repositories STM32F4xx and LPC17xx are dead (the README 
 has been updated to point to the MCU repository)


Please mention that in wiki.dlang.org
May be even worth creating dedicated "ARM" page there which will 
aggregated all related articles.
Apr 26 2015
parent reply "Jens Bauer" <doctor who.no> writes:
On Sunday, 26 April 2015 at 14:18:24 UTC, Dicebot wrote:

 On Sunday, 26 April 2015 at 07:04:06 UTC, Jens Bauer wrote:

 Some of you already know that I've been working on startup 
 files for STM32F4xx and LPC17xx.

 https://github.com/jens-gpio/MCU


 Please mention that in wiki.dlang.org
 May be even worth creating dedicated "ARM" page there which 
 will aggregated all related articles.


Done.
http://wiki.dlang.org/Microcontroller_startup_files

-This is my first successful Wiki page, BTW. :)
Apr 26 2015
next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/26/2015 05:55 PM, Jens Bauer wrote:

 Done.
 http://wiki.dlang.org/Microcontroller_startup_files
 
 -This is my first successful Wiki page, BTW. :)


Nice, minilibd seems to be maintained as well, you happen to know the
author?
I'd really like to see binary releases of GDC for arm-none-eabi that
ship with a patched compiler (iff necessary) and minilibd.
Apr 26 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Sunday, 26 April 2015 at 16:09:57 UTC, Martin Nowak wrote:

 On 04/26/2015 05:55 PM, Jens Bauer wrote:

 Done.
 http://wiki.dlang.org/Microcontroller_startup_files
 
 -This is my first successful Wiki page, BTW. :)


 Nice, minilibd seems to be maintained as well, you happen to 
 know the author?


I haven't met Timo (yet), I live in Denmark, and as far as I 
understand, Timo is from Finland.
-But we communicate here.


 I'd really like to see binary releases of GDC for arm-none-eabi 
  that
 ship with a patched compiler (iff necessary) and minilibd.


So far, building GCC-4.9.2+GDC-4.9 works for me. I haven't done 
any 'deep' coding yet, but I do some tests almost every day.

I may be able to put together some kind of recipe for building 
the GCC+GDC I have.
Unfortunately, I have not been able to build with multilib yet, 
so my setup cannot build code for Cortex-M0; it keeps stuffing 
Cortex-M3 and Cortex-M4 instructions in there.

-But if I build GCC without GDC, then I can build with multilib, 
and make code for Cortex-M0. So I cannot have both.

I know Mike have been working on this. Hopefully one of us will 
find a solution.
Apr 26 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/26/2015 07:29 PM, Jens Bauer wrote:

 I may be able to put together some kind of recipe for building the
 GCC+GDC I have.
 Unfortunately, I have not been able to build with multilib yet, so my
 setup cannot build code for Cortex-M0; it keeps stuffing Cortex-M3 and
 Cortex-M4 instructions in there.


The wiki says to disable multilib
(http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
what's the problem? Maybe ask Iain/Johannes if it's GDC specific.


 -But if I build GCC without GDC, then I can build with multilib, and
 make code for Cortex-M0. So I cannot have both.
 
 I know Mike have been working on this. Hopefully one of us will find a
 solution.


What libc are you using? The gcc-arm-embedded project uses newlib and
newlib-nano. https://launchpad.net/gcc-arm-embedded
Apr 26 2015
next sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

 On 04/26/2015 07:29 PM, Jens Bauer wrote:

 Unfortunately, I have not been able to build with multilib 
 yet, so my
 setup cannot build code for Cortex-M0; it keeps stuffing 
 Cortex-M3 and
 Cortex-M4 instructions in there.


 The wiki says to disable multilib
 (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
 what's the problem?


The problem is that I cannot have a single compiler, which 
compiles for these architectures:
ARM7TDMI
Cortex-M0
Cortex-M3
Cortex-M4

Using a Cortex-M3 or Cortex-M4 compiler to build code for a 
Cortex-M0, will insert 32-bit instructions randomly (most code is 
16-bit, though, so parts of it gets it right). As soon as the 
microcontroller tries to run a 32-bit instruction, it will crash.

-In order to build code for Cortex-M0 or Cortex-M0+, I will have 
to rebuild the compiler.
The alternative is to build 5 different compilers. I don't want 
that either.

...

The reason I cannot build GDC with multilib, is that I get a 
compile-error when building the final GCC+GDC.
Building GCC alone without GDC gives me no such error.
-So if I want to have multilib support, I will have to be without 
GDC.
Apr 26 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

 On 04/26/2015 07:29 PM, Jens Bauer wrote:

 Unfortunately, I have not been able to build with multilib yet, so my
 setup cannot build code for Cortex-M0; it keeps stuffing Cortex-M3 and
 Cortex-M4 instructions in there.



 The wiki says to disable multilib

 (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
 what's the problem?



 The problem is that I cannot have a single compiler, which compiles for
 these architectures:
 ARM7TDMI
 Cortex-M0
 Cortex-M3
 Cortex-M4

 Using a Cortex-M3 or Cortex-M4 compiler to build code for a Cortex-M0, will
 insert 32-bit instructions randomly (most code is 16-bit, though, so parts
 of it gets it right). As soon as the microcontroller tries to run a 32-bit
 instruction, it will crash.

 -In order to build code for Cortex-M0 or Cortex-M0+, I will have to rebuild
 the compiler.
 The alternative is to build 5 different compilers. I don't want that either.

 ...

 The reason I cannot build GDC with multilib, is that I get a compile-error
 when building the final GCC+GDC.
 Building GCC alone without GDC gives me no such error.
 -So if I want to have multilib support, I will have to be without GDC.


Where exactly does it error?

I can't think of a sole reason why gdc/libphobos would throw an error
in multilib builds, so it must be something collateral (libstdc++) ?

Regards
Iain.
Apr 26 2015
next sibling parent "Jens Bauer" <doctor who.no> writes:
On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:

 On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 The reason I cannot build GDC with multilib, is that I get a 
 compile-error
 when building the final GCC+GDC.
 Building GCC alone without GDC gives me no such error.
 -So if I want to have multilib support, I will have to be 
 without GDC.


 Where exactly does it error?


I'm doing a rebuild now; it'll probably take 50 minutes before I 
got the result. I'll post a reply when I have something.


 I can't think of a sole reason why gdc/libphobos would throw an 
 error
 in multilib builds, so it must be something collateral 
 (libstdc++) ?


I remember something about libstdc++ problems. I forgot whether 
it was a missing libstdc++ after the build or if it was causing 
trouble with the build.
Apr 27 2015
prev sibling next sibling parent reply "Jens Bauer" <doctor who.no> writes:
On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:

 On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:




{snip}

 The reason I cannot build GDC with multilib, is that I get a
 compile-error when building the final GCC+GDC.




Correction: it's a 'build-error', but it's caused by sed.


 Building GCC alone without GDC gives me no such error.


 Where exactly does it error?


Here's the complete chunk. It's on purpose I started with 
config.h.

---8<-----8<-----8<-----
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e 

]*\)/_GLIBCXX_\1/g' 
\
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > 
arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-single.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h 

 arm-none-eabi/bits/gthr-posix.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-default.h


config.status: executing libtool commands
config.status: executing include/gstdint.h cconfig.status: 
executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e 

]*\)/_GLIBCXX_\1/g' 
\
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > 
arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-single.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h 

 arm-none-eabi/bits/gthr-posix.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-default.h


make: *** [all] Error 2
Failed
--->8----->8----->8-----

As you see, config.h, libstdc++ and multilib are all present in 
this chunk.



 Apr 27 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:

 On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:




 {snip}

 The reason I cannot build GDC with multilib, is that I get a
 compile-error when building the final GCC+GDC.





 Correction: it's a 'build-error', but it's caused by sed.


 Building GCC alone without GDC gives me no such error.



 Where exactly does it error?



 Here's the complete chunk. It's on purpose I started with config.h.


<snip>


 As you see, config.h, libstdc++ and multilib are all present in this chunk.


Try building with --disable-libstdcxx as in the suggestion from Timo.

Regards
Iain



 Apr 27 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:

 On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d


{snip}

 As you see, config.h, libstdc++ and multilib are all present 
 in this chunk.


 Try building with --disable-libstdcxx as in the suggestion from 
 Timo.


Unfortunately, it still fails:
---8<-----8<-----8<-----

config.status: creating Makefile
config.status: creating scripts/testsuite_flags
config.status: creating scripts/extract_symvers
config.status: creating doc/xsl/customization.xsl
config.status: creating include/Makefile
Adding multilib support to include/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating libsupc++/Makefile
Adding multilib support to libsupc++/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating python/Makefile
Adding multilib support to python/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating src/Makefile
Adding multilib support to src/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating src/c++98/Makefile
Adding multilib support to src/c++98/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating src/c++11/Makefile
Adding multilib support to src/c++11/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating doc/Makefile
Adding multilib support to doc/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating po/Makefile
Adding multilib support to po/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating testsuite/Makefile
Adding multilib support to testsuite/Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in 
/Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e 

]*\)/_GLIBCXX_\1/g' 
\
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > 
arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-single.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h 

 arm-none-eabi/bits/gthr-posix.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-default.h


config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e 

]*\)/_GLIBCXX_\1/g' 
\
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > 
arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-single.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h 

 arm-none-eabi/bits/gthr-posix.h


sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' 
\
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 
's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < 
/Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h 

 arm-none-eabi/bits/gthr-default.h


make: *** [all] Error 2
--->8----->8----->8-----
(Sorry for the delay, I ran the wrong build-script at first - 
building GCC twice takes approximately 100 minutes)



 Apr 27 2015



  parent reply "Mike" <none none.com>  writes:


On Monday, 27 April 2015 at 18:26:35 UTC, Jens Bauer wrote:

 On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:

 On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d


 {snip}

 As you see, config.h, libstdc++ and multilib are all present 
 in this chunk.


 Try building with --disable-libstdcxx as in the suggestion 
 from Timo.


 Unfortunately, it still fails:


[...]

The way I've gotten around this is to do "make all-gcc".

According to http://www.mingw.org/wiki/HostedCrossCompilerHOWTO:

"The make targets all-gcc and install-gcc are used here to
prevent the build process from attempting to build and install
the C++ compiler and libraries before we have the base C
libraries built and installed."

Mike



 Apr 27 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Tuesday, 28 April 2015 at 06:32:16 UTC, Mike wrote:

 On Monday, 27 April 2015 at 18:26:35 UTC, Jens Bauer wrote:

 On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:

 On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d


 {snip}

 As you see, config.h, libstdc++ and multilib are all present 
 in this chunk.


 Try building with --disable-libstdcxx as in the suggestion 
 from Timo.


 Unfortunately, it still fails:


 [...]

 The way I've gotten around this is to do "make all-gcc".


This is what I use as well, but that doesn't seem to let my 
second stage pass.



 Apr 28 2015



prev sibling  parent  Johannes Pfau <nospam example.com>  writes:


Am Mon, 27 Apr 2015 07:56:02 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

 On 04/26/2015 07:29 PM, Jens Bauer wrote:

 Unfortunately, I have not been able to build with multilib yet,
 so my setup cannot build code for Cortex-M0; it keeps stuffing
 Cortex-M3 and Cortex-M4 instructions in there.



 The wiki says to disable multilib

 (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
 what's the problem?



 The problem is that I cannot have a single compiler, which compiles
 for these architectures:
 ARM7TDMI
 Cortex-M0
 Cortex-M3
 Cortex-M4

 Using a Cortex-M3 or Cortex-M4 compiler to build code for a
 Cortex-M0, will insert 32-bit instructions randomly (most code is
 16-bit, though, so parts of it gets it right). As soon as the
 microcontroller tries to run a 32-bit instruction, it will crash.

 -In order to build code for Cortex-M0 or Cortex-M0+, I will have to
 rebuild the compiler.
 The alternative is to build 5 different compilers. I don't want
 that either.

 ...

 The reason I cannot build GDC with multilib, is that I get a
 compile-error when building the final GCC+GDC.
 Building GCC alone without GDC gives me no such error.
 -So if I want to have multilib support, I will have to be without
 GDC.


 
 Where exactly does it error?
 
 I can't think of a sole reason why gdc/libphobos would throw an error
 in multilib builds, so it must be something collateral (libstdc++) ?
 
 Regards
 Iain.


It might be libbacktrace related. I saw errors building AVR32 multilibs
caused by libbacktrace: We pull in libbacktrace even if druntime/phobos
are disabled with --disable-libphobos.


Possible fix: gcc/d/config-lang.in

 compilers="cc1d\$(exeext)"
 
-target_libs="target-libphobos target-zlib target-libbacktrace"
+if eval test x\${enable_libphobos} "=" xno ; then
+    target_libs=""
+else
+    target_libs="target-libphobos target-zlib target-libbacktrace"
+fi
 





 Apr 27 2015



prev sibling next sibling parent  "Mike" <none none.com>  writes:


On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:


 The wiki says to disable multilib
 (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
 what's the problem? Maybe ask Iain/Johannes if it's GDC 
 specific.


When I first started working with GDC, I had a hell of a time 
getting the cross-compiler to build.  I disabled multilib simply 
to remove a variable.  Since I was able to eventually get what I 
needed with that configuration, I left it as is.  In summary, the 
choice to disable multilib was rather arbitrary.

I'm not currently working on this, and I don't have the hardware 
to properly test it.

Timo also asked about this a while ago, but it didn't elicit much 
discussion 
(http://forum.dlang.org/post/uwkshliqwbmmxdfiuaow forum.dlang.org). 
  I'm not knowledgable enough about it, so I wasn't able to offer 
any help.

Mike



 Apr 26 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:


 The wiki says to disable multilib
 (http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler#Build_GCC),
 what's the problem? Maybe ask Iain/Johannes if it's GDC 
 specific.


I have also tried for years to build a working multilib without 
success. Now I think I have been able to get all versions to 
work. I welcome everyone to test and report if this works.

The build script:
../gcc/configure --disable-bootstrap \
--enable-languages=c,d  --disable-nls --target=arm-eabi \
--without-headers  --with-newlib --without-isl --without-cloog \
--disable-libphobos --disable-libstdcxx --disable-libbacktrace\
--enable-multilib

And I replace the whole gcc/config/arm/t-arm-elf with this:
MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4 
  mfloat-abi=hard mfpu=fpv4-sp-d16
MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
MULTILIB_REQUIRED += mcpu=cortex-m0
MULTILIB_REQUIRED += mcpu=cortex-m3


MULTILIB_EXTRA_OPTS += mthumb


This will build m0 and m3 with soft float and m4 with hard float. 
I have used gdc head + gcc 6 head from about a week ago. It may 
be possible this will work with gcc 5.1 release + gdc 5  and I 
hope somebody will test this.

Please note: This is the first time ever I have suceeded. This 
will not work with any gcc before april. An older gcc will not 
build m4 or it may even not pass configuring.

So please test and report.


 What libc are you using? The gcc-arm-embedded project uses 
 newlib and
 newlib-nano. https://launchpad.net/gcc-arm-embedded


I have used standard newlib from sources. There were some 
discussions that libc should not be needed any more to build the 
compiler. I can not test this because I do not have a totally 
clean environment right now. So if anybody could advice me or 
just test if it is currently possible to build without libc.



 Apr 26 2015



 next sibling parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

Oops, I forget to uncomment the m4 options. The correct version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += 
 mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
  mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  
 /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb





 Apr 26 2015



 next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 07:22, Timo Sintonen via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
  mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb




Maybe you could instead create a new file under config/arm/t-mprofile,
for use with --with-multilib-list=mprofile  (see patch below).

See config/arm/t-aprofile for guidance, which looks to be tailored
multilib support for the Cortex-A range of CPUs.

I can ask around if someone has done something similar for Cortex-M.

Regards
Iain.

--- a/gcc/config.gcc
+++ b/gcc/config.gcc
   -3711,6 +3711,28    case "${target}" in
                                        tmake_file="${tmake_file}
arm/t-aprofile"
                                        break
                                        ;;
+                               mprofile)










+                                       if test "x$with_arch" != x \
+                                           || test "x$with_cpu" != x \
+                                           || test "x$with_float" != x \
+                                           || test "x$with_fpu" != x \
+                                           || test "x$with_mode" != x ; then
+                                           echo "Error: You cannot
use any of --with-arch/cpu/fpu/float/mode with
--with-multilib-list=mprofile" 1>&2
+                                           exit 1
+                                       fi
+                                       tmake_file="${tmake_file}
arm/t-mprofile"
+                                       break
+                                       ;;
                                default)
                                        ;;
                                *)



 Apr 26 2015



prev sibling next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 08:28, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 27 April 2015 at 07:22, Timo Sintonen via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
  mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb




 Maybe you could instead create a new file under config/arm/t-mprofile,
 for use with --with-multilib-list=mprofile  (see patch below).

 See config/arm/t-aprofile for guidance, which looks to be tailored
 multilib support for the Cortex-A range of CPUs.


Also stumbled across:
https://github.com/prattmic/arm-cortex-m4-hardfloat-toolchain/blob/master/patches/gcc-multilib.patch



 Apr 26 2015



prev sibling  parent reply "Mike" <none none.com>  writes:


On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct version 
 is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += 
 mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
 mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  
 /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb




The toolchain at https://launchpad.net/gcc-arm-embedded doesn't 
require this modification, so I'm wondering if there's another 
way.  My understanding is that this is unlreated to GDC itself, 
so we should be able to follow essentially the same procedure as 
the embedded C/C++ toolchains, right?

They have their build scripts included in their source package, 
so I spent a little time analyzing their build scripts today, and 
I see they are using the following config option:

"--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

I'm wondering if that alone will do it.  I guess I'll give it a 
try later and let you all know what I find.

Mike



 Apr 27 2015



 next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 09:34, Mike via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
 mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb





 The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this
 modification, so I'm wondering if there's another way.  My understanding is
 that this is unlreated to GDC itself, so we should be able to follow
 essentially the same procedure as the embedded C/C++ toolchains, right?

 They have their build scripts included in their source package, so I spent a
 little time analyzing their build scripts today, and I see they are using
 the following config option:

 "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

 I'm wondering if that alone will do it.  I guess I'll give it a try later
 and let you all know what I find.



From what I'm reading in config.gcc, ARM does not support


--with-multilib-list= *except* for 'default' and 'aprofile'.  So
Ubuntu/Canonical must be applying local patches to get that working.

Iain.



 Apr 27 2015



prev sibling next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 09:47, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 27 April 2015 at 09:34, Mike via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
 mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb





 The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this
 modification, so I'm wondering if there's another way.  My understanding is
 that this is unlreated to GDC itself, so we should be able to follow
 essentially the same procedure as the embedded C/C++ toolchains, right?

 They have their build scripts included in their source package, so I spent a
 little time analyzing their build scripts today, and I see they are using
 the following config option:

 "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

 I'm wondering if that alone will do it.  I guess I'll give it a try later
 and let you all know what I find.


 From what I'm reading in config.gcc, ARM does not support
 --with-multilib-list= *except* for 'default' and 'aprofile'.  So
 Ubuntu/Canonical must be applying local patches to get that working.


Yep!  Here's the local patch:  http://pastebin.com/D3RmCNMf

Regards
Iain



 Apr 27 2015



prev sibling next sibling parent  "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:

 On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Oops, I forget to uncomment the m4 options. The correct 
 version is

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += 
 mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
 mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3
 MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  
 /mfpu=fpv4-sp-d16
 MULTILIB_EXTRA_OPTS += mthumb




 The toolchain at https://launchpad.net/gcc-arm-embedded doesn't 
 require this modification, so I'm wondering if there's another 
 way.  My understanding is that this is unlreated to GDC itself, 
 so we should be able to follow essentially the same procedure 
 as the embedded C/C++ toolchains, right?

 They have their build scripts included in their source package, 
 so I spent a little time analyzing their build scripts today, 
 and I see they are using the following config option:

 "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

 I'm wondering if that alone will do it.  I guess I'll give it a 
 try later and let you all know what I find.

 Mike


There are two ways to make t-arm-elf: inclusive and exclusive. 
The exclusive way is to list all combinations and exclude 
unwanted with MULTILIB_EXCEPYIONS. This has been the usual way to 
do this. I have not seen the inclusive method I use.

How they tell that m4 should use hard float and the rest do not 
use?  If you can do the build, check with readelf that the 
libraries have correct architecture and compiler flags



 Apr 27 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:


 The toolchain at https://launchpad.net/gcc-arm-embedded doesn't 
 require this modification, so I'm wondering if there's another 
 way.  My understanding is that this is unlreated to GDC itself, 
 so we should be able to follow essentially the same procedure 
 as the embedded C/C++ toolchains, right?

 They have their build scripts included in their source package, 
 so I spent a little time analyzing their build scripts today, 
 and I see they are using the following config option:

 "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

 I'm wondering if that alone will do it.  I guess I'll give it a 
 try later and let you all know what I find.

 Mike


They have not touched t-arm-elf. Instead they have created 
t-aprofile where they have recipes for a huge collection of 
libraries. They also have used the exclusive method and only a 
real guru can understand what this file is doing. I think there 
will be more than 10 different libraries built.

Somewhere in configure options they have put an option that tells 
configure to use this file instead of t-arm-elf.



 Apr 27 2015



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 18:08, Timo Sintonen via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:


 The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require
 this modification, so I'm wondering if there's another way.  My
 understanding is that this is unlreated to GDC itself, so we should be able
 to follow essentially the same procedure as the embedded C/C++ toolchains,
 right?

 They have their build scripts included in their source package, so I spent
 a little time analyzing their build scripts today, and I see they are using
 the following config option:

 "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"

 I'm wondering if that alone will do it.  I guess I'll give it a try later
 and let you all know what I find.

 Mike



 They have not touched t-arm-elf. Instead they have created t-aprofile where
 they have recipes for a huge collection of libraries. They also have used
 the exclusive method and only a real guru can understand what this file is
 doing. I think there will be more than 10 different libraries built.

 Somewhere in configure options they have put an option that tells configure
 to use this file instead of t-arm-elf.


(That would be gcc/config.gcc)



 Apr 27 2015



prev sibling next sibling parent  "Jens Bauer" <doctor who.no>  writes:


On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

 I have also tried for years to build a working multilib without 
 success. Now I think I have been able to get all versions to 
 work. I welcome everyone to test and report if this works.


You can be sure I will test it. :)
Thank you again for doing all the hard and valuable work!



 Apr 27 2015



prev sibling next sibling parent reply "Jens Bauer" <doctor who.no>  writes:


On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:

 I have also tried for years to build a working multilib without 
 success. {snip}

 Please note: This is the first time ever I have suceeded. This 
 will not work with any gcc before april. An older gcc will not 
 build m4 or it may even not pass configuring.


Does this mean that we'll need to use GCC-5.1.0 (released April 
22, 2015) ?
(I'm currently on 4.9.2, which is from october 2014)



 Apr 27 2015



  parent  "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Monday, 27 April 2015 at 10:46:09 UTC, Jens Bauer wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:



 I have also tried for years to build a working multilib 
 without success. {snip}

 Please note: This is the first time ever I have suceeded. This 
 will not work with any gcc before april. An older gcc will not 
 build m4 or it may even not pass configuring.


 Does this mean that we'll need to use GCC-5.1.0 (released April 
 22, 2015) ?
 (I'm currently on 4.9.2, which is from october 2014)


YES! As I mentioned I used gcc 6 head but but I think there has 
not been big changes since 5.1 release.
I have _never_ succeeded with any previous version.

I have never had any success when using any --with options like 
--with-cpu or --with-multilib. Most of the time they result to a 
compiler that has different defaults. The configure script for 
libgcc uses this default compiler in its tests and it always 
fails somewhere because of wrong defaults.

It is also possible the libraries may have wrong set of compiler 
flags even they build correctly. For example: once I got a 
library set built for arch 5. This is totally ok because arch 7 
is compatible with arch 5. There was no issues before I tried 
exceptions. They use callback from libgcc to druntime and this 
failed because of arch mismatch. Took 3 months to find out.

So it is very important that the libraries will be compiled with 
the same compiler flags that the application. This is also true 
when we will make prebuilt libdruntime. The way I have done 
allows to pass correct flags to each library.

Anyway, now we are here to test which is working and which is 
not. I hope that we geet reports from as many people as possible. 
The working methods will go to the wiki page.



 Apr 27 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:


 I have also tried for years to build a working multilib without 
 success. Now I think I have been able to get all versions to 
 work. I welcome everyone to test and report if this works.

 The build script:
 ../gcc/configure --disable-bootstrap \
 --enable-languages=c,d  --disable-nls --target=arm-eabi \
 --without-headers  --with-newlib --without-isl --without-cloog \
 --disable-libphobos --disable-libstdcxx --disable-libbacktrace\
 --enable-multilib

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += 
 mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
  mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3


 MULTILIB_EXTRA_OPTS += mthumb


 This will build m0 and m3 with soft float and m4 with hard 
 float. I have used gdc head + gcc 6 head from about a week ago. 
 It may be possible this will work with gcc 5.1 release + gdc 5  
 and I hope somebody will test this.

 Please note: This is the first time ever I have suceeded. This 
 will not work with any gcc before april. An older gcc will not 
 build m4 or it may even not pass configuring.


Given the other replies in this thread, this looks promising.  
However, I went to give it a test today, and found out my host 
PC's distribution (Arch Linux) hasn't yet released GCC 5.1; it's 
still in testing.

So, I'm going to refrain from testing until the Arch Linux 
package gets officially released.  My current builds don't use 
startup files, libgcc, or any of the other toolchain libs, and I 
only using Cortex-M4F cores, so I'm not sure if my tests will 
prove much of anything, other than successful compilation.

Nevertheless, when GCC 5.1 is official released for my 
distribution, I'll give it a test (if it's not too late by then).

If you suspect it might work for GCC 4.9.2, I'll give it a try.

Mike



 Apr 27 2015



 next sibling parent reply "Jens Bauer" <doctor who.no>  writes:


On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:

 Given the other replies in this thread, this looks promising.  
 However, I went to give it a test today, and found out my host 
 PC's distribution (Arch Linux) hasn't yet released GCC 5.1; 
 it's still in testing.


You don't have to wait for an Arch Linux release of GCC 5.1, 
because you're going to build it yourself anyway, right ?
-It can be downloaded from 
ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2


 If you suspect it might work for GCC 4.9.2, I'll give it a try.


I'm currently experimenting with building on 4.9.2; I expect to 
have a good build later today.



 Apr 27 2015



  parent reply "Mike" <none none.com>  writes:


On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:

 On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:

 Given the other replies in this thread, this looks promising.  
 However, I went to give it a test today, and found out my host 
 PC's distribution (Arch Linux) hasn't yet released GCC 5.1; 
 it's still in testing.


 You don't have to wait for an Arch Linux release of GCC 5.1, 
 because you're going to build it yourself anyway, right ?
 -It can be downloaded from 
 ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2


I always thought we needed to build our cross-compilers with the 
same version as the host in order to have confidence in the 
build.  Correct me if I'm wrong.

Mike



 Apr 27 2015



 next sibling parent  "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Tuesday, 28 April 2015 at 02:18:29 UTC, Mike wrote:

 On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:

 On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:

 Given the other replies in this thread, this looks promising.
  However, I went to give it a test today, and found out my 
 host PC's distribution (Arch Linux) hasn't yet released GCC 
 5.1; it's still in testing.


 You don't have to wait for an Arch Linux release of GCC 5.1, 
 because you're going to build it yourself anyway, right ?
 -It can be downloaded from 
 ftp.gnu.org/gnu/gcc/gcc-5.1.0/gcc-5.1.0.tar.bz2


 I always thought we needed to build our cross-compilers with 
 the same version as the host in order to have confidence in the 
 build.  Correct me if I'm wrong.

 Mike


It has always been recommended that the gcc used should be as 
close as possible to the gcc being compiled. This was very 
important in gcc 2.8 time. 2.7 could not compile anything after 
2.8. I think they are more stable now and the previous release 
may always be used to compile the last release.

It is important that we first test with the original sources. 
Packages may have modified them which may cause issues. It is 
also important that the system is totally clean from previous 
installation. I have tried to build in a vm but it has always 
failed with something like 32/64 bit issue in system headers.

I will put a sample build script in gdc list.



 Apr 27 2015



prev sibling  parent  "Jens Bauer" <doctor who.no>  writes:


On Tuesday, 28 April 2015 at 02:18:29 UTC, Mike wrote:

 On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:

 You don't have to wait for an Arch Linux release of GCC 5.1,


 I always thought we needed to build our cross-compilers with 
 the same version as the host in order to have confidence in the 
 build.


I've never used anything later than GCC-4.2 to build GCC 3.x.x 
... 4.9.2
-So you can absolutely use this or anything later to build your 
toolchain. :)
There's no real difference in building a cross toolchain and 
building a native toolchain (except from some things acts up, but 
it'll do that with any compiler version anyway).



 Apr 28 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:


 The build script:
 ../gcc/configure --disable-bootstrap \
 --enable-languages=c,d  --disable-nls --target=arm-eabi \
 --without-headers  --with-newlib --without-isl --without-cloog 
 \
 --disable-libphobos --disable-libstdcxx --disable-libbacktrace\
 --enable-multilib

 And I replace the whole gcc/config/arm/t-arm-elf with this:
 MULTILIB_OPTIONS  += 
 mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
 mfloat-abi=hard mfpu=fpv4-sp-d16
 MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
 MULTILIB_REQUIRED += mcpu=cortex-m0
 MULTILIB_REQUIRED += mcpu=cortex-m3


 MULTILIB_EXTRA_OPTS += mthumb




[...]

 If you suspect it might work for GCC 4.9.2, I'll give it a try.


I tested this script generating an arm-none-eabil 4.9.2 
cross-compiler with a 4.9.2 host.  My build script is here:  
https://github.com/JinShil/arm-none-eabi-gdc

The lib dir looks like this:
lib
└── gcc
     └── arm-none-eabi
         └── 4.9.2
             ├── cortex-m0
             ├── cortex-m3
             ├── cortex-m4
             ├── include
             ├── include-fixed
             ├── install-tools
             │   └── include
             └── plugin
                 └── include
                     ├── ada
                     │   └── gcc-interface
                     ├── c-family
                     ├── config
                     │   └── arm
                     ├── cp
                     ├── d
                     ├── java
                     └── objc

The "cortex-m{x}" folder have the following files:
crtbegin.o  crtend.o  crti.o  crtn.o  libgcc.a  libgcov.a

I haven't tried to compile anything yet though.  Again, none of 
my software uses these binaries.

Mike



 Apr 27 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Tuesday, 28 April 2015 at 04:05:15 UTC, Mike wrote:

 On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
 [...]

 If you suspect it might work for GCC 4.9.2, I'll give it a try.


 I tested this script generating an arm-none-eabil 4.9.2 
 cross-compiler with a 4.9.2 host.  My build script is here:  
 https://github.com/JinShil/arm-none-eabi-gdc


What ? -Are gmp, mpc and mpfr not required anymore ?

Today I'll do more experiments. I didn't succeed yesterday, so it 
may take a bit more trial and error (I'm used to it anyway, as it 
took me 2 years to get a working GCC toolchain on this computer - 
please don't mention brew, fink and the toolchain scripts that 
are made for intel - they don't work).



 Apr 28 2015



  parent reply "Mike" <none none.com>  writes:


On Tuesday, 28 April 2015 at 12:13:38 UTC, Jens Bauer wrote:

 On Tuesday, 28 April 2015 at 04:05:15 UTC, Mike wrote:

 On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
 [...]

 If you suspect it might work for GCC 4.9.2, I'll give it a 
 try.


 I tested this script generating an arm-none-eabil 4.9.2 
 cross-compiler with a 4.9.2 host.  My build script is here:  
 https://github.com/JinShil/arm-none-eabi-gdc


 What ? -Are gmp, mpc and mpfr not required anymore ?


I don't see why they should be required for this use case.  I'm 
building a cross-compiler that will run on my Linux 64-bit host.  
Since I already have a native compiler for my host, I already 
have those libraries.  Therefore, I just need to build the 
cross-compiler and link it to those libraries (At least, that's 
how I understand it).  If I were to build a canadian 
cross-compiler, that would be different.

Mike



 Apr 28 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Wednesday, 29 April 2015 at 03:11:05 UTC, Mike wrote:

 On Tuesday, 28 April 2015 at 12:13:38 UTC, Jens Bauer wrote:

 What ? -Are gmp, mpc and mpfr not required anymore ?


 I don't see why they should be required for this use case.  I'm 
 building a cross-compiler that will run on my Linux 64-bit 
 host.  Since I already have a native compiler for my host, I 
 already have those libraries.  Therefore, I just need to build 
 the cross-compiler and link it to those libraries (At least, 
 that's how I understand it).  If I were to build a canadian 
 cross-compiler, that would be different.


Alright. I just tried without those libraries and I get 
build-errors, so they're still required.
(They're actually required at your end, too, but as you have them 
installed, the installed libraries will be used).

I've been building and re-building the past few days; I still 
haven't found out why my crti.o, libgcc.o and others are missing, 
but I'm getting closer.

I've also improved my build-system slightly, so that it's almost 
presentable.
A number of variables plus the configure arguments are set up at 
the beginning. After that, some helper-functions are set up, then 
the sources are downloaded+depacked or just cloned (but only if 
necessary). After this, they're patched and compressed (only 
first time). Finally they're built in a clean build directory.
The build-system is fairly server-friendly; it allows you to set 
up your own Web-server as a cache; you only need to set an 
environment variable called DL_CACHE for this. It also tries to 
shorten the build-time by only doing what's necessary (though I'm 
building from scratch each time). At the end, the number of 
hours, minutes and seconds is shown. Currently for my PowerMac G5 
QuadCore/2.5GHz, it takes approximately 48 minutes 
(binutils+GCC+newlib; a second GCC would take approximately 50 
minutes extra).
... I'll try and make a paste later, when it's been polished 
slightly. It's possible to run it line-by-line or as a script. 
I've also made it as a .pdf file.



 Apr 29 2015



prev sibling  parent  "Jens Bauer" <doctor who.no>  writes:


On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 Nevertheless, when GCC 5.1 is official released for my 
 distribution, I'll give it a test (if it's not too late by 
 then).

 If you suspect it might work for GCC 4.9.2, I'll give it a try.


I think I might have something usable now.

http://d.gpio.dk/dl/Build%20a%20GDC%20toolchain.pdf

Bonus: I recommend rebuilding tar for multi-core support:
http://d.gpio.dk/dl/Upgrade%20tar.pdf
I could not build pigz, but if you can build it, you can add it 
using --with-gzip=pigz



 Apr 29 2015



prev sibling  parent reply "Jens Bauer" <doctor who.no>  writes:


On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 The build script:
 ../gcc/configure --disable-bootstrap \
 --enable-languages=c,d  --disable-nls --target=arm-eabi \
 --without-headers  --with-newlib --without-isl --without-cloog \
 --disable-libphobos --disable-libstdcxx --disable-libbacktrace\
 --enable-multilib


You probably didn't mean to have the backslash right next to 
--disable-libbacktrace.
This results in the following switch:

--disable-libbacktrace--enable-multilib

... which makes it build alright. (multilib is enabled by 
default).
If adding a space before --enable-multilib, then I get a build 
error; a part of cc1 seem to require libbacktrace.

Thus I believe removing --disable-libbacktrace would be OK to do.

I'm still in the process of building/modifying, so it'll take a 
while before I report my best results.
So far, it looks like GCC-4.9.2 can be built with multilib if 
using --disable-bootstrap.



 Apr 27 2015



  parent  "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Tuesday, 28 April 2015 at 02:11:06 UTC, Jens Bauer wrote:

 On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

 The build script:
 ../gcc/configure --disable-bootstrap \
 --enable-languages=c,d  --disable-nls --target=arm-eabi \
 --without-headers  --with-newlib --without-isl --without-cloog 
 \
 --disable-libphobos --disable-libstdcxx --disable-libbacktrace\
 --enable-multilib


 You probably didn't mean to have the backslash right next to 
 --disable-libbacktrace.
 This results in the following switch:

 --disable-libbacktrace--enable-multilib

 ... which makes it build alright. (multilib is enabled by 
 default).
 If adding a space before --enable-multilib, then I get a build 
 error; a part of cc1 seem to require libbacktrace.

 Thus I believe removing --disable-libbacktrace would be OK to 
 do.

 I'm still in the process of building/modifying, so it'll take a 
 while before I report my best results.
 So far, it looks like GCC-4.9.2 can be built with multilib if 
 using --disable-bootstrap.


Yes, my mistake. I just made a build with the corrected version 
with success.



 Apr 27 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Sunday, 26 April 2015 at 16:09:57 UTC, Martin Nowak wrote:


 Nice, minilibd seems to be maintained as well, you happen to 
 know the
 author?


I am the author of minlibd


 I'd really like to see binary releases of GDC for arm-none-eabi 
 that
 ship with a patched compiler (iff necessary) and minilibd.


One of the biggest issues has been the multilib build. If it is 
solved now we are one step closer to be able to build binaries.



 Apr 26 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 27 April 2015 at 05:30:55 UTC, Timo Sintonen wrote:

 One of the biggest issues has been the multilib build. If it is 
 solved now we are one step closer to be able to build binaries.


Great, I tried to find out how GDC binaries are build, but 
couldn't find any script.

How much stuff do you strip out of runtime for minilibd? It still 
seems to contain fat typeinfo and moduleinfo. We'd probably need 
the equivalent of -no-rtti and -fno-exceptions and add 
-fno-moduleinfo.

Maybe building a few different configurations of minilibd makes 
sense.
The ARM toolchain comes with a nano.spec to select newlib-nano 
and size optimized libc++.
https://launchpadlibrarian.net/200699979/readme.txt



 Apr 27 2015



 next sibling parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Monday, 27 April 2015 at 07:55:10 UTC, Martin Nowak wrote:


 Great, I tried to find out how GDC binaries are build, but 
 couldn't find any script.


Instructions here:
http://wiki.dlang.org/GDC/Cross_Compiler/Generic
or here:
https://bitbucket.org/timosi/minlibd/wiki/gdc_cross_compiler

There are other instructions in
http://wiki.dlang.org/GDC/Installation
but I think there is no script


 How much stuff do you strip out of runtime for minilibd? It 
 still seems to contain fat typeinfo and moduleinfo. We'd 
 probably need the equivalent of -no-rtti and -fno-exceptions 
 and add -fno-moduleinfo.


It uses -no-moduleinfo but. The module related stuff in object.d 
has been removed but there may be some code elsewhere. I got 
exceptions to work but for smaller systems they should be made 
removable.

The basic idea has been to make as little changes as possible. I 
started by compiling object.d and then added files and modified 
them one by one until there were no compile or link errors. Then 
I added other files that could be compiled without errors. It is 
not guaranteed that all features work and the list of files have 
changed from version to version.

Required and optional files can be found in Makefile
https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/libdruntime/Makefile?at=default

Required changes to these files
https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/Changes?at=default

A while ago someone turned this change list to a bugzilla issue 
14101, and there is also related issue 14100


 Maybe building a few different configurations of minilibd makes 
 sense.
 The ARM toolchain comes with a nano.spec to select newlib-nano 
 and size optimized libc++.
 https://launchpadlibrarian.net/200699979/readme.txt


I have not yet needed libc in my work but of course we can have 
one.
I repeat here that all libraries have to be built with the same 
compiler flags that the application. Otherwise hard to find bugs 
may occur.



 Apr 27 2015



  parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 04/27/2015 03:42 PM, Timo Sintonen wrote:

 
 The basic idea has been to make as little changes as possible. I started
 by compiling object.d and then added files and modified them one by one
 until there were no compile or link errors. Then I added other files
 that could be compiled without errors. It is not guaranteed that all
 features work and the list of files have changed from version to version.


Wonder if it makes more sense to start from zero and add as few files as
possible.
Druntime doesn't do much useful stuff for a µC anyhow.

- GC and rt.lifetime (new, arrays)
- Moduleinfo
- EH unwind support
- AA implementation
- vectorized array ops
- core.time/sync/thread/demangle

What might be interesting is this.

- core.bitop
- maybe core.atomic
- some gcc simd module
- libc bindings for core.stdc.math and core.stdc.stdio for printf



 Apr 29 2015



 next sibling parent  "Jens Bauer" <doctor who.no>  writes:


On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:

 On 04/27/2015 03:42 PM, Timo Sintonen wrote:

 
 The basic idea has been to make as little changes as possible. 
 I started


 Wonder if it makes more sense to start from zero and add as few 
 files as possible.


That was my thought too.


 Druntime doesn't do much useful stuff for a µC anyhow.


I agree. Things like stdint is needed very much. -But this does 
not really add anything to the binary file size.


 What might be interesting is this.

 - core.bitop
 - maybe core.atomic
 - some gcc simd module
 - libc bindings for core.stdc.math and core.stdc.stdio for 
 printf


Indeed. Personally I hate printf, FILE* and the like, but a huge 
crowd needs them, so I'll admit defeat here. ;)

My thoughts are in the direction: "lightweight", "quick", 
"functional".
Eg. "Everything that does not add to the executable size on its 
own is welcome." and "If it's absolutely required, then OK, add 
it."
-But I'd say that everything else should be up to the user to add 
(if possible).
Some people might not use strings - normally I only use 
zero-terminated character arrays myself, so I would consider this 
optional. But on the other hand, strings in D are very powerful, 
so I would hate if I weren't able to use them. Associate arrays 
are in the same boat.
Thus, if the user is lucky enough to have a file system (eg. 
SD-card), then it would make sense to have a FILE*. On the other 
hand, I wouldn't like the FILE* on anything that does not have 
any disk-like peripherals.



 Apr 29 2015



prev sibling next sibling parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:


 Wonder if it makes more sense to start from zero and add as few 
 files as
 possible.


When I started I did not know D enough to understand what 
druntime does. Just picked the easy way. The amount of required 
changes has got smaller in every release. It is easy to maintain: 
I get mainstream updates and bug fixes just by patching.
Mike has done some work with an empty runtime and Adam has a 
chapter in his book. I do not know any real programs made from 
this base



 Druntime doesn't do much useful stuff for a µC anyhow.

 - GC and rt.lifetime (new, arrays)
 - Moduleinfo
 - EH unwind support
 - AA implementation
 - vectorized array ops
 - core.time/sync/thread/demangle


UC programs mostly use static resources but I think 'new' is 
useful to initialize class objects at runtime. I got exceptions 
to work but I do not know how much use they have. There should be 
some time routines.


 What might be interesting is this.

 - core.bitop
 - maybe core.atomic
 - some gcc simd module
 - libc bindings for core.stdc.math and core.stdc.stdio for 
 printf



Printf is a little tricky. It is actually a file operation to 
stdout and that is actually a syscall to kernel. In a controller 
board we may have several devices where we can send data like 
uart and oled display. (I even have a video output where video 
signal is generated with just one spi and one timer)
I think java style would be better here like
console = new Formatter (new uartWriter (uart2) )
console.printf("",...)
This way the formatter can be reused and is not bound to any 
hardware.


I think it is possible to make a minimum bare metal runtime fom 
scratch. However, there are some requirements:
- A team. One man project may never get ready and it will not 
receive enough attention. It is also often tailored to personal 
needs which makes it difficult for others to use.
- An insider. A project from unknown people will just be ignored. 
(I think we may have one now)
- A project coordinator. I think we will find one.
- Some people who want to work. We may have a couple.

If people thik we should start, I am with.



 Apr 29 2015



 next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 04/30/2015 08:43 AM, Timo Sintonen wrote:

 Printf is a little tricky. It is actually a file operation to stdout and
 that is actually a syscall to kernel.


No, you usually have to implement some hook for outputting yourself,
e.g. putc or write, printf solely takes care of the formatting.



 Apr 30 2015



 next sibling parent reply "Jens Bauer" <doctor who.no>  writes:


On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:

 On 04/30/2015 08:43 AM, Timo Sintonen wrote:

 Printf is a little tricky. It is actually a file operation to 
 stdout and that is actually a syscall to kernel.


 No, you usually have to implement some hook for outputting 
 yourself, e.g. putc or write, printf solely takes care of the 
 formatting.


My knowledge isn't really deep here, but doesn't printf call 
vfprintf(stdout, ...) and
vfprintf call vsnprintf followed by fwrite, etc. ?

Thus I would expect the hook to be somewhere in vfprintf ?



 Apr 30 2015



  parent reply "Mike" <none none.com>  writes:


On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:

 On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:

 On 04/30/2015 08:43 AM, Timo Sintonen wrote:

 Printf is a little tricky. It is actually a file operation to 
 stdout and that is actually a syscall to kernel.


 No, you usually have to implement some hook for outputting 
 yourself, e.g. putc or write, printf solely takes care of the 
 formatting.


 My knowledge isn't really deep here, but doesn't printf call 
 vfprintf(stdout, ...) and
 vfprintf call vsnprintf followed by fwrite, etc. ?

 Thus I would expect the hook to be somewhere in vfprintf ?


As Timo said, eventually, what printf needs is the `write` 
syscall.  The C library needs to be ported to the hardware in 
question.  That requires implementing all the syscalls the the C 
library needs:  `write` for printf, `sbrk` for malloc, etc... 
(http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c) 
Sometimes the toolchain vendors provide this, sometimes the 
programmer has to do it.

IMO, C library bindings are quite useful, and an important part 
of the microcontroller ecosystem, but I don't think it should be 
a prerequisite for druntime.  I recommend keeping it as a 
separate project in Deimos, and leave it to the programmer to 
implement the syscalls if they choose to employ it.

Mike



 Apr 30 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:

 On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:

 Thus I would expect the hook to be somewhere in vfprintf ?


 As Timo said, eventually, what printf needs is the `write` 
 syscall.  The C library needs to be ported to the hardware in 
 question.  That requires implementing all the syscalls the the 
 C library needs:  `write` for printf, `sbrk` for malloc, etc... 
 (http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c) 
 Sometimes the toolchain vendors provide this, sometimes the 
 programmer has to do it.


Uhm, in that case, why not supply a weakref dummy, eg. functions 
that can be overridden.
Thus stat, open, fstat, lseek, read, write, isatty, close, link 
and unlink just do nothing at all.
If the MCU has a file-system, then it can implement those as 
strong refs.
Same about gettimeofday, getpid, execve, fork, kill - Often 
there's only a single thread and no possibility for loading and 
executing a named program.
-So it should be fairly easy to change newlib 'requirements' to 
'optional'. :)

I feel like trying this out, perhaps when the new light comes. ;)



 Apr 30 2015



  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:

 On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:

 On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:

 Thus I would expect the hook to be somewhere in vfprintf ?


 As Timo said, eventually, what printf needs is the `write` 
 syscall.  The C library needs to be ported to the hardware in 
 question.  That requires implementing all the syscalls the the 
 C library needs:  `write` for printf, `sbrk` for malloc, 
 etc... 
 (http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c) 
 Sometimes the toolchain vendors provide this, sometimes the 
 programmer has to do it.


 Uhm, in that case, why not supply a weakref dummy, eg. 
 functions that can be overridden.
 Thus stat, open, fstat, lseek, read, write, isatty, close, link 
 and unlink just do nothing at all.
 If the MCU has a file-system, then it can implement those as 
 strong refs.
 Same about gettimeofday, getpid, execve, fork, kill - Often 
 there's only a single thread and no possibility for loading and 
 executing a named program.
 -So it should be fairly easy to change newlib 'requirements' to 
 'optional'. :)

 I feel like trying this out, perhaps when the new light comes. 
 ;)


Please do not make yet another c compiler. Make a D compiler.
File system support can be an option that can be selected. A file 
in D is an object. Try to think object oriented way.



 May 01 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Friday, 1 May 2015 at 07:44:49 UTC, Timo Sintonen wrote:

 On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:

 On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:

 On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:

 Thus I would expect the hook to be somewhere in vfprintf ?


 Sometimes the toolchain vendors provide this, sometimes the 
 programmer has to do it.


 Uhm, in that case, why not supply a weakref dummy, eg. 
 functions that can be overridden.




{snip}

 -So it should be fairly easy to change newlib 'requirements' 
 to 'optional'. :)

 I feel like trying this out, perhaps when the new light comes. 
 ;)


 Please do not make yet another c compiler. Make a D compiler.
 File system support can be an option that can be selected. A 
 file in D is an object. Try to think object oriented way.


That would do nicely, but I was merely thinking about crippling 
the library so it does 'nothing'.

If we were simply to supply 'fopen' instead of 'open', returning 
an object would be fairly straightforward.

A hacky open could return a pointer to an object, because the 
returned value is a 32-bit integer, which is the same size as a 
pointer and:
     "If successful, open() returns a non-negative integer, termed 
a file
     descriptor.  It returns -1 on failure, and sets errno to 
indicate the error."

-That means though, that the RAM *must* be in the area 0x00000000 
... 0x7fffffff in order to satisfy the "non-negative integer" 
statement.

But it's of course not "pretty", and it would not be portable to 
a 64-bit system, if open does not return a 64-bit integer on 
those systems.

We could also keep returning a 'file number', then have a 
function, which found the FILE* (which is an object) for this 
'file number'. This would most likely limit the number of files 
one can keep open simultaneously. The limit could be changed 
during startup.

The problem with these two implementations is that I don't use 
files in microcontrollers, so there will be cases where it's 
insufficient. But being able to open more than 1000 files 
simultaneously does not make much sense on a microcontroller, 
which has 64K RAM or less.

If anyone has a better suggestion, I'm ears all over the place.. 
I mean I'm all ears. ;)



 May 01 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Friday, 1 May 2015 at 09:49:51 UTC, Jens Bauer wrote:

 A hacky open could return a pointer to an object, because the 
 returned value is a 32-bit integer, which is the same size as a 
 pointer and:


... would introduce a lot of dangling pointer errors instead of 
'error: file not open'...



 May 01 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:

 On 04/30/2015 08:43 AM, Timo Sintonen wrote:

 Printf is a little tricky. It is actually a file operation to 
 stdout and
 that is actually a syscall to kernel.


 No, you usually have to implement some hook for outputting 
 yourself,
 e.g. putc or write, printf solely takes care of the formatting.


I repeat here that there are several output devices in a board at 
the same time like serial port and lcd display. Printf can not be 
bound to one device at compile time.
It is not hard to take the formatter out of printf and make it a 
separate interface that can be connected to different outputs. 
this way we do not need the libc dummies. I think this is more 
the D and object oriented way. A hook sounds too much C for me.

Even better would be a CTFE formatter. There was discussion about 
this last year. Anybody knows the state?



 May 01 2015



  parent  "Meta" <jared771 gmail.com>  writes:


On Friday, 1 May 2015 at 07:15:58 UTC, Timo Sintonen wrote:

 I repeat here that there are several output devices in a board 
 at the same time like serial port and lcd display. Printf can 
 not be bound to one device at compile time.
 It is not hard to take the formatter out of printf and make it 
 a separate interface that can be connected to different 
 outputs. this way we do not need the libc dummies. I think this 
 is more the D and object oriented way. A hook sounds too much C 
 for me.


You can use std.format to get printf-style formatting and then 
pass the string to where you want.



 Even better would be a CTFE formatter. There was discussion 
 about this last year. Anybody knows the state?


There are quite a few people who want a CTFE formatter, I 
believe, but that also has the issue of causing a lot of code 
bloat. Remember also that you *can* use std.format.format at 
compile time:

enum str = "This is a %s".format("test");



 May 01 2015



prev sibling  parent  "Jens Bauer" <doctor who.no>  writes:


On Thursday, 30 April 2015 at 06:43:18 UTC, Timo Sintonen wrote:
{snip}

 I think it is possible to make a minimum bare metal runtime 
 from scratch.


{snip}

Yes I think it won't be too difficult.
All are good points that we should have in mind, while deciding 
on how we proceed.
-Also Mike's input is valuable. I agree with both of you.

Mike, Timo, Martin and Johannes:
Here's what I planned a few week ago ...
1: Get the toolchain working for Cortex-M0, Cortex-M3 and 
Cortex-M4. (Done, thanks to you).
2: Create a bunch of startup files for different devices as an 
appetizer. (Done, but ongoing)
3: Create a linker-script suitable for the casual MCU programmer. 
(Almost done)
4: Create a simple Makefile as an example. (Pending)
5: Create a set of files, which can be shared across all MCUs 
(for instance containing the *int*_t) types. This could later 
grow to a bare-metal druntime. (Pending)
6: Create a couple of driver files for one of the STM32 
microcontrollers. (Pending)
7: Create a complete example project, similar to those already 
written in C, which demonstrates that it can be done completely 
in D.
...
10: Present this to Reinhard Keil, as the ARM Keil tools now use 
LLVM. I am sure Reinhard will find the D language intriguing. But 
as he is very busy, I would like to wait until I have a fully 
functioning example, which shows that D is now ready for 
microcontrollers.

If step 10 is done too early, it might not be as appealing as if 
we have a working demo.

Mike, Timo and I all have different "approaches" and "needs".
We can definitely use this to our benefit. D)iversity is great. =D
I have the impression that Martin seems to have a good overview 
and also knowledge about different MCUs.



 Apr 30 2015



prev sibling  parent reply "Mike" <none none.com>  writes:


On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:


 Wonder if it makes more sense to start from zero and add as few 
 files as
 possible.
 Druntime doesn't do much useful stuff for a µC anyhow.

 - GC and rt.lifetime (new, arrays)
 - Moduleinfo
 - EH unwind support
 - AA implementation
 - vectorized array ops
 - core.time/sync/thread/demangle

 What might be interesting is this.

 - core.bitop
 - maybe core.atomic
 - some gcc simd module
 - libc bindings for core.stdc.math and core.stdc.stdio for 
 printf



Starting from zero appeals to my way of thinking.  I've made 
several attempts at this both on the PC and for microcontrollers, 
so please allow me to offer my thoughts on the idea:

If starting from zero, I recommend narrowing the scope to simply 
runtime initialization. IMO, if one can get to main with a small 
subset of the language ready for use, the rest is mostly icing on 
the cake.

While this may seem simple to achieve, I think it will raise a 
few questions that will need answering.

* Can ModuleInfo be leveraged, without introducing overhead, to 
call module constructors and static constructors?  They might be 
useful for hardware initialization.
* Is dynamic memory allocation a requirement of D, or a library 
feature?
* Does D need the C runtime, or can it init on its own?
* Should the C standard library bindings be part of the runtime, 
or exist as an external Deimos library?  Either way they can 
still be used by the runtime, I'm just suggesting that they 
should be encapsulated.
* What will be done about TypeInfo for now?  It's causing me some 
serious code-bloat problems.  See 
http://forum.dlang.org/post/quemhwpgijwmqtpxukiv forum.dlang.org
* Is data and bss initialization part of  the runtime, or 
delegated to toolchain, silicon, and BSP vendors?

I think runtime initialization is a relatively simple task, but 
would still present a few challenges, choices, and even a few 
problems.  However, due to the fact that it's narrow in scope, I 
suspect it would be a likely success and could put some momentum 
in the right direction.

Mike



 Apr 30 2015



 next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 04/30/2015 01:30 PM, Mike wrote:

 While this may seem simple to achieve, I think it will raise a few
 questions that will need answering.
 
 * Can ModuleInfo be leveraged, without introducing overhead, to call
 module constructors and static constructors?  They might be useful for
 hardware initialization.


Currently D sorts modules by initialization order,which requires every
moduleinfo to contain an array of imported modules. Quite a lot of RAM
for a nice to have feature, so we should drop it or at least provide a
-fno-moduleinfo switch.


 * Is dynamic memory allocation a requirement of D, or a library feature?


Definitely a library feature, though many language features, like array
appending, won't work without it (delegate closures won't even work
without a GC).


 * Does D need the C runtime, or can it init on its own?


It shouldn't need a C runtime.


 * Should the C standard library bindings be part of the runtime, or
 exist as an external Deimos library?  Either way they can still be used
 by the runtime, I'm just suggesting that they should be encapsulated.


It doesn't cost you anything to include the bindings in a release, they
could be maintained in a separate project if that helps.


 * What will be done about TypeInfo for now?  It's causing me some
 serious code-bloat problems.  See
 http://forum.dlang.org/post/quemhwpgijwmqtpxukiv forum.dlang.org


Implement a -fno-rtti switch for GDC.


 * Is data and bss initialization part of  the runtime, or delegated to
 toolchain, silicon, and BSP vendors?


We should provide appropriate linker scripts and do the initialization.



 Apr 30 2015



 next sibling parent reply "Mike" <none none.com>  writes:


On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:


 
 * Can ModuleInfo be leveraged, without introducing overhead, 
 to call
 module constructors and static constructors?  They might be 
 useful for
 hardware initialization.


 Currently D sorts modules by initialization order,which 
 requires every
 moduleinfo to contain an array of imported modules. Quite a lot 
 of RAM
 for a nice to have feature, so we should drop it or at least 
 provide a
 -fno-moduleinfo switch.


Agreed.  Luckily -fno-emit-moduleinfo is already implemented, but 
without a ModuleInfo implementation, this will be a required 
switch to get a successful build.


 * Is dynamic memory allocation a requirement of D, or a 
 library feature?


 Definitely a library feature, though many language features, 
 like array
 appending, won't work without it (delegate closures won't even 
 work
 without a GC).


Good!


 * Does D need the C runtime, or can it init on its own?


 It shouldn't need a C runtime.


Good!


 * Should the C standard library bindings be part of the 
 runtime, or
 exist as an external Deimos library?  Either way they can 
 still be used
 by the runtime, I'm just suggesting that they should be 
 encapsulated.


 It doesn't cost you anything to include the bindings in a 
 release, they
 could be maintained in a separate project if that helps.


Yes, that helps.  There's already a project created in Deimos: 
https://github.com/D-Programming-Deimos/libc


 * What will be done about TypeInfo for now?  It's causing me 
 some
 serious code-bloat problems.  See
 http://forum.dlang.org/post/quemhwpgijwmqtpxukiv forum.dlang.org


 Implement a -fno-rtti switch for GDC.


What about https://issues.dlang.org/show_bug.cgi?id=12270?  
...perhaps in addition to -fno-rtti.


 * Is data and bss initialization part of  the runtime, or 
 delegated to
 toolchain, silicon, and BSP vendors?


 We should provide appropriate linker scripts and do the 
 initialization.


The linker script can give the location of the data and bss 
segments.  My question is really about whether or not the 
druntime implementation should assume responsibility for loading 
the data segment from flash and zeroing bss.  I suppose that 
should be left to the vendor's BSP, not part of druntime itself.

I guess what I'm trying to articulate is that currently when you 
download an MCU toolchain, it contains a collection of things 
from many different vendors (GCC, binutils, newlib, startup 
files, linker scripts, multilibs, etc...), all in one package.  I 
recommend, not doing that with this druntime.  druntime should 
just be the implementation of D language features for 
microcontrollers.

Once a minimal druntime is created, some other effort can take 
that druntime and package it with a compiler, linker, startup 
files, linker scripts, c standard library, debugger, flash 
programmer, etc... and make a convenient downloadable/installable 
package for immediate use.

Assuming that is an appropriate strategy, what does the first 
druntime release look like.
* For example: What will `assert` do?  Is that just a stub to be 
implemented by the programmer?
* What are druntime's "syscalls" that need to be implemented by 
the silicon vendor, BSP, and/or programmer (I'm using a newlib 
port analogy here)?  What does druntime do, and what does it 
require its users to do?

My mind is currently seeing an object.d with some aliases and 
some TypeInfo stubs, __entrypoint.d, and a minimal rt/dmain2.d.  
That will give you a build and get you to main() for a trivial 
program, but you'll start getting linker errors, and potentially 
runtime errors, as you begin to employ more of D's features; even 
the simple ones like `assert`.

That is one of the things that's making it difficult for me to 
simply get a working language.  druntime has features that really 
seem to be more "standard library" features (e.g. `assert`), but 
they are mingled with the language implementation.  It, 
therefore, makes it a challenge to get a build, separate 
concerns, and delegate implementation to users.

Mike



 Apr 30 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Thursday, 30 April 2015 at 23:03:48 UTC, Mike wrote:

 On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:


 * Is data and bss initialization part of  the runtime, or 
 delegated to toolchain, silicon, and BSP vendors?


 We should provide appropriate linker scripts and do the 
 initialization.


 The linker script can give the location of the data and bss 
 segments.  My question is really about whether or not the 
 druntime implementation should assume responsibility for 
 loading the data segment from flash and zeroing bss.  I suppose 
 that should be left to the vendor's BSP, not part of druntime 
 itself.


How about providing functions for copying data and zeroing bss ?
-In my startup file, I use functions for that, because they're 
optimized pretty well.
The code is very similar to my optimized #define in C.

Most Cortex-M microcontrollers allow you to set the clock 
frequency.
It's a good idea to do this before you start copying a large 
block of data, because that means the startup time is quicker.
The drawback is that ... CMSIS wants to write in the BSS (the 
CoreClockFrequency variable, for instance), and that's just 
erased when BSS is cleared - I wish they had just reserved a 
hardware register for these 4 variables.

Anyway, personally, I like the startup file to contain the 
data/bss init, because I might want to customize it. My startup 
files allow you to override Reset_Handler and each exception, 
which means you don't even have to modify the startup file. That 
means one less template-file to copy to every project.


 I guess what I'm trying to articulate is that currently when 
 you download an MCU toolchain, it contains a collection of 
 things from many different vendors (GCC, binutils, newlib, 
 startup files, linker scripts, multilibs, etc...), all in one 
 package.  I recommend, not doing that with this druntime.  
 druntime should just be the implementation of D language 
 features for microcontrollers.


Agree.


 Once a minimal druntime is created, some other effort can take 
 that druntime and package it with a compiler, linker, startup 
 files, linker scripts, c standard library, debugger, flash 
 programmer, etc... and make a convenient 
 downloadable/installable package for immediate use.


Agree.
Linker-scripts can usually be written so they work well with 
multiple devices from the same vendor. I'm not talking about 
specific RAM and Flash settings, but the main body of the linker 
script. Small 3 .. 8 line scripts can then include the body, 
which provides all the standard stuff. So here I'm talking about 
a body linker-script could be provided for each vendor (not each 
device family or each device). If each device family or device 
requires different attention, then I suggest something like 
Vendor:DeviceFamily:DeviceSpecific.
Thus it would not be overwhelming writing one linker script per 
vendor and it would be fairly straight-forward for the casual 
user to add a new device or even a device family if needed.
I'd also prefer having the linker-script in a location, outside 
each project (because I have many projects and I hate duplicates 
and updating each duplicate each time I find something that needs 
to be changed).


 Assuming that is an appropriate strategy, what does the first 
 druntime release look like.
 * For example: What will `assert` do?  Is that just a stub to 
 be implemented by the programmer?


Most asserts on microcontrollers I've seen are just implemented 
as while(1){}
-But one could probably also trigger the debugger (BKPT), 
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then 
version(ASSERT_BKPT) could be used to add a breakpoint before 
that while(1){}. Thus --version=ASSERT_BKPT could be specified on 
the command-line.
Would it be possible to 'extend' an existing assert; eg. the user 
might want to be notified via the U(S)ART ?



 Apr 30 2015



  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:

 Most asserts on microcontrollers I've seen are just implemented 
 as while(1){}
 -But one could probably also trigger the debugger (BKPT), 
 HardFault or RESET if necessary.
 Perhaps the default could be while(1){} and then 
 version(ASSERT_BKPT) could be used to add a breakpoint before 
 that while(1){}. Thus --version=ASSERT_BKPT could be specified 
 on the command-line.
 Would it be possible to 'extend' an existing assert; eg. the 
 user might want to be notified via the U(S)ART ?


In a desktop computer it is easy to return to the system. A 
flying aeroplane can not stop its engines and wait the pilot to 
reboot...

We do have the 'weak' attribute now. Just make a weak default 
handler that stops. Then the application designer can override it 
with whatever the application needs.



 May 01 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Friday, 1 May 2015 at 07:30:03 UTC, Timo Sintonen wrote:

 On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:

 Most asserts on microcontrollers I've seen are just 
 implemented as while(1){}
 -But one could probably also trigger the debugger (BKPT), 
 HardFault or RESET if necessary.
 Perhaps the default could be while(1){} and then 
 version(ASSERT_BKPT) could be used to add a breakpoint before 
 that while(1){}. Thus --version=ASSERT_BKPT could be specified 
 on the command-line.
 Would it be possible to 'extend' an existing assert; eg. the 
 user might want to be notified via the U(S)ART ?


 In a desktop computer it is easy to return to the system. A 
 flying aeroplane can not stop its engines and wait the pilot to 
 reboot...


The 'assert' is intended for debugging, right ?
If not enabling --version=ASSERT_LOOP, --version=ASSERT_BKPT, 
--version=ASSERT_RESET or any other version, then assert should 
simply default to an empty funciton.

Personally, I never ever used assert myself. I always handle the 
situation by making sure my data were in range; if they aren't, I 
correct them.


 We do have the 'weak' attribute now. Just make a weak default 
 handler that stops. Then the application designer can override 
 it with whatever the application needs.


Yes, of course. Why didn't I think of this ? :)



 May 01 2015



prev sibling  parent  "Mike" <none none.com>  writes:


Martin,

This is a bit of a tangent, but I would like to know what your 
thoughts are on this: 
http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org

The problem is that when we use an unimplemented feature of D, 
the best we can hope for is to generate a linker error.  I 
proposed this idea as a way to make the conversation between the 
user and their druntime implementation more polished.  The 
runtime implementation, through its .di files informs the 
compiler and user what is and isn't supported so the user can get 
friendly compile-time errors and the compiler can make better 
assumptions about codegen.

Mike



 Apr 30 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Thursday, 30 April 2015 at 11:30:33 UTC, Mike wrote:


 Starting from zero appeals to my way of thinking.  I've made 
 several attempts at this both on the PC and for 
 microcontrollers, so please allow me to offer my thoughts on 
 the idea:

 While this may seem simple to achieve, I think it will raise a 
 few questions that will need answering.

 * Can ModuleInfo be leveraged, without introducing overhead, to 
 call module constructors and static constructors?  They might 
 be useful for hardware initialization.


I think we should omit moduleinfo totally and so we can not have 
module constructors. I think pointers to static constructors are 
available in a certain section that I have not in my link script. 
Adding this section should make them available.


 * Is dynamic memory allocation a requirement of D, or a library 
 feature?


We should agree whether we are making only yet another C compiler 
or do we want the D compiler. The ability to use object oriented 
features was the reason I started with D. I think we do npot need 
full gc but I want to create objects at least at start. they will 
live trough the program so I have no need to delete then.
I think it is possible to have the memory and object management 
things as set of files that may optionally compiled in or left 
out.  There must be better and smaller malloc programs than the 
one I use now.


 * Does D need the C runtime, or can it init on its own?


We should not depend on any libc. If we need anything from libc 
we must require/provide a multilib libc set that has been 
compiled with the correct compiler flags.


 * Should the C standard library bindings be part of the 
 runtime, or exist as an external Deimos library?  Either way 
 they can still be used by the runtime, I'm just suggesting that 
 they should be encapsulated.


The bindings do not take space in the library but what are we 
doing with bindings if we do not have libc? I think it would be 
better to have a separate libc port project that contains the 
library and bindings.


 * What will be done about TypeInfo for now?  It's causing me 
 some serious code-bloat problems.  See 
 http://forum.dlang.org/post/quemhwpgijwmqtpxukiv forum.dlang.org


I hope the compiler devs can tell us if it is possible to remove 
typeinfo totally and what language features we will lose then.


 * Is data and bss initialization part of  the runtime, or 
 delegated to toolchain, silicon, and BSP vendors?


In C the data initialization is made before main. The copying is 
target independent but may depend on build environment, like what 
symbols the linker script provides. There is no general rule if 
any hardware specific init is needed at this point, before or 
after.
One thing that has not been mentioned yet is that D is using TLS 
by default. Tdata and tbss can be combined to global data and 
bss. However, it is not hard to make śeparate sections for them 
and be prepared to multithreaded system.



 Apr 30 2015



 next sibling parent reply Johannes Pfau <nospam example.com>  writes:


Am Fri, 01 May 2015 06:57:07 +0000
schrieb "Timo Sintonen" <t.sintonen luukku.com>:


 I think we should omit moduleinfo totally and so we can not have 
 module constructors. I think pointers to static constructors are 
 available in a certain section that I have not in my link script. 
 Adding this section should make them available.


C-like constructors. I've got some old code which allows attaching a
 attribute("cctor") to a extern(C) function to make it a C-constructor.
That code could be revived quickly if it's useful.

Outputting normal D module ctors as C-ctors is  possible but 'hacky':
First, the calling convention doesn't match. In order to be compatible
C-constructors should stay extern(C). Now extern(D/C) are actually the
same for all GDC supported architectures, but still. There's also the
issue that it's a semantic change as you can no longer rely on cycle
detection.

TLDR: I'd prefer using  cctor extern(C) void foo() {} instead of normal
d module ctors.

Bonus points: You can have more than one  cctor per module.



 May 01 2015



  parent reply "Mike" <none none.com>  writes:


On Friday, 1 May 2015 at 07:34:04 UTC, Johannes Pfau wrote:


 TLDR: I'd prefer using  cctor extern(C) void foo() {} instead 
 of normal
 d module ctors.

 Bonus points: You can have more than one  cctor per module.


How do you propose defining calling order with this feature?



 May 02 2015



  parent  Johannes Pfau <nospam example.com>  writes:


Am Sat, 02 May 2015 09:45:56 +0000
schrieb "Mike" <none none.com>:


 On Friday, 1 May 2015 at 07:34:04 UTC, Johannes Pfau wrote:
 

 TLDR: I'd prefer using  cctor extern(C) void foo() {} instead 
 of normal
 d module ctors.

 Bonus points: You can have more than one  cctor per module.


 
 How do you propose defining calling order with this feature?


Not at all? C constructors don't really have a defined calling order.
You can optionally specify a 'priority' integer but this only works well
if you control all constructor priorities.



 May 02 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:


 * Is dynamic memory allocation a requirement of D, or a 
 library feature?


 We should agree whether we are making only yet another C 
 compiler or do we want the D compiler. The ability to use 
 object oriented features was the reason I started with D. I 
 think we do npot need full gc but I want to create objects at 
 least at start. they will live trough the program so I have no 
 need to delete then.
 I think it is possible to have the memory and object management 
 things as set of files that may optionally compiled in or left 
 out.  There must be better and smaller malloc programs than the 
 one I use now.


I'm totally with you on this.  I don't want a "better C" or a 
"worse D".  I hope that programming in D on these 
microcontrollers looks very much like the idomatic D in other 
domains.  I want dyanamic memory allocation to be available for 
sure, but I don't want it to be a prerequisite like the garbage 
collector currently is.  IMO it should be opt in.

Also, aren't you using this malloc 
(https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/m
lloc.c?at=default). 
  That looks small and tight, but should be written in D :-)

Mike



 May 01 2015



 next sibling parent reply "Jens Bauer" <doctor who.no>  writes:


On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:

 On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:

 IMO it should be opt in.


Agree. :)

The problem I've seen with most C-solutions, is that once someone 
uses printf, the binary suddenly grows out of proportions. (It 
may be because the programmer included a line for debugging only, 
and that causes the otherwise 1K program to be huge and almost 
not fit the MCU).


 Also, aren't you using this malloc 
 (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
  That looks small and tight, but should be written in D :-)


It looks small and quite quick, but I think it would choke if 
allocating 256 blocks of 1 byte each and then freeing the first 
255 of them. But I absolutely like the simplicity.

I wrote a (much larger) MiniMalloc (also C), which can take any 
number of blocks and any size.
The block address is guaranteed to be on a 4-byte boundary.
Allocating a block of size 0 will always return the same address; 
this can never be freed.
The good part is that you can use it with fairly small 
microcontrollers up to the entire 32-bit address range and no 
maximum number of blocks/maximum block size, so you can easily 
allocate a couple of buffers for your 24-bit TFT display.
The drawback: If you make a 'buffer-overflow', eg write past your 
block's memory, you will corrupt the header of the next block, 
because I placed the header in front of each block.
Thus my malloc/calloc/realloc/free is very old-fashioned, but it 
does join neighbouring blocks when they're released. I've 
stress-tested it for more than 24 hours, and even though it was 
fairly fragmented, there were no signs of other problems. It's 
been tested with 0xdeadbeef fills, 0x00000000 fills and unfilled.

Is it possible to write the malloc so it's "garbage 
collector-friendly" ?
-Eg. would certain algorithms be better than others; would a few 
'accessor' or 'query' functions be helpful; would it be useful 
for the garbage collector to be able to store a couple of flags ?



 May 01 2015



 next sibling parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:


 The problem I've seen with most C-solutions, is that once 
 someone uses printf, the binary suddenly grows out of 
 proportions. (It may be because the programmer included a line 
 for debugging only, and that causes the otherwise 1K program to 
 be huge and almost not fit the MCU).


Std.format, as suggested, would be too big. I tis easty to copy 
the printf formatter from libc sources. Or just write an own. It 
does not have to support all the features. It is a matter of 
taste if it is a c like printf function or a formatter class. Or 
both if we like. Only the used ones are picked from the library.
.

 Also, aren't you using this malloc 
 (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
 That looks small and tight, but should be written in D :-)


 It looks small and quite quick, but I think it would choke if 
 allocating 256 blocks of 1 byte each and then freeing the first 
 255 of them. But I absolutely like the simplicity.


Every solution has its sides. This would perform poorly in a 
solution that allocates and frees big amounts of small blocks. 
But it is good when resources are allocated at the beginning and 
then used trough the whole lifetime of the program.



 May 02 2015



 next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:

 Std.format, as suggested, would be too big. I tis easty to copy 
 the printf formatter from libc sources. Or just write an own.


No need to rewrite libc, just link against it and use whatever is 
needed.


 It is a matter of taste if it is a c like printf function or a 
 formatter class. Or both if we like. Only the used ones are 
 picked from the library.


You could implement more high level application code like a 
formatting library as dub package.



 May 02 2015



  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:

 On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:

 Std.format, as suggested, would be too big. I tis easty to 
 copy the printf formatter from libc sources. Or just write an 
 own.


 No need to rewrite libc, just link against it and use whatever 
 is needed.


I have assumed we are going the way that libc is not a 
requirement. If libc is required we must build a full multilib 
set and possibly include them in binary releases.
This is a question that we can discuss.



 It is a matter of taste if it is a c like printf function or a 
 formatter class. Or both if we like. Only the used ones are 
 picked from the library.


 You could implement more high level application code like a 
 formatting library as dub package.


A separate package is a good idea for advanced things.



 May 02 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Saturday, 2 May 2015 at 10:38:51 UTC, Timo Sintonen wrote:

 On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:

 On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:

 No need to rewrite libc, just link against it and use whatever 
 is needed.


 I have assumed we are going the way that libc is not a 
 requirement. If libc is required we must build a full multilib 
 set and possibly include them in binary releases.
 This is a question that we can discuss.


Personally, I'd like my distribution package to be the 'full 
package', which provides:
C, C++ and D.
The reason for providing C and C++, is that most vendors write 
their driver libraries in C, and I do not think they're going to 
rewrite their entire driver library, because there's a new 
language in town. ;)
Perhaps some vendors would provide additional D compatible files, 
but it's little likely that they would write a library in D 
without autogenerating it using a script; even that is little 
likely.
Anoher reason is 'the transition phase'. Many users already know 
C, and will be doing certain things in C, until they've learned 
D. They also have sources they've already written, which they 
might want to use, in order to get up and running quickly.


 It is a matter of taste if it is a c like printf function or 
 a formatter class. Or both if we like. Only the used ones are 
 picked from the library.


 You could implement more high level application code like a 
 formatting library as dub package.


 A separate package is a good idea for advanced things.


I think it's good to split it up. Also development-wise.
Think of it like we need to take small steps as well; we can't 
start testing printf support, before we can build a minimum 
binary for instance.



 May 02 2015



prev sibling  parent  "Jens Bauer" <doctor who.no>  writes:


On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:

 On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:


 Std.format, as suggested, would be too big. I tis easty to copy 
 the printf formatter from libc sources. Or just write an own. 
 It does not have to support all the features. It is a matter of 
 taste if it is a c like printf function or a formatter class. 
 Or both if we like. Only the used ones are picked from the 
 library.


I like this solution. Very, very few people use %1$08x, but 
instead they add the argument twice, for instance. Also very few 
people set a length on %s.
Most of the time, it's just %s, %d and %x, which is used (where 
%d and %x might have a length like %3d or %08x).


 That looks small and tight, but should be written in D :-)


 It looks small and quite quick, but I think it would choke if 
 allocating 256 blocks of 1 byte each and then freeing the 
 first 255 of them. But I absolutely like the simplicity.


 Every solution has its sides. This would perform poorly in a 
 solution that allocates and frees big amounts of small blocks. 
 But it is good when resources are allocated at the beginning 
 and then used trough the whole lifetime of the program.


Yes. I think that if I had both, I would sometimes pick the one 
and sometimes the other, depending on my needs. If instantiating 
classes at startup, it's definitely great for small devices.
I think it's possible to extend it slightly, so when two or three 
neighbouring blocks are free, they can be combined into one free 
block; the remaining of the array just have to be moved towards 
the first entry.



 May 02 2015



prev sibling next sibling parent  "Martin Nowak" <code dawg.eu>  writes:


On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:

 The problem I've seen with most C-solutions, is that once 
 someone uses printf, the binary suddenly grows out of 
 proportions. (It may be because the programmer included a line 
 for debugging only, and that causes the otherwise 1K program to 
 be huge and almost not fit the MCU).


Granted printf isn't small, but it's not that large either, sure 
you're not including %f float formatting?
https://launchpadlibrarian.net/200699979/readme.txt



 May 02 2015



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:

 Is it possible to write the malloc so it's "garbage 
 collector-friendly" ?


Garbage collection on microcontrollers doesn't make sense, 
because the memory consumption will always be significantly 
higher than with deterministic memory management.



 May 02 2015



  parent reply "Jens Bauer" <doctor who.no>  writes:


On Saturday, 2 May 2015 at 09:17:57 UTC, Martin Nowak wrote:

 On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:

 Is it possible to write the malloc so it's "garbage 
 collector-friendly" ?


 Garbage collection on microcontrollers doesn't make sense, 
 because the memory consumption will always be significantly 
 higher than with deterministic memory management.


Will it be possible to have associative arrays without garbage 
collection ?
What about dynamic strings and dynamic arrays, don't they need GC 
?



 May 02 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:

 Will it be possible to have associative arrays without garbage 
 collection ?


You can write an AA container. A RefCounted AA implementation 
might allow unsafe escaping though.


 What about dynamic strings and dynamic arrays, don't they need 
 GC ?


Same here array slices require a GC to be safe, but one could 
implement them like std::vector.

While built-in arrays and AAs are nice to have it's trivial to 
replace them with other containers, no need for GC.

I never even needed dynamic memory allocation on a 
microcontroller.



 May 02 2015



 next sibling parent reply "Mike" <none none.com>  writes:


On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:


 I never even needed dynamic memory allocation on a 
 microcontroller.


For many typical uses of microcontrollers this is absolutely 
true.  However, the 32-bit microcontrollers from ARM are much 
more powerful than the likes of AVR 8-bit microcontrollers in, 
for example, the Arduino Uno. Not all uses of microcontrollers 
are hard real-time, and these 32-bit ARM chips have processing 
power to spare.

I currently use them to build HMIs (Human Machine Interface, e.g. 
a GUI).  If I'm just doing machine control, I have absolutely no 
need for dynamic memory allocation, but if I'm building a user 
interface that involves images, TrueType fonts, vector graphics, 
etc..., dynamic memory allocation is quite useful, if not 
essential.

I suggest refraining from requiring or preventing any feature, 
including garbage collection and exceptions.  Rather, we can 
gradually make each feature available as the need arises, and the 
user can opt in and make their own tradeoffs.

Mike



 May 02 2015



 next sibling parent reply "Jens Bauer" <doctor who.no>  writes:


On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:

 On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:

 {snip} these 32-bit ARM chips have processing power to spare.


Definitely. Even though they might only be running between 100 
and 200 MHz, they're much more powerful than the computers we had 
in the 80's.


 {snip} if I'm  building a user interface that involves images,
 TrueType fonts, vector graphics, etc..., dynamic memory
 allocation is quite useful, if not essential.


TTF. That sounds pretty amazing! :)


 I suggest refraining from requiring or preventing any feature, 
 including garbage collection and exceptions.  Rather, we can 
 gradually make each feature available as the need arises, and 
 the user can opt in and make their own tradeoffs.


Agree. I'm hoping to find some good places where we can slice the 
cake, so we don't have to eat it all at once. ;)

I'll not be working much on a malloc, but I will be thinking a 
little about a size-optimized / well-performing malloc could be 
written (approximately).
Perhaps I could combine my MiniMalloc with clusters of small 
blocks.
Maybe I could make an 'opt-in' on small blocks.
(In my first implementation of small-block clusters, I had blocks 
of sizes 1 ... 32 bytes, and each cluster contained 128 blocks. 
Each block had a bit in a 128-bit field, which marked it as 
used/free). It was fairly quick to find the cluster a block 
belonged to, and the overhead per block was only a single bit + 
the malloc header. If running out of free blocks in a cluster, 
another cluster was allocated.
This might be suitable for MCUs, but clusters should probably be 
in 16 blocks or 32 blocks, in order to avoid wasting too much 
space. Block sizes might only need to be 1, 2, 4, 8, 16 and 32 
bytes (perhaps depending on the RAM available).



 May 02 2015



 next sibling parent  "Jens Bauer" <doctor who.no>  writes:


On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:

 {snip} the overhead per block was only a single bit + the 
 malloc header.


Correction: The overhead was a single bit + 1/128 of the malloc 
header, because we had 128 blocks per cluster.
Thus if having a cluster of 32 blocks, the overhead would be 2 
bits per block.
A cluster of 16 blocks would have an overhead of 3 bits per 
block, because my header size is 32 bits and always 4-byte 
aligned.



 May 02 2015



prev sibling  parent  "Martin Nowak" <code dawg.eu>  writes:


On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:

 I'll not be working much on a malloc, but I will be thinking a 
 little about a size-optimized / well-performing malloc could be 
 written (approximately).
 Perhaps I could combine my MiniMalloc with clusters of small 
 blocks.


Newlib already ships with a size optimized malloc.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=8d6ca5ce05a89853e40f80b583f0680a77bd4b67



 May 03 2015



prev sibling  parent  "Martin Nowak" <code dawg.eu>  writes:


On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:

 I suggest refraining from requiring or preventing any feature, 
 including garbage collection and exceptions.  Rather, we can 
 gradually make each feature available as the need arises, and 
 the user can opt in and make their own tradeoffs.


Yes exactly



 May 03 2015



prev sibling  parent  "Jens Bauer" <doctor who.no>  writes:


On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:

 On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:

 Will it be possible to have associative arrays without garbage 
 collection ?


 You can write an AA container. A RefCounted AA implementation 
 might allow unsafe escaping though.


I think RefCount would do nicely for my own use. (I'm very much 
used to RefCount from ObjC; never grew up to use the GC there).


 What about dynamic strings and dynamic arrays, don't they need 
 GC ?


 Same here array slices require a GC to be safe, but one could 
 implement them like std::vector.

 While built-in arrays and AAs are nice to have it's trivial to 
 replace them with other containers, no need for GC.


Sounds good. :)


 I never even needed dynamic memory allocation on a 
 microcontroller.


Me neither, but I don't know if that would change.
I'm especially thinking about making a small database on a 
Cortex-M, which would be connected via Ethernet. Thus it would be 
small, diskless, but respond quickly.
Since the STM32F429 Discovery board comes with an on-board 64Mbit 
SDRAM, it's very tempting to have optional support for large 
memory.

After trying AA on Javascript, I got quite interested in them 
(especially for database-use with Bloom filters).

AA would very likely allocate a lot of small blocks. I once wrote 
a very quick malloc, which had clusters of fixed size blocks for 
block sizes less than 32 bytes. It sped up our product so much 
that my boss (who worked on a different platform) came and asked 
how I did it. :)



 May 02 2015



prev sibling  parent reply "Timo Sintonen" <t.sintonen luukku.com>  writes:


On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:


 I'm totally with you on this.  I don't want a "better C" or a 
 "worse D".  I hope that programming in D on these 
 microcontrollers looks very much like the idomatic D in other 
 domains.  I want dyanamic memory allocation to be available for 
 sure, but I don't want it to be a prerequisite like the garbage 
 collector currently is.  IMO it should be opt in.


We should make a list of D features that we can have with and 
without malloc. Then a test program that use all these feqatures.
An object file is not picked from the library if it is not used. 
Options are not needed when compiling the library.


 Also, aren't you using this malloc 
 (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
  That looks small and tight, but should be written in D :-)


It is ok for me and it is used in our production code that does 
not yet use D. I am still open for other solutions.
These functions should be at least extern C because library code 
written in C may use them.



 May 02 2015



  parent  "Martin Nowak" <code dawg.eu>  writes:


On Saturday, 2 May 2015 at 08:33:34 UTC, Timo Sintonen wrote:

 It is ok for me and it is used in our production code that does 
 not yet use D. I am still open for other solutions.
 These functions should be at least extern C because library 
 code written in C may use them.


Newlib already comes with a malloc implementation, you just need 
to implement _sbrk_r.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=8d6ca5ce05a89853e40f80b583f0680a77bd4b67



 May 02 2015



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:


 I think we should omit moduleinfo totally and so we can not 
 have module constructors. I think pointers to static 
 constructors are available in a certain section that I have not 
 in my link script. Adding this section should make them 
 available.


Whats wrong with module constructors?  Why would C-like 
constructors be preferred?



 May 01 2015



  parent  Johannes Pfau <nospam example.com>  writes:


Am Sat, 02 May 2015 06:40:06 +0000
schrieb "Mike" <none none.com>:


 On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
 

 I think we should omit moduleinfo totally and so we can not 
 have module constructors. I think pointers to static 
 constructors are available in a certain section that I have not 
 in my link script. Adding this section should make them 
 available.


 
 Whats wrong with module constructors?  Why would C-like 
 constructors be preferred?


Module constructors guarantee cycle detection at runtime. This requires
most of ModuleInfo data (imported modules) and quite some runtime code.
Of course we could ignore that requirement but I think the same code
should not behave differently on microcontroller D/normal D.

Bonus point: You can have more than one C-like ctor per module.



 May 02 2015



prev sibling  parent  "Martin Nowak" <code dawg.eu>  writes:


On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:

 * Is dynamic memory allocation a requirement of D, or a 
 library feature?


 We should agree whether we are making only yet another C 
 compiler or do we want the D compiler. The ability to use 
 object oriented features was the reason I started with D. I 
 think we do npot need full gc but I want to create objects at 
 least at start. they will live trough the program so I have no 
 need to delete then.


You can use malloc+emplace, scoped!Class, or put the instance in 
the data segment.



 May 02 2015



prev sibling  parent reply Johannes Pfau <nospam example.com>  writes:


Am Mon, 27 Apr 2015 07:55:09 +0000
schrieb "Martin Nowak" <code dawg.eu>:


 On Monday, 27 April 2015 at 05:30:55 UTC, Timo Sintonen wrote:

 One of the biggest issues has been the multilib build. If it is 
 solved now we are one step closer to be able to build binaries.


 
 Great, I tried to find out how GDC binaries are build, but 
 couldn't find any script.


Since 2.066 the binaries on gdcproject.org are built with crosstool-NG
(and an additional D script) in a docker container. I wanted to publish
this some time ago but I still need to write the documentation and
right now I'm kinda busy with other stuff...



 Apr 27 2015



 next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 April 2015 at 19:25, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Mon, 27 Apr 2015 07:55:09 +0000
 schrieb "Martin Nowak" <code dawg.eu>:


 On Monday, 27 April 2015 at 05:30:55 UTC, Timo Sintonen wrote:

 One of the biggest issues has been the multilib build. If it is
 solved now we are one step closer to be able to build binaries.


 Great, I tried to find out how GDC binaries are build, but
 couldn't find any script.


 Since 2.066 the binaries on gdcproject.org are built with crosstool-NG
 (and an additional D script) in a docker container. I wanted to publish
 this some time ago but I still need to write the documentation and
 right now I'm kinda busy with other stuff...


Which reminds me, I've dabbled with docker, but again, there are too
many things for one person to busy oneself with...

https://registry.hub.docker.com/u/ibuclaw/gdc/

I'd like to get back to gdb support, but people keep on pushing out
releases at the wrong time. :-P

Iain



 Apr 27 2015



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 27 April 2015 at 17:25:50 UTC, Johannes Pfau wrote:

 Since 2.066 the binaries on gdcproject.org are built with 
 crosstool-NG
 (and an additional D script) in a docker container.


That's interesting, do the Windows binaries have some binary 
dependency on MinGW?
It currently seems that we'd to build ddmd with GDC or LDC to get 
a fast enough compiler. Maybe that would allow us to 
cross-compile release as well.
Currently I'm using virtual box with 5 different OSes to build a 
release.



 May 03 2015



  parent  Johannes Pfau <nospam example.com>  writes:


Am Sun, 03 May 2015 15:18:40 +0000
schrieb "Martin Nowak" <code dawg.eu>:


 On Monday, 27 April 2015 at 17:25:50 UTC, Johannes Pfau wrote:

 Since 2.066 the binaries on gdcproject.org are built with 
 crosstool-NG
 (and an additional D script) in a docker container.


 
 That's interesting, do the Windows binaries have some binary 
 dependency on MinGW?


AFAIK no. It only uses standard windows dlls.


 It currently seems that we'd to build ddmd with GDC or LDC to get 
 a fast enough compiler. Maybe that would allow us to 
 cross-compile release as well.


That should work. However, we only have very basic MinGW support in
GDC. I don't think it can compile a working ddmd but we'll have to make
it work for the windows->arm cross compilers anyway.


 Currently I'm using virtual box with 5 different OSes to build a 
 release.


I used one VM and that was already kinda annoying. Docker is really
useful for such build-tasks. (easy to use((not need to setup ssh etc)
reproducible, redistributable, fast & parallelizable)



 May 03 2015



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Sunday, 26 April 2015 at 15:55:34 UTC, Jens Bauer wrote:

 On Sunday, 26 April 2015 at 14:18:24 UTC, Dicebot wrote:

 On Sunday, 26 April 2015 at 07:04:06 UTC, Jens Bauer wrote:

 Some of you already know that I've been working on startup 
 files for STM32F4xx and LPC17xx.

 https://github.com/jens-gpio/MCU


 Please mention that in wiki.dlang.org
 May be even worth creating dedicated "ARM" page there which 
 will aggregated all related articles.


 Done.
 http://wiki.dlang.org/Microcontroller_startup_files

 -This is my first successful Wiki page, BTW. :)


Thanks! It is important for that information not be lost among 
hundreds of NG posts, wiki is much more searchable.



 Apr 26 2015



  parent  "Jens Bauer" <doctor who.no>  writes:


On Sunday, 26 April 2015 at 16:34:09 UTC, Dicebot wrote:

 On Sunday, 26 April 2015 at 15:55:34 UTC, Jens Bauer wrote:

 Done.
 http://wiki.dlang.org/Microcontroller_startup_files


 Thanks! It is important for that information not be lost among 
 hundreds of NG posts, wiki is much more searchable.


No problem. I hesitated, because I'm not sure of the directory 
structure yet.
I may have to change it again, but I think I'll be able to keep 
the current repository.



 Apr 26 2015