On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole
wrote:
I was referring to package.d files. And publically importing
all below modules/packages.
Normally, one would want to import only the most necessary parts.
Let's take an example: A microcontroller has USB, LCD controller,
Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM.
-But the program being developed only needs the LCD controller
and the USART, so the Ethernet should not be imported, because if
it's seen by the linker, the linker will include it in the final
binary. Thus the final binary will be huge, if all of those
interfaces are imported.
NXP made some #ifdef in their header files and it was terrible
working with these. You couldn't build one library, which would
work with all your projects, because then you would have a big
lump containing everything, including all the stuff you wouldn't
need.
I wonder if you can get e.g. interfaces and classes working.
I hope I will. ;)
I think classes are really a must. The only thing that I
(currently) see that could perhaps block this from working, would
be missing support for static constructors and a missing memory
allocator.
The missing memory allocator would be entirely because I would
have disabled it; this might be necessary on very small devices
(such as 1K RAM devices or worse).
Devices that have 64K on-chip memory might be big enough for
using new and delete on a regular basis (this is just guesswork).
If the programmer is instantiating classes carefully, it should
be possible to avoid too many problems.
My current startup.d files do not support static constructors.
static destructors are obsolete, because a microcontroller never
'exits'. If it's turned off, the constructed data gets
deallocated automatically when the power drops too low anyway. ;)
In other words: Normally main() never exits.
At worse maybe structs + alias this + meta programming for e.g.
drivers?
When you mention drivers, I'm reminded that on some devices, such
as the STM32F4xx, we have two types of on-chip SRAM: CCMRAM and
normal local SRAM.
The CCMRAM is not accessible by the DMA for instance. That means
if objects are allocated here, they cannot be accessed by the DMA.
In some cases, it would be desirable to 'prefer' allocating in
CCMRAM and if absolutely necessary, allocate in the other local
SRAM.
That means 'new' and 'delete' / 'malloc' and 'free' must be able
to handle multiple RAM locations (because there's also external
SRAM and external SDRAM).
