On Sunday, 14 June 2015 at 19:44:48 UTC, Adrian Matoga wrote:
On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote:
On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga
wrote:
If there's anything I can help with, let me know. My experience
with GDC is close to non-existent (I managed
On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote:
On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote:
Generally, if we stick to the pay-as-you-go approach most
features of D runtime (even exceptions and RTTI) can be ported.
They will not imply any costs when not used, but
I somehow missed this topic earlier but I played a bit with
embedded runtime last month so I'll share some thoughts.
On Sunday, 10 May 2015 at 06:55:07 UTC, Jens Bauer wrote:
On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote:
I've also considered another interesting approach. It seems
On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote:
Generally, if we stick to the pay-as-you-go approach most
features of D runtime (even exceptions and RTTI) can be ported.
They will not imply any costs when not used, but will be ready
to
use out-of-the-box when they're needed.
On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote:
On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote:
I already have supplied those options in my toolchain.
But does anyone know if this is advisable when using FreeRTOS
(or any other RTOS for that matter) ?
-I'm asking, because I'm
On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote:
I already have supplied those options in my toolchain.
But does anyone know if this is advisable when using FreeRTOS
(or any other RTOS for that matter) ?
-I'm asking, because I'm not using any RTOS myself, but there
are loads of
On Friday, 8 May 2015 at 02:25:48 UTC, Mike wrote:
The ports folder in this experiment is essentially the
platform abstraction layer. However, it's resolved at
link-time. What do you suggest: A reserved module/package
implementing a standard interface that is imported at
compile-time? I
On Friday, 8 May 2015 at 02:25:48 UTC, Mike wrote:
What do you suggest: A reserved module/package implementing a
standard interface that is imported at compile-time? I could
do that.
You just import the right PAL (maybe renamed private import) and
everything is typechecked.
Mike n...@none.com writes:
I've gotten even further thanks to everyone's help, but LDC is still
giving me a little grief. Take a look at these undefined references
(abbreviated for this forum):
(_D10TypeInfo_l6__vtblZ+0x8): undef ref
`_D6object8TypeInfo8toStringMxFNaNbNfZAya'
-- snip --
Am Thu, 07 May 2015 16:29:50 +
schrieb Jens Bauer doc...@who.no:
{snip}
Every port is in its own branch
In this case, the files must share the same parent directory, in
order to be updated by a merge with master; correct ?
IIRC it's not always necessary. Git can detect if you moved
On Tuesday, 5 May 2015 at 02:26:28 UTC, Mike wrote:
Porting to a New Platform
**
The platform-agnostic code in d delgates implementation
details to the platform-specific code using `extern(C) extern
_d_sys_name` system calls (for lack of a better term).
You plan
On Thursday, 7 May 2015 at 07:00:58 UTC, Dan Olson wrote:
Mike, try creating an empty ldc2.conf file where you compile
from (I
just tried so it should work). That will override the one that
came with
your ldc2 installation that has searches the real
druntime/phobos before
your versions. It
On Thursday, 7 May 2015 at 09:55:11 UTC, Kagamin wrote:
On Tuesday, 5 May 2015 at 02:26:28 UTC, Mike wrote:
Porting to a New Platform
**
The platform-agnostic code in d delgates implementation
details to the platform-specific code using `extern(C) extern
On Tuesday, 5 May 2015 at 02:26:28 UTC, Mike wrote:
{snip}
Putting it all Together
Users are not expected to use this code directly. Rather, I
envision toolchain, silicon, and board vendors will use this
code as a small, but essential part of, their platform's D
Am Thu, 07 May 2015 11:52:29 +
schrieb Mike n...@none.com:
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)
On Tuesday, 5 May 2015 at 06:56:52 UTC, Iain Buclaw wrote:
On 5 May 2015 at 08:39, Dan Olson via Digitalmars-d
digitalmars-d@puremagic.com wrote:
How about a -disable-tls option so that when there are no
threads and
thus no TLS, you can compile exising D code as-is. Otherwise
you have
to
On Thursday, 7 May 2015 at 16:12:36 UTC, Johannes Pfau wrote:
{snip}
Let me explain the git idea:
I think it's a great idea.
{snip}
Porters simply grep for 'Not implemented' and implement the
function
This sounds easy.
{snip}
(Even if we define formal hooks and a port/ directory
Mike n...@none.com writes:
That did it! But I thought defaultLib= did the same thing. Anyway,
Thanks for all your help, Dan.
I now have support for all 3 compilers porting to 2 different
platforms (one bare metal microcontroller, one modern OS). It can't
do anything more than Hello,
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
On Wednesday, 6 May 2015 at 07:20:38 UTC, Johannes Pfau wrote:
What I would like to see, however, is a friendly compiler
error like This platform does not support thread-local
storage. Please decorate your global variables with
__gshared. rather than undefined reference '_d_get_address'
Am Wed, 06 May 2015 04:47:53 +
schrieb Suliman everm...@live.ru:
Maybe it's stupid question, but is there any chance to get D on
AVR(8/16 bit)?
Yes! I've written small D test programs for AVR.
The only problem could be far pointers. However, far pointers are
very rare in AVR code and
Am Wed, 06 May 2015 02:44:53 +
schrieb Mike n...@none.com:
On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
Am Tue, 05 May 2015 08:41:13 -0700
schrieb Dan Olson zans.is.for.c...@yahoo.com:
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com
writes:
If the
Yes! I've written small D test programs for AVR.
you mean 8-bit AVR? It's very cool! Could you show sources code
example?
On Tuesday, 5 May 2015 at 08:13:21 UTC, Mike wrote:
On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote:
LDC Folks: https://github.com/ldc-developers/ldc/issues/781
is
currently preventing me from supporting LDC with this runtime.
I looked at this and found a workaround and noted it
Am Wed, 06 May 2015 07:44:03 +
schrieb Suliman everm...@live.ru:
Yes! I've written small D test programs for AVR.
you mean 8-bit AVR? It's very cool! Could you show sources code
example?
Yes [1] [2] [3]. Only Hello-World / proof of concept kind of code for
now. There are no fundamental
The progress here is nice. I'd like to do similar stuff with LDC but
have a couple other projects to finish up first.
More thoughts on supporting systems without threads:
Mike n...@none.com writes:
On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
I'm not really sure about this.
On Tuesday, 5 May 2015 at 18:13:03 UTC, Iain Buclaw wrote:
It should also be possible for compilations to succeed without
rt/typeinfo - and for the compiler to not assume they exist
(Type::builtinTypeInfo).
That would also be most welcome.
On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
Am Tue, 05 May 2015 08:41:13 -0700
schrieb Dan Olson zans.is.for.c...@yahoo.com:
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com
writes:
If the cost is too much (ie: there is no heap), then we
should be
able to stop
Maybe it's stupid question, but is there any chance to get D on
AVR(8/16 bit)?
Mike n...@none.com writes:
On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote:
LDC Folks: https://github.com/ldc-developers/ldc/issues/781 is
currently preventing me from supporting LDC with this runtime.
I looked at this and found a workaround and noted it in the above
issue
link.
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com writes:
If the cost is too much (ie: there is no heap), then we should be able
to stop emutls from kicking in by preventing the D frontend from
returning true on isThreadLocal calls.
Iain, I think something like this would be good in
Am Tue, 05 May 2015 08:41:13 -0700
schrieb Dan Olson zans.is.for.c...@yahoo.com:
Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com writes:
If the cost is too much (ie: there is no heap), then we should be
able to stop emutls from kicking in by preventing the D frontend
from
Mike n...@none.com writes:
Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment
There was recently a discussion about how we could create a portable,
pay-as-you-go, D runtime to help bring the promise of D to
free-standing platforms and devices with tight resource
On 5 May 2015 at 08:39, Dan Olson via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Mike n...@none.com writes:
Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment
There was recently a discussion about how we could create a portable,
pay-as-you-go, D runtime to help
On Tuesday, 5 May 2015 at 06:56:52 UTC, Iain Buclaw wrote:
Configure GDC with --disable-tls --disable-threads to get the
desired behaviour (disabling only TLS just makes codegen
fallback to emulated thread support).
I didn't know this. You mean if I configure with those options,
TLS
On Tuesday, 5 May 2015 at 06:39:42 UTC, Dan Olson wrote:
LDC Folks: https://github.com/ldc-developers/ldc/issues/781 is
currently preventing me from supporting LDC with this runtime.
I looked at this and found a workaround and noted it in the
above issue
link.
Many Thanks!
I've gotten
On 5 May 2015 at 09:48, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 5 May 2015 at 06:56:52 UTC, Iain Buclaw wrote:
Configure GDC with --disable-tls --disable-threads to get the desired
behaviour (disabling only TLS just makes codegen fallback to emulated thread
Am Tue, 05 May 2015 02:26:26 +
schrieb Mike n...@none.com:
Read on GitHub:
https://github.com/JinShil/minimal_druntime_experiment
There was recently a discussion about how we could create a
portable, pay-as-you-go, D runtime to help bring the promise of D
to free-standing platforms
On 5 May 2015 at 19:38, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com 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
Read on GitHub:
https://github.com/JinShil/minimal_druntime_experiment
There was recently a discussion about how we could create a
portable, pay-as-you-go, D runtime to help bring the promise of D
to free-standing platforms and devices with tight resource
constraints (e.g. microcontrollers).
40 matches
Mail list logo
