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

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?

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

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.

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.

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

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.

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!

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';