On Wednesday, 8 April 2015 at 11:17:12 UTC, Mike wrote:
> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote:
>
> enum weak = gcc.attribute.attribute("weak");
> enum isrDefault = gcc.attribute.attribute("alias", "defaultHandler");
>
> extern @weak @isrDefault void NMI_Handler();
> extern @weak @isrDefault void HardFault_Handler();

This is indeed helpful. I've now reduced each of the approximately 100 lines declaring exception vectors to something like these:

@weak @ar void Reset_Handler();
@weak @ae void NMI_Handler();

-It would be neat, if @attribute("weak") and @attribute("alias","function") could be combined into one, but I haven't found a way to do that - I've done that in C earlier, though:
void __attribute__((weak, alias(defaultExceptionHandler))) NMI_Handler(void);

> I use this idiom briefly in my code here: https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/start.d

Yes. I actually came across it and didn't notice it. But now that you've explained it, it absolutely makes sense. :)

-I actually added @attribute("naked") to my defaultResetHandler yesterday, as I wanted to get rid of the prologue; so I completely agree; the startup code should have this attribute.
I've now changed that to use the enum, to be more consistent. ;)

On Wednesday, 8 April 2015 at 15:53:37 UTC, Jens Bauer wrote:
> [snip] I find it strange that calling an empty function outside
> the source file will cause that huge difference.
> -But of course, there's a logic explanation somewhere. ;)
>
> It might be caused by the linker script; I'll try and see if I can modify it to get rid of those things.

