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
next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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
prev sibling next sibling parent 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
prev sibling next sibling 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:
--001a11c3a9840eb49b04f42b1ae4
Content-Type: text/plain; charset=ISO-8859-1

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'; --001a11c3a9840eb49b04f42b1ae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Mar 8, 2014 9:40 AM, &quot;Johannes Pfau&quot; &lt;<a href=3D"mailto:nos= pam example.com">nospam example.com</a>&gt; wrote:<br> &gt;<br> &gt; Am Sat, 08 Mar 2014 09:12:48 +0000<br> &gt; schrieb &quot;Mike&quot; &lt;<a href=3D"mailto:none none.com">none non= e.com</a>&gt;:<br> &gt;<br> &gt; &gt; On Saturday, 8 March 2014 at 08:09:29 UTC, Timo Sintonen wrote:<b= r> &gt; &gt; &gt;<br> &gt; &gt; &gt; Why do you need synchronized? Are you building some kind of<= br> &gt; &gt; &gt; multithreading library?<br> &gt; &gt;<br> &gt; &gt; I don&#39;t need it yet. =A0I&#39;m just exploring features of D = and trying<br> &gt; &gt; to learn how to implement them. =A0The real problem isn&#39;t tha= t I<br> &gt; &gt; can&#39;t use synchronized, but rather that the compiler is not a= ware<br> &gt; &gt; of my target. =A0I haven&#39;t searched through GDC&#39;s source = code yet,<br> &gt; &gt; but I suspect there will be more problems in the near future if<b= r> &gt; &gt; the compiler is not taught about this target.<br> &gt; &gt;<br> &gt; &gt; Mike<br> &gt; &gt;<br> &gt;<br> &gt; critsecsize looks like a perfect example for configuration parameters<= br> &gt; which should be provided by the runtime.<br> &gt;<br> &gt; I&#39;m thinking of a core/config.d module which can be read by the<br=

&gt; ------------<br> &gt; enum critsecsize =3D 4;<br> &gt; enum hasGC =3D true;<br> &gt; enum hasAArray =3D true;<br> &gt; enum hasUnicodeLoops =3D true;<br> &gt; enum hasExceptions =3D true;<br> &gt; enum ...<br> &gt; ------------<br> &gt;<br> &gt; I wouldn&#39;t be too worried about &#39;isLinux&#39; in general. Iain= moved many<br> &gt; of these checks out of the frontend IIRC and rewrote them as checks<br=

u<br> &gt; want to know the critsecsize/used ABI/...<br> &gt;<br> &gt; grep isLinux */* shows that the only place in GDC where it&#39;s ever = used<br> &gt; is critsecsize.<br> &gt; If you grep for isWindows you&#39;ll see that these checks are DMD-onl= y and<br> &gt; GDC already avoids them. (isWindows affects extern(System) but that&#3= 9;s<br> &gt; fine). It&#39;s similar for in the other cases.<br> &gt;</p> <p>I thought I might just also add that it is a mid to long term goal to re= move isLinux and friends out of the dfrontend and into target.c in upstream= dmd.=A0 When this is ready, then we can pull all use setting/getting isLin= ux and friends out of GDC.</p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </p> --001a11c3a9840eb49b04f42b1ae4--
Mar 09 2014