April 10, 2015
On Wednesday, 8 April 2015 at 15:25:20 UTC, Jens Bauer wrote:

>>> Question number 2: Is it possible to change the VectorFunc to be a real function pointer, rather than a void* ?
>
>> immutable ISR[3] g_pfnVectors =
>> [
>>      cast(ISR)&_stack
>>    , &Reset_Handler
>>    , &NMI_Handler
>>    , &HardFault_Handler
>> ];
>
> In your example, you do not have the initial stack pointer.
> The above code gives me the following:
> src/test.d:24:13: error: reinterpreting cast from uint* to void()* is not supported in CTFE
>     cast(ISR)&_stack
>              ^
>
> -That's the only reason I needed to change it to from function() to void*.
> Can you successfully cast(ISR)&_stack ?

I don't know if that's a constraint of the language or a limitation of the current CTFE implementation, but either way, I never really liked it.  I know the C folks do this stuff all the time, but I think it's kinda janky.

I know of two potential alternatives:
1)  Do it in the linker script (my current method):

MEMORY
{
  CCRAM (rxw) : ORIGIN = 0x10000000, LENGTH = 64k
}

/* Falling stack starts at the end of the CCM */
_stackStart = ORIGIN(CCRAM) + LENGTH(CCRAM);

SECTIONS
{
    .text :
    {
        LONG(_stackStart);
        KEEP(YourISRVectorTable);
    }
}

2) Use a union (See pp. 10 here: http://www.state-machine.com/arm/QDK_ARM-Cortex_STM32-GNU.pdf)

C Code to be adapted to D:

typedef void (*ExceptionHandler)(void);
typedef union {
	ExceptionHandler handler;
	void            *pointer;
} VectorTableEntry;

__attribute__ ((section(".isr_vector")))
VectorTableEntry const g_pfnVectors[] = {
	{ .pointer = &__c_stack_top__           },
	{ .handler = &Reset_Handler             },
	{ .handler = &NMI_Handler               },
	... ect ...
};

Mike
April 11, 2015
On Wednesday, 8 April 2015 at 23:18:41 UTC, Mike wrote:
> You may also wnat to compile with -nodefaultlibs -nostdlib -nostartfiles.  That removes the cruntime and libgcc.

I forgot about those. Yes, when excluded those and added a /DISCARD/ for the exidx and armexidx, I finally got rid of the huge overhead.
Thank you so much!

I guess that the CTFE optimizes any function calls if they reside in the startup.d file, because if I keep it in the startup.d, then the size stays small, but as soon as I move a called function out from the startup.d into its own file, then the overhead shows up.

-But it's no longer a problem. ;)
April 11, 2015
On Thursday, 9 April 2015 at 10:47:42 UTC, Artur Skawina wrote:
>>> On Tuesday, 7 April 2015 at 20:33:26 UTC, Jens Bauer wrote:
>> 
>> -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

Thank you, Artur.

This is what I did (it's very close to the above; just slightly modified):

enum weak = gcc.attribute.attribute("weak");
alias Tuple(A...) = A;
alias rst = Tuple!(weak, gcc.attribute.attribute("alias", "defaultResetHandler"));
alias exc = Tuple!(weak, gcc.attribute.attribute("alias", "defaultExceptionHandler"));

So now the code is much easier to read ...

@rst extern(C) void Reset_Handler();
@exc extern(C) void NMI_Handler();
@exc extern(C) void HardFault_Handler();
...
...
@exc extern(C) void LTDC_ER_IRQHandler();
@exc extern(C) void DMA2D_IRQHandler();

April 11, 2015
On Friday, 10 April 2015 at 00:05:29 UTC, Mike wrote:
> On Wednesday, 8 April 2015 at 15:25:20 UTC, Jens Bauer wrote:
>
>>>> Question number 2: Is it possible to change the VectorFunc to be a real function pointer, rather than a void* ?
>>
>> Can you successfully cast(ISR)&_stack ?
>
> I don't know if that's a constraint of the language or a limitation of the current CTFE implementation, but either way, I never really liked it.
I don't really like typecasting myself, but I know a function pointer and a stack pointer are both pointers, thus they're the same size.

> I know the C folks do this stuff all the time, but I think it's kinda janky.

True, but I need to write my files flexible, so that the majority of people will be able to use it out-of-the-box. I have to keep in mind that there are people who will make a part of their code in C during the transition phase, and I have to keep in mind that those who wrote the library in C, probably won't provide a complete library in D within the first week. ;)

I agree with you on the 'minimal' style. I too hate all the junk that's added. 'printf' has always been prohibited in my microcontroller code - I don't have a file system on my microcontroller; no screen, no keyboard and no harddisk, thus I don't want anything that has any connection to printf or a file system. ;)

Basically my startup.d will be very similar to the startup.s you already know (I translated my startup.s into a startup.c a long time ago - because I didn't want one for each type of assembler).

> I know of two potential alternatives:
> 1)  Do it in the linker script (my current method):

Two things makes me little fond of this solution:
1: The "LONG" type. If it had been "PTR" or "UINT32", then it would be more attractive, but I do not expect those types exist.
2: I like people to be able to define the stack location inside the sources if they want to.
That means: Typically the linker script will provide it, but some people need to move the stack, and I don't want them to need to change the linker script (if at all possible).

> 2) Use a union (See pp. 10 here:
This solution is probably more appealing to me.
I'll need to make some more tests.

My initial attempt was to create a function, which did the type conversion via a CTFE function, buuut it didn't like that the symbol was undefined and not a constant, so I'll have to make a few more attempts.

Thank you again for your valuable help. I hope that my fiddling will bring you something useful too. ;)
1 2 3
Next ›   Last »