On Tuesday, 5 May 2015 at 17:38:38 UTC, Johannes Pfau wrote:
I would probably split the runtime into at least two, probably
three
parts:
* Compiler support library (object.d, gcc/*.d, exception
implementation) (module rt/ no module name)
* Higher level library (portable, micro)
* Hardware specific library (not portable, avr/ stm/)
I think some basic portability between microcontrollers is
useful. The
compiler support library should be only a few 100 lines of code
and
should be without external dependencies. This way it's also
useful for
very small platforms (8bit) or use-cases where you inject code
into
other processes. It's trivial to port: we should have an ansi-c
port
and native ports should be implementable in 1-2 hours.
The higher level library should contain stuff like
'core.time.Duration',
emplace, allocator framework, Volatile!T, register wrapper
types, etc.
The implementation could be hardware specific, but it should
provide a
common interface (e.g. a delay!Duration function has got a
common
interface but different implementation, malloc is similar).
Namespace micro => import micro.time; import micro.memory;
So everything in the micro namespace is portable.
The hardware library the provides access to hardware specific
peripherals. In reality the high-level-library might require the
hardware library or they could actually be merged. The
important part
is portable vs platform specific module API for user code.
Sorry for the late reply, but I'm still chewing and digesting
this. How do you propose delegating implementation down the
supply chain? I suppose you may have answered that with your git
idea below, but did you have something else in mind?
I think that's really what I'm trying to work out with this
experiment: How to delegate the implementation so it's obvious
what porters need to do without a lot of explanation, and they
can implement just the features they need.
A radically different approach instead of using ports
directories is
using git features: Have a base repository with a master branch
which
only includes the interfaces, probably with static assert
wherever
platform specific code is necessary. Then have AVR/STM32/LPC/...
branches where you simply implement these functions. (We could
also
have different repositories instead of branches)
+ you can modify all code
+ you already start with a common interface
+ changes are easy to compare by comparing git branches
+ changes have descriptions (in their git commits)
+ it's easy to merge further generic changes
I'll have to think about this and give it a try. I fear,
however, that it might be a little too radical for what people
are used to, but maybe not.
Phobos and core.stdc should then also be separate libraries.
Agreed.
* Add -fno-rtti compiler switch
This is something I could probably finish up in a few hours next
weekend.
That would be an immense help and productivity boost. Thanks for
your support.
* Add attribute support so programmer can choose which types
to generate runtime-time info for.
I can add an @attribute(notypeinfo) in GDC but it'll be
implemented in
the backend. This means we can prevent TypeInfo output but we
can't
reliably warn on TypeInfo usage. You'll get linker errors
instead.
Probably a good idea to table that for now.
Mike
