I'm building some code that is heavily templated. Therefore, I
have many very small classes. I was surprised to see my binaries
growing very large, disproportionately to the amount of code I
was adding. I inspected the binaries with objdump and found
contents of the .rodata section like the
On Sunday, 11 January 2015 at 15:02:07 UTC, bearophile wrote:
Mike:
I'm building some code that is heavily templated. Therefore,
I have many very small classes.
This is a non sequitur.
I believe it is because nearly every one of the instantiated
template names is appears in the .rodata se
On Saturday, 11 October 2014 at 08:15:55 UTC, Iain Buclaw via
D.gnu wrote:
So, I'm wondering if the compiler maintainers would entertain
a change to
the GDC that moved the runtime declarations (i.e. _d_newclass,
_d_{whatever}) to a .di file in druntime.
* Compilation would automatically import
On Sunday, 11 January 2015 at 16:57:41 UTC, Johannes Pfau wrote:
That's likely used/caused by the TypeInfo.name property.
Judging by what I'm seeing, I think you're right.
But I'm compiling with -fdata-sections and -Wl,--gc-sections, so
shouldn't that put each TypeInfo.name in its own secti
On Tuesday, 13 January 2015 at 14:20:43 UTC, Mike wrote:
Here's what I'm seeing:
arm-none-eabi-objdump -t binary/firmware
binary/firmware: file format elf32-littlearm
SYMBOL TABLE:
0800 ld .text .text
08000a44 ld .rodata .rodata
On Tuesday, 13 January 2015 at 14:36:15 UTC, Dicebot wrote:
I remember speaking about it with Martin and Daniel during
DConf 2014 and I think it was Daniel who mentioned that by
default TypeInfo/ModuleInfo is emitted in some weird packed
way. When LDC announced using --gc-sections by default
On Tuesday, 13 January 2015 at 10:49:43 UTC, Iain Buclaw via
D.gnu wrote:
I can assist, though timing is a problem as of late. I'll have
a list
of jobs to catch-up on my side before my attention becomes
undivided.
Iain.
Thanks, Iain. I patiently await any assistance you can provide.
On Wednesday, 14 January 2015 at 08:42:55 UTC, Iain Buclaw via
D.gnu wrote:
On 14 January 2015 at 04:00, Mike via D.gnu
wrote:
On Tuesday, 13 January 2015 at 14:36:15 UTC, Dicebot wrote:
I remember speaking about it with Martin and Daniel during
DConf 2014 and
I think it was Daniel who
On Wednesday, 14 January 2015 at 09:04:50 UTC, Mike wrote:
Ok, but I have a mess of classes generated by templates (and I
love it). Their `name` properties [1] should go in .rodata,
right? But why aren't they being put in their own sections
when compiling with -fdata-sections?
[1] -
http
On Wednesday, 14 January 2015 at 13:32:53 UTC, Mike wrote:
Well, I was working a reduced test case and found that it has
something to do with my trace.d file here:
https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/trace.d
If I add a trace.writeLine("x") in my progr
On Wednesday, 14 January 2015 at 14:20:50 UTC, Iain Buclaw via
D.gnu wrote:
Could it be that the entire module trace takes up 128K?
Probably not
very likely. And I doubt the writeLine/write templates
contribute to
much.
Sorry, I didn't see this reply before I submitted my last post.
The
On Wednesday, 14 January 2015 at 14:34:48 UTC, Mike wrote:
I'll try to make a reduced test case on Linux that others can
run
and see.
Ok, here's my reduced test case that runs on Linux 64-bit. I
don't know if I really needed to implement the syscalls, but I
just wanted to get rid of everyt
On Thursday, 15 January 2015 at 11:42:31 UTC, Dicebot wrote:
Random guess: can it possibly confuse template-based variadics
with runtime variadics? Latter require RTTI to work. If
something like that happens it is surely a bug.
Thanks for the reply. I have to apologize for the last post,
On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
After some google-fu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Considering this was filed in 2000 I'd say it's not very likely
to get
fixed soon :-(
That looks right-on, and knowing the likely cause, I should able
On Sunday, 11 January 2015 at 16:57:41 UTC, Johannes Pfau wrote:
If you only want to disable TypeInfo for some classes that's
more
difficult:
https://github.com/D-Programming-microD/GDC/commit/f0614bc9480dacd1ec6bb75277d280afa96e08bb
Is this good enough for a pull request upstream, or just a
On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
My best guess is that the strings are always placed in rodata,
never in
separate sections. If you do write("x"), "x" is also in rodata,
the
rodata section can't be removed. If you delete the write call
there's
no reference to
I'm trying to track down an optimization bug.
I have written a D program and a C program that are essentially
identical, and compiled them to assembly code with my
arm-none-eabi-gdc/gcc build.
C Code: https://bpaste.net/show/6f420de3a892
C ASM : https://bpaste.net/show/42c75f6763bf
arm-none-e
On Monday, 26 January 2015 at 17:50:59 UTC, Liran Zvibel wrote:
With the following gcd flags:
-fno-invariants -fno-in -fno-out -fno-bounds-check -O3
-fno-assert -c -nophoboslib -nostdlib
I still have 3 undefined symbols:
_D10TypeInfo_i6__initZ _D15TypeInfo_Struct6__vtblZ _Dmodule_ref
If y
On Tuesday, 28 April 2015 at 05:00:50 UTC, Timo Sintonen wrote:
../$gccver/configure --target=arm-eabi --disable-bootstrap \
--enable-languages=c --enable-multilib --disable-nls \
--without-isl --without-cloog \
--without-gmp --without-mpfr --without-mpc \
--disable-libphobos
I th
Iain recently asked me to let him know what might be needed for a
-ffreestanding implementation in GDC. I couldn't really give a
good answer, so I tried to spend some more time thinking "What
does freestanding mean in D?"
It is my understanding that the -ffreestanding switch in C
prevents the co
On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
After some google-fu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
Considering this was filed in 2000 I'd say it's not very likely
to get
fixed soon :-(
So the best option is probably to get rid of this problem by
patchin
On Sunday, 10 May 2015 at 09:54:51 UTC, Mike wrote:
Looks like someone picked up on this and submitted a patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9 Cool!!
But I still have yet to test it.
Damn! Didn't work.
On Sunday, 10 May 2015 at 13:20:42 UTC, Iain Buclaw wrote:
Not sure what you're using to build, but it seems reliant on
-ffunction-sections -fdata-sections -fmerge-constants - or at
least
the latter two of those options.
Did you try the minimum test in the PR?
I'm using the cross-compiler b
On Sunday, 10 May 2015 at 12:48:55 UTC, Mike wrote:
On Sunday, 10 May 2015 at 09:54:51 UTC, Mike wrote:
Looks like someone picked up on this and submitted a patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c9 Cool!!
But I still have yet to test it.
Damn! Didn't work.
Bug report
On Sunday, 10 May 2015 at 17:45:30 UTC, Johannes Pfau wrote:
I've just opened a pull request for -fno-rtti at [1]. The
frontend part
needs to go into DMD but I'd like some testing feedback first.
This is
especially important as I had literally no time to test this
updated code ;-) Please provid
On Thursday, 14 May 2015 at 15:21:46 UTC, Johannes Pfau wrote:
^
The compiler was still building the xopEquals and xopCMP
functions.
These use TypeInfo internally but they're also only accessible
through
TypeInfo. Solution: We should not generate these functions with
-fno-rtti. Bo
Consider this code
testInline.d
module testInline;
import gcc.attribute;
public enum inline = gcc.attribute.attribute("forceinline");
@inline int add(int a, int b)
{
return a + b;
}
test.d
**
import std.stdio;
import testInline;
void main()
{
writeln(add(1, 2));
}
On Saturday, 30 May 2015 at 16:55:14 UTC, denizzzka wrote:
Hi!
I am tried to use step-by-step instructions from wiki
(http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler)
to build toolchain on Debian GNU/Linux 8 and got this error
after execute "make -j4 all-target-libgcc":
[sni
On Wednesday, 3 June 2015 at 12:54:32 UTC, Johannes Pfau wrote:
That's correct. All ARM GCC compilers can generate code for all
ARM variants (the hf compiler can generate softfloat code and
the softfloat compiler can generate hf code as well). The
difference between the compilers are the ship
On Thursday, 4 June 2015 at 18:35:45 UTC, Johannes Pfau wrote:
If you mean adding support to the same binary toolchain
package: I don't think that will work. Multilib requires
similar systems, it's probably not possible to mix
linux+libphobos and baremetal builds.
Indeed. I completely gloss
On Saturday, 6 February 2016 at 21:58:17 UTC, Dan Olson wrote:
Hi Iain, Johannes. I'm asking here because I don't expect
anybody else is playing with thumb instructions.
Both GDC and LDC have version ARM_Thumb defined for original
thumb (call it thumb-1) and thumb-2. But there is no way to
On Wednesday, 10 February 2016 at 17:03:35 UTC, Dan Olson wrote:
I noticed that even thumb-1 has different instruction set based
on arm architecture.
Yes. I did a little more research into this, as it peeked my
curiosity. Take a look at this Wikipedia entry
(https://en.wikipedia.org/wiki/
On Saturday, 27 August 2016 at 08:05:08 UTC, Timo Sintonen wrote:
My question is: is this the way we should go?
If it is, what would be the preferred name for this type? Also
what would you think should be the module and file name?
There was some discussion about the module and file names whe
This is just an experience report for those who might be
interested.
Given this pull request
(https://github.com/D-Programming-GDC/GDC/pull/456) I thought I'd
try testing a more recent GDC with my STM32 demo
(https://github.com/JinShil/stm32f42_discovery_demo) and see what
the state of thing
On Sunday, 25 June 2017 at 10:44:26 UTC, Iain Buclaw wrote:
Out of curiosity, is that the original built binary, or post
trimming
(strip / --gc-sections)?
I'm compiling with -ffunction-sections and -fdata-sections, and
linking with --gc-sections.
There might be a size optimization possibili
On Sunday, 25 June 2017 at 10:53:35 UTC, Mike wrote:
I'm not really interested in that because its too blunt of an
instrument. I'd like to use TypeInfo, but only if I'm doing
dynamic casts or other things that require such runtime
information. Also, I'd only want the TypeInfo for the types
On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
Compile Speed
=
It takes about 1 minute 30 seconds to build and link the STM32
demo resulting in a 6kB binary. That's pretty bad, but I
suspect that's a DMD CTFE problem.
I'm been informed that this PR
(https://github.com/dla
On Sunday, 25 June 2017 at 13:40:56 UTC, Iain Buclaw wrote:
I'll make a formal PR when I have some time later.
Iain.
For those who may encounter this post at a later date, the PR is
here: https://github.com/D-Programming-GDC/GDC/pull/505 and it
seems to solve the problem. Yeah!
On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:
Looks like it would be best to apply these PRs in the order
listed:
https://github.com/dlang/dmd/pull/5276
https://github.com/dlang/dmd/pull/5948
https://github.com/dlang/dmd/pull/6418
Thanks. I actually wasn't aware, until yest
On Tuesday, 27 June 2017 at 17:55:02 UTC, Iain Buclaw wrote:
Looks like it would be best to apply these PRs in the order
listed:
https://github.com/dlang/dmd/pull/5276
https://github.com/dlang/dmd/pull/5948
https://github.com/dlang/dmd/pull/6418
Compiling https://github.com/JinShil/stm32
On Wednesday, 28 June 2017 at 12:15:17 UTC, Johannes Pfau wrote:
Have you already tried -fsyntax-only to remove the backend
computation?
time arm-none-eabi-gdc -c -O3 -fsyntax-only -nophoboslib
-nostdinc -nodefaultlibs -nostdlib -fno-emit-moduleinfo -mthumb
-mcpu=cortex-m4 -Isource/runtime -
On Wednesday, 28 June 2017 at 11:19:10 UTC, Mike wrote:
I'd be glad to do some troubleshooting if you have any ideas.
I just checked in a branch that will compile with a desktop GDC
compiler in case someone wants to give it a try. I tested with
6.2.1 20160830 from the Arch Linux repository.
On Wednesday, 28 June 2017 at 13:48:54 UTC, Johannes Pfau wrote:
I guess if archlinux GDC is slow as well this is unlikely the
main cause, but did you build your compiler in release mode
(--enable-checking=release)?
Thanks, I wasn't aware of that. I just rebuilt and it brought
the time down
On Wednesday, 28 June 2017 at 16:52:26 UTC, Iain Buclaw wrote:
You probably want to tone down on optimizations as well. -O3
will be doing a lot of work, sometimes for little or no gain.
In most cases, -O2 -finline-functions is good enough, which can
be abbreviated further as simply -Os. [fo
On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
Phase opt and generate is the topl-evel timer for the entire
"backend" compilation phase. I was expecting to see more of a
breakdown of individual passes.
Sorry, it didn't look broken down to me. Here's the full report.
arm-non
On Wednesday, 28 June 2017 at 22:17:09 UTC, Iain Buclaw wrote:
A thought just occurred to me, you are compiling the entire
program + object.d right? Nothing else will link/be linked to
the binary?
If that is the case, you should definitely compile with
-fwhole-program. I suspect that may c
On Monday, 17 July 2017 at 23:57:02 UTC, Iain Buclaw wrote:
Infact, after inspecting the unoptimized result, I think I can
safely say this is the entire program, as it is intended to be
built.
If I compile without optimizations, I am able to get a complete
binary also, even without the cha
I'm currently try to replace my old volatileLoad/Store functions
that utilized a `shared` bug as an alternative to `volatile`.
The used to look like this:
@inline T volatileLoad(T)(T* a)
{
asm { "" ::: "memory"; };
return *cast(shared T*)a;
}
@inline void volatileStore(T)(T* a, in T v)
On Tuesday, 18 July 2017 at 20:54:26 UTC, Iain Buclaw wrote:
Just after module core.bitop; line, add:
nothrow:
@safe:
@nogc:
Thanks, and sorry for the foolish mistake. I'm getting a working
binary now. Well, at least my status LED is blinking and I see my
LCD screen trying to do something,
My stm32 demo has now been updated and working with GDC/GCC
7.1.0. Thanks for all your improvements.
However, I'm getting broken binaries with -O2 and -O3. I've
nailed the culprit down to -fschedule-insns (i.e. if I add
-fno-schedule-insns to -O2 or -O3, the binary works fine).
I disassemb
On Friday, 21 July 2017 at 23:44:53 UTC, Mike wrote:
I'm getting broken binaries with -O2 and -O3. I've nailed the
culprit down to -fschedule-insns (i.e. if I add
-fno-schedule-insns to -O2 or -O3, the binary works fine).
I disassembled '-O2' and '-O2 -fno-schedule-insns' and compared
them,
On Friday, 21 July 2017 at 23:44:53 UTC, Mike wrote:
However, I'm getting broken binaries with -O2 and -O3. I've
nailed the culprit down to -fschedule-insns (i.e. if I add
-fno-schedule-insns to -O2 or -O3, the binary works fine).
I've confirmed that -fschedule-insns is reordering register
On Saturday, 22 July 2017 at 09:07:31 UTC, Iain Buclaw wrote:
https://github.com/JinShil/stm32f42_discovery_demo/search?utf8=%E2%9C%93&q=cast%28shared&type=
Those should probably be volatileLoad, as they look to be used
by setValue().
I am such an idiot. Problem solved. Thank you, and I'm t
Hello,
It is common practice in ARM Cortex-M bare metal C/C++ programs
to define symbols in the linker so one can initialize the .data
and .bss segments and know the boundaries of one's stack and
heap. It looks something like this.
linkerscript
__text_end__ = .;
.data : AT(__text
On Saturday, 19 April 2014 at 01:50:45 UTC, Iain Buclaw via D.gnu
wrote:
I think you mean to 'extern (C) extern'
Yes, that's what I was looking for. Thanks.
On Wednesday, 11 June 2014 at 21:54:28 UTC, Iain Buclaw wrote:
It's done, after 2 months brewing in development.
https://github.com/D-Programming-GDC/GDC/pull/76
This is great news. Thank you to all those involved.
On Sunday, 13 July 2014 at 11:17:29 UTC, Joseph Rushton Wakeling
via D.gnu wrote:
The simplest way to build such cross-compilers is with
crosstool-NG:
http://wiki.dlang.org/GDC/Cross_Compiler/crosstool-NG
I also build the binaries at http://gdcproject.org/downloads/
with
crosstool-NG.
Thanks
On Sunday, 13 July 2014 at 10:10:34 UTC, Joseph Rushton Wakeling
via D.gnu wrote:
I decided it was time to start pulling out Adam Ruppe's
embedded programming guide, and as a decidedly non-embedded
programmer, the instructions here:
http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compil
I received a question from Dicebot in at the end of my
presentation. He asked about the --gc-sections linker flag
breaking code from GDC.
I recently discovered how one can see why this is occurring, and
I hope this will help identify the problem and lead to a solution.
Compile any simple he
On Wednesday, 16 July 2014 at 13:52:57 UTC, Mike wrote:
I received a question from Dicebot in at the end of my
presentation. He asked about the --gc-sections linker flag
breaking code from GDC.
I recently discovered how one can see why this is occurring,
and I hope this will help identify th
On Saturday, 16 August 2014 at 09:29:14 UTC, Johannes Pfau wrote:
I just had a look at this and ClassInfo has a mutable 'monitor'
field,
so it can't be placed into read-only data.
This was discussed at DConf 2014.
https://www.youtube.com/watch?v=TNvUIWFy02I#t=1008
There is currently a pu
On Saturday, 16 August 2014 at 09:59:03 UTC, Artur Skawina via
D.gnu wrote:
Taking the address of an always_inline function is allowed.
It may be allowed, but it probably shouldn't be. Always-inlining
a function and taking the address of that function is
contradictory.
But this situation
On Saturday, 16 August 2014 at 11:16:09 UTC, Artur Skawina via
D.gnu wrote:
A `@nocode` attribute would be a good idea, yes, but there's no
need
to make it implicit for `@inline`.
But this situation demonstrates why having an intelligent
linker is a better solution than decorating with attrib
On Sunday, 17 August 2014 at 08:26:40 UTC, Johannes Pfau wrote:
Great! But I think this pull request addresses a different
monitor
problem: There's an implicit __monitor field in every class
right now,
which makes every class _instance_ bigger.
But the monitor in TypeInfo/ClassInfo is differ
Hello,
In my continued, though stalled, effort to try and make minimal
runtime for embedded systems, I've tried to find a way for users
to know at compile-time if a feature of the runtime is supported
or not, and more importantly, if they are explicitly or
implicitly using an unsupported feat
On Saturday, 11 October 2014 at 17:37:22 UTC, Kevin Lamonte wrote:
On Saturday, 11 October 2014 at 06:59:33 UTC, Mike wrote:
Hello,
In my continued, though stalled, effort to try and make
minimal runtime for embedded systems, I've tried to find a way
for users to know at compile-time if a fea
I'm wondering, if some of you that do development on GDC could
briefly describe how you set up your development environment.
I can build GDC fine, but I can't do the 30-minute build for
every little change. The build script is just a black box to me
right now. How do you guys do incremental
On Sunday, 12 October 2014 at 09:11:16 UTC, Iain Buclaw via D.gnu
wrote:
Incremental Builds:
When you make a change to either the gdc or gcc sources,
running make
inside objdir will keep on doing incremental builds for you.
Some
exceptions to the rule:
* Adding/Removing files from libpho
On Sunday, 12 October 2014 at 09:11:16 UTC, Iain Buclaw via D.gnu
wrote:
On 12 October 2014 01:29, Mike via D.gnu
wrote:
I'm wondering, if some of you that do development on GDC could
briefly
describe how you set up your development environment.
I can build GDC fine, but I can't
This has been brought up before:
[1]
http://forum.dlang.org/post/cqzazaqxpwezignix...@forum.dlang.org
[2]
http://forum.dlang.org/post/zapxhodqmotriapue...@forum.dlang.org
But I'd like to know what GDC's long term plans are to enable
removing dead code from executables.
(1) Adding a D-specif
70 matches
Mail list logo
