www.digitalmars.com         C & C++   DMDScript  

D.gnu - ICE due to unsupported target

reply "Mike" <none none.com> writes:
I'm getting an ICE in d-target.cc/critsecsize when I create a 
synchronized block.  Looking at the source code, it's pretty 
obvious why - my target (ARM Cortex-M bare metal) isn't any of 
the ones listed:

if (global.params.isWindows)
   ...
else if (global.params.isLinux)
   ...
else if (global.params.isFreeBSD)
   ...
else if (global.params.isOpenBSD)
   ...
else if (global.params.isOSX)
   ...
else if (global.params.isSolaris)
   ...

gcc_unreachable();  //ARM cortex-M (ARM Thumb): Ouch!

Interestingly, it only lists OSs, not CPU architectures.  If I 
look at the Param struct in mars.h, it seems there is no 
parameter that suits my target.

I may be able to submit a pull request to change this (at least 
partially), but I'm looking for advice on how to add support for 
my target.

* Does GDC/DMD need a new isARMThumb/isBareMetal/isWhatever param?
* Should critsecsize return sizeof(target's size_t) if not 
otherwise specified instead of calling gcc_unreachable()?

I realize there is a broader problem here than support for 
synchronized.  What's the correct way to go about adding support 
for my target platform.

Thanks,
Mike
Mar 07 2014
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 8 March 2014 at 07:52:10 UTC, Mike wrote:

 I'm getting an ICE in d-target.cc/critsecsize when I create a 
 synchronized block.  Looking at the source code, it's pretty 
 obvious why - my target (ARM Cortex-M bare metal) isn't any of 
 the ones listed:

 if (global.params.isWindows)
   ...
 else if (global.params.isLinux)
   ...
 else if (global.params.isFreeBSD)
   ...
 else if (global.params.isOpenBSD)
   ...
 else if (global.params.isOSX)
   ...
 else if (global.params.isSolaris)
   ...

 gcc_unreachable();  //ARM cortex-M (ARM Thumb): Ouch!

 Interestingly, it only lists OSs, not CPU architectures.  If I 
 look at the Param struct in mars.h, it seems there is no 
 parameter that suits my target.

 I may be able to submit a pull request to change this (at least 
 partially), but I'm looking for advice on how to add support 
 for my target.

 * Does GDC/DMD need a new isARMThumb/isBareMetal/isWhatever 
 param?
 * Should critsecsize return sizeof(target's size_t) if not 
 otherwise specified instead of calling gcc_unreachable()?

 I realize there is a broader problem here than support for 
 synchronized.  What's the correct way to go about adding 
 support for my target platform.

 Thanks,
 Mike


Why do you need synchronized? Are you building some kind of 
multithreading library?
Mar 08 2014
parent reply "Mike" <none none.com> writes:
On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:

 Why do you need synchronized? Are you building some kind of 
 multithreading library?


I don't need it yet.  I'm just exploring features of D and trying 
to learn how to implement them.  The real problem isn't that I 
can't use synchronized, but rather that the compiler is not aware 
of my target.  I haven't searched through GDC's source code yet, 
but I suspect there will be more problems in the near future if 
the compiler is not taught about this target.

Mike
Mar 08 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 08 Mar 2014 09:12:48 +0000
schrieb "Mike" <none none.com>:


 On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:

 Why do you need synchronized? Are you building some kind of 
 multithreading library?


 
 I don't need it yet.  I'm just exploring features of D and trying 
 to learn how to implement them.  The real problem isn't that I 
 can't use synchronized, but rather that the compiler is not aware 
 of my target.  I haven't searched through GDC's source code yet, 
 but I suspect there will be more problems in the near future if 
 the compiler is not taught about this target.
 
 Mike
 


critsecsize looks like a perfect example for configuration parameters
which should be provided by the runtime.

I'm thinking of a core/config.d module which can be read by the
compiler to get information about the runtime:
------------
enum critsecsize = 4;
enum hasGC = true;
enum hasAArray = true;
enum hasUnicodeLoops = true;
enum hasExceptions = true;
enum ...
------------

I wouldn't be too worried about 'isLinux' in general. Iain moved many
of these checks out of the frontend IIRC and rewrote them as checks
using Target::. In the end isLinux is just not the correct check if you
want to know the critsecsize/used ABI/...

grep isLinux */* shows that the only place in GDC where it's ever used
is critsecsize. 
If you grep for isWindows you'll see that these checks are DMD-only and
GDC already avoids them. (isWindows affects extern(System) but that's
fine). It's similar for in the other cases.

So the compiler doesn't really have to be aware you're targeting
bare-metal as it shouldn't be tightly coupled to OS anyway. But what
you might want is a version identifier for 'BareMetal/NoOS' and
'CortexM3'. If you really need those, file a pull request for this
documentation:
http://dlang.org/version.html

For GDC version identifiers are implemented using these GCC patches:
https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/patches/patch-versym-cpu-4.9.x
https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/patches/patch-versym-os-4.9.x

I'm not really sure if CortexM3/M4 versions are easy to add though.
General rule: If there's some kind of macro for this in GCC/C/C++ it's
easy to add for GDC.
Mar 08 2014
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 8 March 2014 09:37, Johannes Pfau <nospam example.com> wrote:

 Am Sat, 08 Mar 2014 09:12:48 +0000
 schrieb "Mike" <none none.com>:


 On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:

 Why do you need synchronized? Are you building some kind of
 multithreading library?


 I don't need it yet.  I'm just exploring features of D and trying
 to learn how to implement them.  The real problem isn't that I
 can't use synchronized, but rather that the compiler is not aware
 of my target.  I haven't searched through GDC's source code yet,
 but I suspect there will be more problems in the near future if
 the compiler is not taught about this target.

 Mike


 critsecsize looks like a perfect example for configuration parameters
 which should be provided by the runtime.

 I'm thinking of a core/config.d module which can be read by the
 compiler to get information about the runtime:
 ------------
 enum critsecsize = 4;
 enum hasGC = true;
 enum hasAArray = true;
 enum hasUnicodeLoops = true;
 enum hasExceptions = true;
 enum ...
 ------------

 I wouldn't be too worried about 'isLinux' in general. Iain moved many
 of these checks out of the frontend IIRC and rewrote them as checks
 using Target::. In the end isLinux is just not the correct check if you
 want to know the critsecsize/used ABI/...


The first step was to get the front-end shared among gdc and dmd.

The next step is to fix the codegen so that it does not rely on the
compiler knowing the critsecsize.
Mar 08 2014
parent Johannes Pfau <nospam example.com> writes:
Am Sat, 8 Mar 2014 11:45:18 +0000
schrieb Iain Buclaw <ibuclaw gdcproject.org>:

 
 The next step is to fix the codegen so that it does not rely on the
 compiler knowing the critsecsize.


That's better, of course!
Mar 08 2014
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Mar 8, 2014 9:40 AM, "Johannes Pfau" <nospam example.com> wrote:

 Am Sat, 08 Mar 2014 09:12:48 +0000
 schrieb "Mike" <none none.com>:


 On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:

 Why do you need synchronized? Are you building some kind of
 multithreading library?


 I don't need it yet.  I'm just exploring features of D and trying
 to learn how to implement them.  The real problem isn't that I
 can't use synchronized, but rather that the compiler is not aware
 of my target.  I haven't searched through GDC's source code yet,
 but I suspect there will be more problems in the near future if
 the compiler is not taught about this target.

 Mike


 critsecsize looks like a perfect example for configuration parameters
 which should be provided by the runtime.

 I'm thinking of a core/config.d module which can be read by the
 compiler to get information about the runtime:
 ------------
 enum critsecsize = 4;
 enum hasGC = true;
 enum hasAArray = true;
 enum hasUnicodeLoops = true;
 enum hasExceptions = true;
 enum ...
 ------------

 I wouldn't be too worried about 'isLinux' in general. Iain moved many
 of these checks out of the frontend IIRC and rewrote them as checks
 using Target::. In the end isLinux is just not the correct check if you
 want to know the critsecsize/used ABI/...

 grep isLinux */* shows that the only place in GDC where it's ever used
 is critsecsize.
 If you grep for isWindows you'll see that these checks are DMD-only and
 GDC already avoids them. (isWindows affects extern(System) but that's
 fine). It's similar for in the other cases.


I thought I might just also add that it is a mid to long term goal to
remove isLinux and friends out of the dfrontend and into target.c in
upstream dmd.  When this is ready, then we can pull all use setting/getting
isLinux and friends out of GDC.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 09 2014
prev sibling parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 8 March 2014 at 09:12:49 UTC, Mike wrote:

 On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:

 Why do you need synchronized? Are you building some kind of 
 multithreading library?


 I don't need it yet.  I'm just exploring features of D and 
 trying to learn how to implement them.  The real problem isn't 
 that I can't use synchronized, but rather that the compiler is 
 not aware of my target.  I haven't searched through GDC's 
 source code yet, but I suspect there will be more problems in 
 the near future if the compiler is not taught about this target.

 Mike


Synchronized block tells to the thread scheduler to lock this 
piece of code for this thread. No other thread may enter this 
block while this thread is in it.
The compiler generates a library call that does the work. The 
thread scheduler is operating system dependent and not related to 
hardware.

Anyway, this is valid code and should pass. I have to remove all 
synchronized words when compiling the runtime. "Nothreads" 
directive might be useful, in this case it should just ignore the 
synchronized word.

When there is something os dependent, there should always be a 
nosystem block or default case which has reasonable default 
values or just empty variables/functions if they are not used. In 
D there is version(NoSystem).

In gcc build we know the host we are building and the target we 
are building for. There is only one operating system that the 
generated compiler supports. (or none like in arm-none-eabi) I 
think all operating system related in the compiler should be in 
compile time directives and have no runtime code for that. When 
we get the --with-cpu- etc statements work, we may tune the 
compiler even more.
Mar 08 2014
parent "Mike" <none none.com> writes:
On Saturday, 8 March 2014 at 10:33:30 UTC, Timo Sintonen wrote:

 In gcc build we know the host we are building and the target we 
 are building for.


Yeah! You are right.  GDC/GCC is somewhat unique in this regard, 
isn't it? critsecsize could just return a constant that's 
determined at GDC's compile time?

I guess the question is, "Where should OS features be 
implemented?".  In the language (i.e. the runtime), or in the 
compiler?  I think I'd prefer the runtime, but it's an 
interesting question.

Man, D is messing with my mind.


 There is only one operating system that the generated compiler 
 supports. (or none like in arm-none-eabi) I think all operating 
 system related in the compiler should be in compile time 
 directives and have no runtime code for that.


I pose another question to you, then.  If I build an OS with 
arm-none-eabi, do I then need to modify GDC/GCC to write programs 
for my OS?  I sure hope not.

I keep running into this catch 22 with D.  I'm trying to build an 
OS with D, but D requires an OS.  I'm still trying to figure out 
how to reconcile that.

It's an interesting conundrum.


 When we get the --with-cpu- etc statements work, we may tune 
 the compiler even more.


I didn't know they weren't working.  Please elaborate.

Mike
Mar 08 2014