Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 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)
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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 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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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?
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 ?
Re: ARM Cortex-M Microcontroller startup files
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 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.
Re: ARM Cortex-M Microcontroller startup files
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?
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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. :)
Re: ARM Cortex-M Microcontroller startup files
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).
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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/malloc.c?at=default). That looks small and tight, but should be written in D :-) Mike
Re: ARM Cortex-M Microcontroller startup files
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);
Re: ARM Cortex-M Microcontroller startup files
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, 0x 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 ?
Re: ARM Cortex-M Microcontroller startup files
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?
Re: ARM Cortex-M Microcontroller startup files
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/quemhwpgijwmqtpxu...@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.
Re: ARM Cortex-M Microcontroller startup files
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 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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 ? :)
Re: ARM Cortex-M Microcontroller startup files
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'...
Re: ARM Cortex-M Microcontroller startup files
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 0x
... 0x7fff 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. ;)
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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/quemhwpgijwmqtpxu...@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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 ?
Re: ARM Cortex-M Microcontroller startup files
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/quemhwpgijwmqtpxu...@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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 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
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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 ?
Re: ARM Cortex-M Microcontroller startup files
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/quemhwpgijwmqtpxu...@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
Re: ARM Cortex-M Microcontroller startup files
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. ;)
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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).
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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).
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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 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
Re: ARM Cortex-M Microcontroller startup files
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!
Re: ARM Cortex-M Microcontroller startup files
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)
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 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
Re: ARM Cortex-M Microcontroller startup files
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)
+ # Note that arm/t-mprofile is a
+ # stand-alone make file fragment to be
+ # used only with itself. We do not
+ # specifically use the
+ # TM_MULTILIB_OPTION framework because
+ # this shorthand is more
+ # pragmatic. Additionally it is only
+ # designed to work without any
+ # with-cpu, with-arch with-mode
+ # with-fpu or with-float options.
+ 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 12
+ exit 1
+ fi
+ tmake_file=${tmake_file}
arm/t-mprofile
+ break
+ ;;
default)
;;
*)
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_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
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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_REQUIRED += mcpu=cortex-m4 #/mfloat-abi=hard #/mfpu=fpv4-sp-d16 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
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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_REQUIRED += mcpu=cortex-m4 #/mfloat-abi=hard
#/mfpu=fpv4-sp-d16
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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)
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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 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...
Re: ARM Cortex-M Microcontroller startup files
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
# The D frontend is written in C++, so we need to build the C++
# compiler during stage 1.
Re: ARM Cortex-M Microcontroller startup files
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 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
Re: ARM Cortex-M Microcontroller startup files
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
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_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
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_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'
\
ARM Cortex-M Microcontroller startup files
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)
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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. :)
Re: ARM Cortex-M Microcontroller startup files
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/uwkshliqwbmmxdfiu...@forum.dlang.org). I'm not knowledgable enough about it, so I wasn't able to offer any help. Mike
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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_REQUIRED += mcpu=cortex-m4 #/mfloat-abi=hard #/mfpu=fpv4-sp-d16 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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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.
Re: ARM Cortex-M Microcontroller startup files
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
