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