• Dylan Graham (43/43) Oct 06 2021 [Source Code](https://github.com/hmmdyl/LWDR)

Dylan Graham <dylan.graham2000 gmail.com> writes:

[Source Code](https://github.com/hmmdyl/LWDR)
[Plan](https://github.com/hmmdyl/SAoC2021/blob/main/plan.md)
[Proposal](https://github.com/hmmdyl/SAoC2021/blob/main/proposal.md)
[SAOC 
Projects](https://dlang.org/blog/2021/08/30/saoc-2021-projects/)

[Report for week 1 of milestone 
1](https://forum.dlang.org/thread/vodbtqqwvdmapnjzlzaq forum.dlang.org)
[Report for week 2 of milestone 
1](https://forum.dlang.org/thread/sqounqxhveqhbcxcmxbw forum.dlang.org)

Light Weight D Runtime.
6th October, 2021.
Symmetry Autumn of Code, Week 3 of Milestone 1.

Hi all,
The past week has been productive. I have finished task 1 of 
milestone 1 - implementation of `static` and `shared static` 
constructors and destructors, crushed a nasty bug in the thread 
local storage (TLS) implementation and begun to modularise parts 
of LWDR.

To start, I did some testing with [`ModuleInfo` 
list](https://github.com/hmmdyl/LWDR/commit/31278fab8bba5120e0cd0e
871d11b9675409bc9). Mostly just poking around to see how it worked, and did
what I expected it would. I have found that I need to cast the function
pointers in the `ModuleInfo` structure to `nothrow` and ` nogc`, otherwise they
refuse to call. Sadly, my pervasive usage of `nothrow` has not saved me - I've
had to implement a stub `_d_eh_personality` in C regardless. I will begin to
remove the `nothrow` tags as it can affect code generation.

I studied the code [in DRuntime's 
`rt.minfo`](https://github.com/dlang/druntime/blob/stable/src/rt/minfo.d) more
carefully. I found a reliance on something called `HashTab`. I have implemented
a data structure called the
[`LLUnionSet`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/lwdr/i
ternal/unionset.d), which sort of does the same thing. It's a collection of
key-value pairs and is designed specifically for usage in [LWDR's
`rt.moduleinfo`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/moduleinfo.d).

I have replicated [DRuntime's 
`core.internal.array.casting.__ArrayCast`](https://github.com/dlang/druntime/blob/stable/src/core/internal/
rray/casting.d#L75) in
[LWDR](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/s
urce/rt/arrcast.d), as some code in LWDR needed it.

All hardware implementations for getting the module information 
now have to provide a [function called 
`allModules`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/
ections/ldc.d#L18), which returns a range over all modules present. For now,
only the implementation for 'exotic' platforms compiled with LDC are supported.
The [TLS](https://github.com/hmmdyl/LWDR/tree/f641dde3f36a2b01216cad2c27917330438
f35b/source/rt/tls) and [section/module
information](https://github.com/hmmdyl/LWDR/tree/f641dde3f36a2b01216cad2c279173304386f35b
source/rt/sections) implementations have been split up upon hardware and/or
compiler lines. This is to prepare LWDR to support more platforms in the
future. All modules in each package should implement the same public interface,
which will be called by the `LWDR` helper class and other parts of LWDR.

The module sorting and cycle checking algorithm in [DRuntime's 
minfo](https://github.com/dlang/druntime/blob/stable/src/rt/minfo.d#L165) was
[reimplemented](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/r
/moduleinfo.d#L37). The algorithm is responsible for ensuring that static
constructors and destructors are called in the correct order and detecting
cycles. If a cycle is detected, LWDR currently only raises an assertion saying
that a cycle was detected. The
[`LWDR`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/sourc

these constructors and destructors. It should work out of the box (with the
version `LWDR_ModuleCtors`). For those pedantic about memory consumption
(version `LWDR_ModuleCtors_MinHeap`), it can also free and re-sort/allocate on
each call to `LWDR.startRuntime/stopRuntime/registerCurrentThread/deregisterCurrentThread`.

[`core.bitop` was copied into 
LWDR](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/s
urce/core/bitop.d), since `rt.moduleinfo` relies heavily on it. I had to remove
a few unnecessary imports to make it compile properly.

I mentioned last week a problem with the TLS implementation. I 
wasn't sure what it was at first - I thought it was an alignment 
problem. Some TLS variables were corrupt, some weren't. Some time 
in the debugger found that the FreeRTOS TLS implementation was 
[clobbering the 
registers](https://github.com/hmmdyl/LWDR/wiki/Thread-Local-Storage#register-clobbering-on-arm-eabi).

Until the 15th, I will be working on task 2 - implementation of 
Object monitor and synchronisation primitives. If I have spare 
time I will have LWDR generate cycle path information if it 
detects a module dependency cycle.

All the best,
Dylan Graham