Nope, that wasn't it. However, I found out that when I call an external function, some unwinding code is forced upon me; it's used by libgcc. I can't seem to get rid of it. I've removed the -lgcc from my linker flags (along with *all* other libraries, and it's still forced upon me.

I tried to remove as much of the druntime, as I could, but it did not help a tad.

On Wednesday, 8 April 2015 at 15:44:00 UTC, Jens Bauer wrote:
> On Wednesday, 8 April 2015 at 11:17:12 UTC, Mike wrote:
>> I did something along these lines (modified to match your example) and it worked fine for me:
>>
>> alias VectorFunc = void function();
>>
>> @attribute("weak") @attribute("alias", "defaultHandler")
>> extern void Reset_Handler();
>
> Strange; I can't get it to build without extern(C).
> Also, if I remove extern(C) from for instance HardFault_Handler, then a HardFault_Handler written in C is not found by the linker.

If HardFault_Handler is written in C then you will definitely need to decorate with extern(C).

If your handlers are written in D, and neither the implementation nor the declaration are decorated with extern(C) then it should work.

Mike

On Wednesday, 8 April 2015 at 17:45:01 UTC, Jens Bauer wrote:
> On Wednesday, 8 April 2015 at 15:53:37 UTC, Jens Bauer wrote:
>> [snip] I find it strange that calling an empty function outside
>> the source file will cause that huge difference.
>> -But of course, there's a logic explanation somewhere. ;)
>>
>> It might be caused by the linker script; I'll try and see if I can modify it to get rid of those things.
>
> Nope, that wasn't it. However, I found out that when I call an external function, some unwinding code is forced upon me; it's used by libgcc. I can't seem to get rid of it. I've removed the -lgcc from my linker flags (along with *all* other libraries, and it's still forced upon me.
>
> I tried to remove as much of the druntime, as I could, but it did not help a tad.

I can think of two places in the runtime where extra code can be added to your binary: runtime initialization and thread-local storage.  There may be others depending on what features are implemented in the runtime.

You can find the runtime initialization code for GDC's runtime here:  https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/rt/dmain2.d#L152

That eventually will call some things that malloc, and more. That all happens before you get to main.  Are you compiling with -fno-emit-moduleinfo?  That may help reduce some of that runtime initialization.

As I recall, thread-local storage also employs malloc as memory is needed for each thread-local variable when a new thread is created.  If your project is single-threaded, it still works the same way when the initial thread is created.  If you have any thread-local state try removing them or changing them to __gshared, and see if that helps.

My runtime is quite minimal, which has both benefits and consequences.  You can find it here: https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/runtime

This will give you a C-like programming experience.  You can use classes, but won't be able to allocate them on the GC heap.  Instead, you can employ some of the patterns here:  http://wiki.dlang.org/Memory_Management

You may also wnat to compile with -nodefaultlibs -nostdlib -nostartfiles.  That removes the cruntime and libgcc.  But if you do that, you may have to compensate by adding additional startup code In D.  You can see how I've done that here:  https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/start.d#L102

As I understand it, minlibd is a more full-featured runtime, and that too has its benefits and consequences.

Mike

On Wednesday, 8 April 2015 at 16:10:53 UTC, Jens Bauer wrote:
> On Wednesday, 8 April 2015 at 11:17:12 UTC, Mike wrote:
>> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote:

>
> -I actually added @attribute("naked") to my defaultResetHandler yesterday, as I wanted to get rid of the prologue; so I completely agree; the startup code should have this attribute.
> I've now changed that to use the enum, to be more consistent. ;)

I actually added that out of necessity, not optimization.  Id I use the STM32, and reset the MCU, the CCRAM is disabled by default.  Since my stack is in CCRAM, I need to first enable it before any functions can be called.

Mike

On Wednesday, 8 April 2015 at 23:23:53 UTC, Mike wrote:
> On Wednesday, 8 April 2015 at 16:10:53 UTC, Jens Bauer wrote:
>> On Wednesday, 8 April 2015 at 11:17:12 UTC, Mike wrote:
>>> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote:
>
>>
>> -I actually added @attribute("naked") to my defaultResetHandler yesterday, as I wanted to get rid of the prologue; so I completely agree; the startup code should have this attribute.
>> I've now changed that to use the enum, to be more consistent. ;)
>
> I actually added that out of necessity, not optimization.  Id I use the STM32, and reset the MCU, the CCRAM is disabled by default.  Since my stack is in CCRAM, I need to first enable it before any functions can be called.
>

Sorry, I need to be more careful when typing on a tablet.  That should read:

I actually added that out of necessity, not optimization.  If I use the STM32 system bootloader, and reset the MCU, the CCRAM is disabled by default.  Since my stack is in CCRAM, I need to first enable it before any functions can be called.

Mike

On Wednesday, 8 April 2015 at 23:23:53 UTC, Mike wrote:
> I actually added that out of necessity, not optimization.  Id I use the STM32, and reset the MCU, the CCRAM is disabled by default.  Since my stack is in CCRAM, I need to first enable it before any functions can be called.

According to ST-Microelectronics, CCMRAM is enabled by default (by hardware).

I am using CCMRAM without enabling it, so it must be correct what their User's Manual states.

On Wednesday, 8 April 2015 at 23:28:45 UTC, Mike wrote:
> If I use the STM32 system bootloader, and reset the MCU,
> the CCRAM is disabled by default.

I see. That is absolutely incorrect behaviour of the bootloader.
A bootloader should only change the things that are absolutely necessary to change.

I'll have a look at the other details in your replies tomorrow, as I'm getting very sleepy; so writing code is not a good idea in my present state. ;)

On Thursday, 9 April 2015 at 00:37:32 UTC, Jens Bauer wrote:
> On Wednesday, 8 April 2015 at 23:23:53 UTC, Mike wrote:
>> I actually added that out of necessity, not optimization.  Id I use the STM32, and reset the MCU, the CCRAM is disabled by default.  Since my stack is in CCRAM, I need to first enable it before any functions can be called.
>
> According to ST-Microelectronics, CCMRAM is enabled by default (by hardware).
>
> I am using CCMRAM without enabling it, so it must be correct what their User's Manual states.

Indeed, that's true.  This problem I'm referring to only occurs when when resetting from the system boot loader.  Since I want my stack to work under both conditions, I need to add that code.

See the discussion here for more information:
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fLeave%20DFU%20while%20boot0%20is%20high%20%28STM32F4%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1158

Mike

On 04/08/15 18:10, Jens Bauer via Digitalmars-d-learn wrote:
> On Wednesday, 8 April 2015 at 11:17:12 UTC, Mike wrote:
>> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote:
>>
>> enum weak = gcc.attribute.attribute("weak");
>> enum isrDefault = gcc.attribute.attribute("alias", "defaultHandler");
>>
>> extern @weak @isrDefault void NMI_Handler();
>> extern @weak @isrDefault void HardFault_Handler();
> 
> This is indeed helpful. I've now reduced each of the approximately 100 lines declaring exception vectors to something like these:
> 
> @weak @ar void Reset_Handler();
> @weak @ae void NMI_Handler();
> 
> -It would be neat, if @attribute("weak") and @attribute("alias","function") could be combined into one, but I haven't found a way to do that

http://forum.dlang.org/post/mailman.2672.1403379235.2907.digitalmars-d@puremagic.com

artur