On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:
If we push to have this fixed after that we are pretty close
to having something usable are we not?
Depends on your definition of "usable". Fixing the bloat issue
would remove a current road block, and at least allow progress
to continue.
IMO, to make D a pleasant experience on the ARM Cortex-M
platform, we'll need to implement the entire druntime including
threading, GC, exceptions, dynamic arrays, etc... even if those
features are not used. This is because D just hasn't been
designed and implemented in a modular fashion to allow one to
pay-as-they-go, and as you experienced in one of your other
posts today, you just get too many undefined references and
other odd errors that have nothing to do with your code. The
only way to make those errors go away is to ensure everything
in druntime is there.
If the bloat problem were solved, we could at least continue
working towards that end. But it's not immediately apparent to
me how much overhead a complete runtime implementation will add
to as simple microcontroller application, and how well the
compiler and linker can optimize and remove that overhead. We
may encounter other roadblocks like I did with the TypeInfo
bloat, and have to fight a major battle to get something done
about it.
But I don't want to have to implement the entire druntime in
order to start making progress. It shouldn't have to be that
way.
Mike
I completely agree with you here, its a real shame! Id be happy
to put some effort into this, I don't know if you can help me put
pressure on the right people to get the bloat thing fixed. It
seems like its probably fixed in dmd compiler, but none of the
others. I think ldc2 is the compiler that has the most potential
because it can easily be compiled unlike the gdc one and then dmd
one doesn't seem to support arm out the box unless things changed
recently.
I'm happy to have a GC on a system like stm32, as I read it only
collects on calls to new, and most sensible embedded designs
would just allocate at initialization and not during runtime.
Threading I think we could easily use freertos or something
underneath.
Which just leaves dynamic arrays and exceptions which I know next
to nothing about right now :)
Firstly who do we need to talk to about the bloat in LDC?
