DMD as cross-compiler

Denis Feklushkin feklushkin.denis at gmail.com
Sun Nov 15 08:12:01 UTC 2020


On Sunday, 15 November 2020 at 07:51:52 UTC, Paulo Pinto wrote:
> On Sunday, 15 November 2020 at 07:21:28 UTC, Denis Feklushkin 
> wrote:
>> [...]
>>
>> Really, libc is not (only) C library, but de-facto standard 
>> for accessing to OS syscalls. It is possible to drop it but it 
>> doesn't make any sense, it just adds extra work to maintain a 
>> huge compatibility layer for all supported OSes.
>>
>> I once thought differently, but recently delved deeper into 
>> druntime and looked how it works. In total, I think, there are 
>> about ~15 calls to libc, not so many.
>
> Only for the OSes where C was born on, UNIX and POSIX clones.
>
> There are still several platforms around where this is not the 
> case, because their main systems programming language isn't C, 
> e.g. IBM and Unisys mainframes.
>
> Embedded platforms that use their own toolchains without any 
> kind of POSIX compatibility.
>
> And desktop OSes like Windows, which follows the tradition of C 
> and C++ compilers outside the UNIX world, where each compiler 
> vendor ships their own ISO compliant library, and the OS 
> syscalls are completly unrelated, e.g. ZeroMemory() instead of 
> memset(). Amiga, Atari, OS/2, BeOS, Symbian, Brew, Mac OS pre 
> OS X, Newton, PalmOS, are all examples of this tradition.

Agree. Also threads are not part of the libc, but Posix: if 3-rd 
party libc provides C standard functions it does not necessarily 
provides pthread interface.

In this regard, I want to propose related idea to move this 
dependent from libc and threads and etc parts into a separate 
druntime package ("backend") so that those who wish can 
themselves implement  interfaces to these or another more 
appropriate OS calls.

Something like:
https://github.com/denizzzka/druntime/blob/non_posix/src/core/thread/osthread.d#L217
===>
https://github.com/denizzzka/d_c_arm_test/blob/master/d/freertos_druntime_backend/external/core/thread.d#L396

but without all these "version (DruntimeAbstractRt)" branches.

This will simplify druntime main code (get rid of many versions 
branches inside of the druntime) and make it possible to easily 
implement support for various not common operating systems such 
as HaikuOS or druntime for bare-metal.


More information about the Digitalmars-d mailing list