View mode: basic / threaded / horizontal-split · Log in · Help
March 08
ICE due to unsupported target
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
March 08
Re: ICE due to unsupported target
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?
March 08
Re: ICE due to unsupported target
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
March 08
Re: ICE due to unsupported target
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.
March 08
Re: ICE due to unsupported target
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.
March 08
Re: ICE due to unsupported target
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
March 08
Re: ICE due to unsupported target
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.
March 08
Re: ICE due to unsupported target
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!
March 09
Re: ICE due to unsupported target
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';
Top | Discussion index | About this forum | D home