Thread overview
LWDR SAOC Milestone 1, Weekly Report for 22nd SEP to 29th SEP
Sep 30
kinke
September 30

Source Code
Plan
Proposal
SAOC Projects

Report for week 1 of milestone 1

Light Weight D Runtime.
30th September, 2021
Symmetry Autumn of Code, Week 2 of Milestone 1.

Hi all,
My apologies for posting this update late. Over the past week, I completed testing for task 3 - manual deallocation of delegates. I'm pleased to say that from my internal tests it appears to be working well. Tests have been completed on an STM32F407. Progress has been made on task 1 - support for ModuleInfo and static/module constructors and destructors.

I've had to slightly deviate from the plan due to how LDC handles module information. The original plan was based off DMD's implementation, but those hooks are unavailable on LDC (obviously, in retrospect -_- ). Instead, LDC relies on a linked list, and the initial pointer is available as _Dmodule_ref. The linked list contains pointers to ModuleInfo, which LWDR can then iterate over.

There hasn't been much formal code written, instead I've been doing tests and ensuring that it behaves as expected. There was a bug where a shared static this() {...} constructor was unable to see TLS variables, despite them being allocated. It was due to an alignment issue during allocation. This still needs to be corrected - it is a very quick fix, fortunately.

To reduce program size, I have been applying LDC_no_moduleinfo and LDC_no_typeinfo pragmas to LWDR's internal modules and types, respectively. Public facing modules and types do not have these pragmas. In debug mode, which the -O0 and -gc flags, this saved ~1KB of program memory.

To cut down on the size of ModuleInfo, I have made it so the unitTest function is only compiled in when unit tests are active. This is in accordance with my previous work to reduce the size of vtables for TypeInfo. It may interfere with custom unit testing libraries.

Going forward next week, I will need to fix the alignment issue, and work on the minfo module, which will handle ctor sorting and dispatches calls to module constructors and destructors.

All the best,
Dylan Graham

September 30

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

I've had to slightly deviate from the plan due to how LDC handles module information. The original plan was based off DMD's implementation, but those hooks are unavailable on LDC (obviously, in retrospect -_- ). Instead, LDC relies on a linked list, and the initial pointer is available as _Dmodule_ref. The linked list contains pointers to ModuleInfo, which LWDR can then iterate over.

That's just the fallback for unknown/exotic OS like Solaris. Changing the compiler to emit the ModuleInfo pointers into the __minfo section would be a simple change in https://github.com/ldc-developers/ldc/blob/f9ba17248eb53021c91130b0cb7c6c00a3f8074c/gen/modules.cpp#L107-L126, e.g., generally for ELF targets with unknown OS.

September 30

On Thursday, 30 September 2021 at 08:10:40 UTC, kinke wrote:

>

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

I've had to slightly deviate from the plan due to how LDC handles module information. The original plan was based off DMD's implementation, but those hooks are unavailable on LDC (obviously, in retrospect -_- ). Instead, LDC relies on a linked list, and the initial pointer is available as _Dmodule_ref. The linked list contains pointers to ModuleInfo, which LWDR can then iterate over.

That's just the fallback for unknown/exotic OS like Solaris. Changing the compiler to emit the ModuleInfo pointers into the __minfo section would be a simple change in https://github.com/ldc-developers/ldc/blob/f9ba17248eb53021c91130b0cb7c6c00a3f8074c/gen/modules.cpp#L107-L126, e.g., generally for ELF targets with unknown OS.

Thanks for the information, but I'd prefer not to modify the compiler just to make LWDR work (mtriple is arm-none-eabi). It's not an issue at all - the LDC version is running perfectly. I simply should have looked a bit harder.

September 30

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

Source Code
Plan
Proposal
SAOC Projects

[...]

Well done. Keep it up!

October 01

On Thursday, 30 September 2021 at 23:01:40 UTC, Imperatorn wrote:

>

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

Source Code
Plan
Proposal
SAOC Projects

[...]

Well done. Keep it up!

Thank you :)

October 02

On Friday, 1 October 2021 at 22:44:08 UTC, Dylan Graham wrote:

>

On Thursday, 30 September 2021 at 23:01:40 UTC, Imperatorn wrote:

>

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

Source Code
Plan
Proposal
SAOC Projects

[...]

Well done. Keep it up!

Thank you :)

No, thank you 😁

This is actually important for me/us that are in the embedded space.

Will experiment with this in about a month or two ☀️

October 06

On Saturday, 2 October 2021 at 07:15:19 UTC, Imperatorn wrote:

>

On Friday, 1 October 2021 at 22:44:08 UTC, Dylan Graham wrote:

>

On Thursday, 30 September 2021 at 23:01:40 UTC, Imperatorn wrote:

>

On Thursday, 30 September 2021 at 06:53:41 UTC, Dylan Graham wrote:

>

Source Code
Plan
Proposal
SAOC Projects

[...]

Well done. Keep it up!

Thank you :)

No, thank you 😁

This is actually important for me/us that are in the embedded space.

Will experiment with this in about a month or two ☀️

That is exciting! Let me know if you run into any problems and I'll try to fix them ASAP.