Hi,
Today is my first D-day. I haven't even written any d-code yet,
but I've got the compiler for my PPC-based Mac (yes, it's old).
I'm familiar with compiling toolchains for ARM Cortex-M0, M3 and
M4.
Is there any information on how to build a cross-gdc targetting
these architectures ?
Eg. the
It seems I've found it...
http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler
-It also seems I have to use gcc-4.9, as the gcc-4.8 branch does
not seem to exist in the git repository ?
On Thursday, 15 January 2015 at 16:58:34 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 15 January 2015 at 16:49, Jens Bauer via Digitalmars-d
-It also seems I have to use gcc-4.9, as the gcc-4.8 branch
does not seem to exist in the git repository ?
That should be gdc-4.8, gdc-4.9
I just
Build failed on final gcc.
I normally use newlib and multilib, because I'm developing for
Cortex-M0, Cortex-M3 and Cortex-M4 and would like to be able to
switch between those and use the same compiler.
But following the above mentioned instructions seem to suggest
disabling multilib and using
Thank you both Mike and Timo for clearing these things up. :)
(I had the impression that multilib replaced glibcc, not the
other way round - but clearly that's not what it was about).
I've spent around 3 years on getting my toolchain working (!)
-This is because I'm on a PowerPC based Mac. I ca
I've sometimes wished for a while ... else combination in C.
-But I never got around to proposing my suggestion to whoever or
whatever committee is in charge of the C language.
But since D is a language that has much more freedom regarding
implementation, I'd like to suggest it here. :)
This
On Sunday, 18 January 2015 at 16:03:24 UTC, MattCoder wrote:
On Sunday, 18 January 2015 at 15:52:24 UTC, Jens Bauer wrote:
Maybe I misunderstood your question, but what you think about
this way:
... It's close, but the result would be different.
The while is a combined if+while, where the fi
On Sunday, 18 January 2015 at 18:16:47 UTC, Marc Schütz wrote:
Unfortunately, this would break existing code:
That is absolutely correct. Good catch. I did not think of that
particular case.
However... What if the 'else', which "belongs" to while, is named
differently, for instance ...
wh
I'd like to give an example on a different use of the same
feature:
while(length--)
{
*d++ = *s++;
}
if(length == -1) /* the programmer will need to know the value
of length here. */
{
/* handle case where length was exactly 0, it's now -1 */
}
would become:
while(length--)
{
*d
On Sunday, 18 January 2015 at 23:06:27 UTC, ketmar via
Digitalmars-d wrote:
it will introduce a new keyword, and it will break any code
which using
"otherwise" as identifier. as far as i can tell this
(introducing new
keyword) is one of the hardest thing to do, 'cause Walter will
reject
it wit
Encouraged by Timo Sintonen's great posts, I decided to spend
some time trying to build a Cortex-M toolchain for D-programming.
So this morning, I've successfully built my first toolchain
supporting C, C++ and D for the first time.
I wanted to take the new language out for a spin, but I ran into
(I just found out that I should probably have posted this in the
digitalmars.D.learn forum instead, sorry for the inconvenience)
I belive the following information is slightly incorrect:
"GDC requires the following minimal object.d file in the same
folder as start.d. It is imported automatically."
My tests have shown that object.d needs to be in the CWD, not in
the same directory as "start.d".
This is my command-line:
On Tuesday, 31 March 2015 at 15:50:17 UTC, Dan Olson wrote:
"Mike" writes:
I just cut and pasted the code from the wiki myself and
compiled with
my arm-none-eabi-gdc cross-compiler and it works fine. I'm
sorry, but I'm not sure what the problem could be.
Mike
Yeah, something strange. The
Unfortunately, my attempt to build GDC on my CubieBoard2 failed.
However, I decided to change the line slightly, in order to find
out exactly what's going wrong...
src/start.d:46:12: error: mismatched array lengths, 0 and 3
uint[4]message=[2,cast(uint)"hello\r\n".ptr,7];
^
ma
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
Am Wed, 01 Apr 2015 12:56:22 +
It could be an endianess issue somewhere in the code. I
debugged a misaligned-access bug in the frontend some time ago,
bugs like these can result in the weirdest effects.
Indeed. I had some st
I have successfully built GDC on CubieBoard2 (Cubian) now.
I've rebuilt GDC on the G5 as well, using the same script.
I've used nano for making object.d and start.d, in order to avoid
too many problems with character encoding.
In addition, I've used hexdump -C .d to verify that the
text-files a
So are there any suggestions on enabling debug-code, which
might give hints on what is going wrong ?
I'm not sure if there's any debug code, but here's what I would
do [snip]
Mike and Johannes - Thank you both for the suggestions.
I will follow the debug path you've given me when I've finishe
Reading lexer.c, in order to find out what's causing me problems
on my PowerMac, I came across this snippet, and I'd like to point
out that it is not reliable:
case '\r':
p++;
if (*p != '\n') // if CR stands
by itself
any compiler that does the second is broken and should be
fixed. DMD is not broken.
If the byte values for \n and \r are clearly given as \r = 13
(0x0d) and \n = 10 (0x0a), instead of \n = newline and \r =
carriage return, then I agree.
However, I know 5 compilers, which do swap \r and \n, b
I got a little further, and will continue to look into the issue.
Currently, this is what I've gotten so far...
arm-none-eabi-gdc start.d -c -wrapper gdb,--args
break expression.c:11707
break expression.c:11570
break init.c:1015
break init.c:557
run
...
Breakpoint 1, AssignExp::semantic (this=
Which compilers?
MrCpp, MrC, MPWC, MPWCpp and CodeWarrior.
These compilers must respect the platform's definition of \n =
newline and \r = carriage return.
Because the platform defines newline = 13, then \n must have the
value 13.
Since there's not clear definition of \n and \r, they can't
On Thursday, 2 April 2015 at 12:24:22 UTC, Kagamin wrote:
On Thursday, 2 April 2015 at 11:42:50 UTC, Jens Bauer wrote:
On the other hand, if a file was copied to a platform, where
\r = 13 and \n = 10, and the file contains lines ending in
0x0d, then this compiler would not be able to build the
On Thursday, 2 April 2015 at 11:55:09 UTC, ketmar wrote:
so your suggestion actually *introduces* the bug in DMD.
Nope, not if implemented correctly.
0x0a should be handled, 0x0d should be handled and 0x0d0a should
be handled.
But if using \r and \n, then you would have problems with 0x0d0a
On Thursday, 2 April 2015 at 13:16:20 UTC, Daniel Murphy wrote:
"Jens Bauer" wrote in message
news:otojrdbbmfcfkuyol...@forum.dlang.org...
MrCpp, MrC, MPWC, MPWCpp and CodeWarrior.
That's horrible.
I completely agree. But it's not the only thing that's wrong on
the particular platform (I
Well, it seems I found the problem.
lexer.h, line 203 reads:
union
{
d_int32 int32value;
d_uns32 uns32value;
d_int64 int64value;
d_uns64 uns64value;
...
...
...
};
While this optimization is neat, it does not produce correct co
I better also mention that the problem is the same for floats in
Lexer::inreal(Token *).
On Friday, 3 April 2015 at 08:06:03 UTC, Jens Bauer wrote:
I better also mention that the problem is the same for floats
in Lexer::inreal(Token *).
Ignore that - it's always read/written as a long double.
Sorry for then noise.
On Friday, 3 April 2015 at 10:32:39 UTC, Daniel Murphy wrote:
It doesn't matter for this hash table.
Alright - if there's no major difference in performance, then it
won't matter (Johannes mentioned that it's only used internally).
I've sent an email to Johannes regarding the patch - because
On Friday, 3 April 2015 at 14:22:43 UTC, Kai Nacke wrote:
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote:
I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian
system.
LDC is endian-clean. I used LDC on big-endian Linux/PPC64.
Unfortunately, I can't b uild LLVM on my
On Friday, 3 April 2015 at 15:41:34 UTC, David Nadlinger wrote:
On Friday, 3 April 2015 at 14:39:35 UTC, Jens Bauer wrote:
Unfortunately, I can't b uild LLVM on my PowerMac. :/
Why would that be so?
Basically because it requires GCC > 4.2 - but unfortunately
there's more.
Once upon a time,
On Friday, 3 April 2015 at 16:11:59 UTC, Iain Buclaw wrote:
On 3 April 2015 at 17:58, Jens Bauer via Digitalmars-d
Basically because it requires GCC > 4.2 - but unfortunately
there's more.
Once upon a time, LLVM did support being built with GCC 4.2,
but I can't get
those sources
On Friday, 3 April 2015 at 16:39:40 UTC, David Nadlinger wrote:
On Friday, 3 April 2015 at 15:58:03 UTC, Jens Bauer wrote:
Basically because it requires GCC > 4.2 - but unfortunately
there's more.
Once upon a time, LLVM did support being built with GCC 4.2,
but I can't get those sources anymore
On Friday, 3 April 2015 at 17:05:28 UTC, John Colvin wrote:
There is universal binary of LLVM 2.1 with clang (llvm-gcc back
then I think) available here:
http://llvm.org/releases/2.1/llvm-llvm-gcc4.0-2.1-darwin-univ.tar.gz
Thank you so much; I'll try it immediately. I don't know why I
haven't
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
Hello everyone, this is my first post on the forum.
Then as a fellow newcomer to D, let me be the first to welcome
you. :)
I wrote a blog post on why I'm excited about D. You can read it
here: http://hawkins.io/2015/04/excited-about
On Tuesday, 7 April 2015 at 00:28:11 UTC, Rikki Cattermole wrote:
I was slightly surprised that you didn't mention CTFE in there
as it is one of D's unique and powerful features.
But only because I'm a little invested https://leanpub.com/ctfe
in it.
It is very cool, that you can generate table
On Tuesday, 7 April 2015 at 00:57:09 UTC, Rikki Cattermole wrote:
CTFE could have some pretty awesome applications for embedded I
suspect. After all, you can pregenerate data structures ext.
For faster execution.
Yes, they're particularly useful for embedded devices.
I've often used tables in
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
@property isn't really about parentheses-less calls
(parentheses are optional for all function calls), it's more
for this sort of thing:
[snip]
@property void val(int v)
{
a_ = (a_ & flagMask) & (v & ~flagMask);
}
On Tuesday, 7 April 2015 at 01:28:03 UTC, Rikki Cattermole wrote:
I'm watching your progress closely. I think we are ready to get
D properly on micro controllers and you are really testing,
exploring it even.
Johannes made some very important additions for regarding this.
It might already be p
On Tuesday, 7 April 2015 at 16:29:40 UTC, Walter Bright wrote:
I noticed a bug in one of the examples:
assert("Adam Hawkins" == myName());
should be:
assert("Adam Hawkins" == myName());
-It already is. :)
By the way; the reason to switch from C to D can be put *very*
simple:
:C ->
On Tuesday, 7 April 2015 at 16:39:39 UTC, Jens Bauer wrote:
:C -> :D
Even better (includes the meaning of '=' in place of 'when'):
=C -> =D
On Tuesday, 7 April 2015 at 17:25:00 UTC, Walter Bright wrote:
The current D associative array algorithm
I did a quick-scan of the source and didn't see any Bloom filter
there.
I wonder if it would be best to have the Bloom filters completely
external or if they should be included in the asso
I voted for nano+uCode (my own IDE, which is still pre-alpha).
uCode is designed for microcontroller and SPLD/CPLD use.
nano, because it's the only editor on a Mac, I can be sure of
handling Unicode well.
(TextEdit messes up unicode files, Xcode 2.5 seems to work with
Unicode, but Xcode 3.x mes
On Wednesday, 8 April 2015 at 08:59:04 UTC, Szymon Gatner wrote:
From StackOverflow's 2015 Developer Survey [1]:
Mac appears to have overtaken the Linuxes among active Stack
Overflow devs.
[1]http://stackoverflow.com/research/developer-survey-2015
If they wanted to have some more reliable num
On Wednesday, 8 April 2015 at 10:43:43 UTC, Dmitri Makarov wrote:
On Wednesday, 8 April 2015 at 10:29:44 UTC, Jens Bauer wrote:
nano, because it's the only editor on a Mac, I can be sure of
handling Unicode well.
Emacs provides complete Unicode support.
True - and I do like Emacs, but I need
On Wednesday, 8 April 2015 at 13:20:18 UTC, Jacob Carlborg wrote:
Xcode 2.5?? You're a bit behind.
Xcode 2.5 is the best Xcode. There's only one IDE from Apple
which is better: Project Builder!
The rest of them are too broken for me. Xcode 3.x keeps spamming
my console.
Even if I could run
On Saturday, 11 April 2015 at 15:35:47 UTC, w0rp wrote:
From what I just read, __attribute__((used)) in GCC should do
the job, and I think it should be usable from GDC with its
attribute pragmas.
I wouldn't mind having this functionality.
For a long time, I've wanted it in C in those cases w
Some of you already know that I've been working on startup files
for STM32F4xx and LPC17xx.
Since a number of people have shown interest in these files, I've
now merged those two repositories into one and improved it for
adding more vendors.
What I'd like you to do, is to tell me which micro
On Sunday, 26 April 2015 at 14:18:24 UTC, Dicebot wrote:
On Sunday, 26 April 2015 at 07:04:06 UTC, Jens Bauer wrote:
Some of you already know that I've been working on startup
files for STM32F4xx and LPC17xx.
https://github.com/jens-gpio/MCU
Please mention that in wiki.dlang.org
May be even
On Sunday, 26 April 2015 at 16:09:57 UTC, Martin Nowak wrote:
On 04/26/2015 05:55 PM, Jens Bauer wrote:
Done.
http://wiki.dlang.org/Microcontroller_startup_files
-This is my first successful Wiki page, BTW. :)
Nice, minilibd seems to be maintained as well, you happen to
know the author?
I
On Sunday, 26 April 2015 at 16:34:09 UTC, Dicebot wrote:
On Sunday, 26 April 2015 at 15:55:34 UTC, Jens Bauer wrote:
Done.
http://wiki.dlang.org/Microcontroller_startup_files
Thanks! It is important for that information not be lost among
hundreds of NG posts, wiki is much more searchable.
On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
On 04/26/2015 07:29 PM, Jens Bauer wrote:
Unfortunately, I have not been able to build with multilib
yet, so my
setup cannot build code for Cortex-M0; it keeps stuffing
Cortex-M3 and
Cortex-M4 instructions in there.
The wiki says
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
I have also tried for years to build a working multilib without
success. Now I think I have been able to get all versions to
work. I welcome everyone to test and report
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
I have also tried for years to build a working multilib without
success. {snip}
Please note: This is the first time ever I have suceeded. This
will not work with any g
On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:
On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
wrote:
The reason I cannot build GDC with multilib, is that I get a
compile-error
when building the final GCC+GDC.
Building GCC alone without GDC gives me no such error.
-So
On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:
On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
wrote:
{snip}
The reason I cannot build GDC with multilib, is that I get a
compile-error when building the final GCC+GDC.
Correction: it's a 'build-error',
On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:
On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d
{snip}
As you see, config.h, libstdc++ and multilib are all present
in this chunk.
Try building with --disable-libstdcxx as in the suggestion from
Timo.
Unfortunately, it
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
The build script:
../gcc/configure --disable-bootstrap \
--enable-languages=c,d --disable-nls --target=arm-eabi \
--without-headers --with-newlib --without-isl --without-cloog \
--disable-libphobos --disable-libstdcxx --disable-libb
On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
Given the other replies in this thread, this looks promising.
However, I went to give it a test today, and found out my host
PC's distribution (Arch Linux) hasn't yet released GCC 5.1;
it's still in testing.
You don't have to wait for
On Tuesday, 28 April 2015 at 02:18:29 UTC, Mike wrote:
On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:
You don't have to wait for an Arch Linux release of GCC 5.1,
I always thought we needed to build our cross-compilers with
the same version as the host in order to have confiden
On Tuesday, 28 April 2015 at 04:05:15 UTC, Mike wrote:
On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
[...]
If you suspect it might work for GCC 4.9.2, I'll give it a try.
I tested this script generating an arm-none-eabil 4.9.2
cross-compiler with a 4.9.2 host. My build script is he
On Tuesday, 28 April 2015 at 06:32:16 UTC, Mike wrote:
On Monday, 27 April 2015 at 18:26:35 UTC, Jens Bauer wrote:
On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:
On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d
{snip}
As you see, config.h, libstdc++ and multilib are all
On Wednesday, 29 April 2015 at 03:11:05 UTC, Mike wrote:
On Tuesday, 28 April 2015 at 12:13:38 UTC, Jens Bauer wrote:
What ? -Are gmp, mpc and mpfr not required anymore ?
I don't see why they should be required for this use case. I'm
building a cross-compiler that will run on my Linux 64-bi
On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
Nevertheless, when GCC 5.1 is official released for my
distribution, I'll give it a test (if it's not too late by
then).
If you suspect it might work for GCC 4.9.2, I'll give
On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:
On 04/27/2015 03:42 PM, Timo Sintonen wrote:
The basic idea has been to make as little changes as possible.
I started
Wonder if it makes more sense to start from zero and add as few
files as possible.
That was my thought too.
On Thursday, 30 April 2015 at 06:43:18 UTC, Timo Sintonen wrote:
{snip}
I think it is possible to make a minimum bare metal runtime
from scratch.
{snip}
Yes I think it won't be too difficult.
All are good points that we should have in mind, while deciding
on how we proceed.
-Also Mike's input
On Thursday, 30 April 2015 at 20:54:07 UTC, Martin Nowak wrote:
On 04/30/2015 08:43 AM, Timo Sintonen wrote:
Printf is a little tricky. It is actually a file operation to
stdout and that is actually a syscall to kernel.
No, you usually have to implement some hook for outputting
yourself, e.g.
On Thursday, 30 April 2015 at 23:03:48 UTC, Mike wrote:
On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:
* Is data and bss initialization part of the runtime, or
delegated to toolchain, silicon, and BSP vendors?
We should provide appropriate linker scripts and do the
initiali
On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
Thus I would expect the hook to be somewhere in vfprintf ?
As Timo said, eventually, what printf needs is the `write`
syscall. The C library needs to be ported to the hardwar
On Friday, 1 May 2015 at 07:30:03 UTC, Timo Sintonen wrote:
On Thursday, 30 April 2015 at 23:49:52 UTC, Jens Bauer wrote:
Most asserts on microcontrollers I've seen are just
implemented as while(1){}
-But one could probably also trigger the debugger (BKPT),
HardFault or RESET if necessary.
Pe
On Friday, 1 May 2015 at 07:44:49 UTC, Timo Sintonen wrote:
On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
Thus I would expect the hook to be somewhere in vfprin
On Friday, 1 May 2015 at 09:49:51 UTC, Jens Bauer wrote:
A hacky open could return a pointer to an object, because the
returned value is a 32-bit integer, which is the same size as a
pointer and:
... would introduce a lot of dangling pointer errors instead of
'error: file not open'...
On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy
wrote:
I would like to use D on SmartOS.
SmartOS looks pretty interesting. [see docker.com] :)
{snip}
Unfortunately I get this error;
{snip}
On Thursday, 30 April 2015 at 17:54:00 UTC, Joakim wrote:
dmd git HEAD requires a host D
On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:
On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
IMO it should be opt in.
Agree. :)
The problem I've seen with most C-solutions, is that once someone
uses printf, the binary suddenly grows out of proportions. (It
may be because
On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
Std.format, as suggested, would be too big. I tis easty to copy
the printf formatter from libc sources. Or just write an own.
It does not have to support all the features.
On Saturday, 2 May 2015 at 09:17:57 UTC, Martin Nowak wrote:
On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
Is it possible to write the malloc so it's "garbage
collector-friendly" ?
Garbage collection on microcontrollers doesn't make sense,
because the memory consumption will alwa
On Saturday, 2 May 2015 at 10:38:51 UTC, Timo Sintonen wrote:
On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:
On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
No need to rewrite libc, just link against it and use whatever
is needed.
I have assumed we are going the w
On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:
On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:
Will it be possible to have associative arrays without garbage
collection ?
You can write an AA container. A RefCounted AA implementation
might allow unsafe escaping though.
On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:
On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:
{snip} these 32-bit ARM chips have processing power to spare.
Definitely. Even though they might only be running between 100
and 200 MHz, they're much more powerful than the compute
On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:
{snip} the overhead per block was only a single bit + the
malloc header.
Correction: The overhead was a single bit + 1/128 of the malloc
header, because we had 128 blocks per cluster.
Thus if having a cluster of 32 blocks, the overhead w
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
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 rewrite normal variables to __g
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
prog
I'm sorry for opening such a topic; I've heard it's not liked a
lot, but I think it might be necessary.
I'm not asking for a 'volatile' keyword, but rather to find out
what the right thing to use is.
After reading a few different threads related to
microcontrollers, I started wondering how 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 struc
On Thursday, 7 May 2015 at 21:42:08 UTC, Iain Buclaw wrote:
On 7 May 2015 at 23:39, Iain Buclaw
wrote:
When used properly though, it's properties make it a prime
candidate
for the foundation of libraries/programs that centre around
the use of
atomics. However, shared is not to be confused wit
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?
On Saturday, 9 May 2015 at 12:16:58 UTC, Kagamin wrote:
On Thursday, 7 May 2015 at 16:04:56 UTC, Jens Bauer wrote:
Regarding (1), because marking a variable 'shared' is not
enough (it allows instructions to be moved around), Johannes
already made a volatileLoad and volatileStore, which will be
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 not
On Sunday, 10 May 2015 at 12:43:31 UTC, Kagamin wrote:
On Saturday, 9 May 2015 at 16:59:35 UTC, Jens Bauer wrote:
... "System calls" will need to access the peripherals in some
way, in order to send data to for instance a printer or
harddisk. If the way it's done is using a memory location,
th
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 to
On Thursday, 18 June 2015 at 04:35:31 UTC, Rikki Cattermole wrote:
On 18/06/2015 4:25 p.m., Joakim wrote:
On Thursday, 18 June 2015 at 04:01:42 UTC, Rikki Cattermole
wrote:
I agree with Rikki that it'd be better to add features to the
web forum
in a backward-compatible way, such as putting tag
Hi all.
If you're interested in developing in D for embedded systems, and
you want a board, please let me know.
I've decided to be a sponsor of 3 boards + programming adapters
(aka. "dongles").
The board:
http://shop.ebay.com/181630173615
-It has 64KB Flash memory and 20KB on-chip SRAM.
There
92 matches
Mail list logo
