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
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
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
Am Sun, 03 May 2015 15:18:40 +
schrieb Martin Nowak c...@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
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
Am Sat, 02 May 2015 06:40:06 +
schrieb Mike n...@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
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
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?
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,
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
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
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
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
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
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
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.
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
Am Sat, 02 May 2015 09:45:56 +
schrieb Mike n...@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
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
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
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
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
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
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
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
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
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
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,
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
Am Fri, 01 May 2015 06:57:07 +
schrieb Timo Sintonen t.sinto...@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
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
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
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.
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'...
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
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
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
-
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.
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,
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
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
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/psssnzurlzeqeneag...@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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 27 April 2015 at 09:47, Iain Buclaw ibuc...@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
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
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
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
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 +=
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
On 27 April 2015 at 08:28, Iain Buclaw ibuc...@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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Am Mon, 27 Apr 2015 07:55:09 +
schrieb Martin Nowak c...@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
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
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 +
schrieb Martin Nowak c...@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
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
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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
96 matches
Mail list logo
