www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Being reading a lot about betterC, but still have some questions

reply kiboshimo <matheusmvpeixoto gmail.com> writes:
Hi,

Some stuff must look obvious to an experienced programmer so they 
are not explicit on articles and documentation over the internet. 
I'm somewhat inexperienced, so:

- betterC does not need glue code to interop with C. Does it 
achieve this by "gluing" behind the scenes? I've read in a 
comment somewhere that the ABI is the same, but idk people say 
lots of things.

- betterC cannot be used with some parts of phobos. Should I 
worry I won't be able to use essential stuff for systems 
programming? Things like atomics.
// If that is the case, can I supplant these low-level stuff with 
an equivalent C library? (I don't think so, but I'm hopefull).

- betterC can be compiled to WASM, but some of phobos can't, so 
basically same worries as above. I'm afraid to lose some 
essential systems stuff that I could not replace.

I'm going to try a project with raylib and WASM. Really liked the 
idea of doing it with betterC to start my systems programming 
journey (tough start, don't care, just fill me in if you want to).

Thanks :)
Jul 09
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:

 Hi,

 Some stuff must look obvious to an experienced programmer so 
 they are not explicit on articles and documentation over the 
 internet. I'm somewhat inexperienced, so:

 - betterC does not need glue code to interop with C. Does it 
 achieve this by "gluing" behind the scenes? I've read in a 
 comment somewhere that the ABI is the same, but idk people say 
 lots of things.

 - betterC cannot be used with some parts of phobos. Should I 
 worry I won't be able to use essential stuff for systems 
 programming? Things like atomics.
 // If that is the case, can I supplant these low-level stuff 
 with an equivalent C library? (I don't think so, but I'm 
 hopefull).

 - betterC can be compiled to WASM, but some of phobos can't, so 
 basically same worries as above. I'm afraid to lose some 
 essential systems stuff that I could not replace.

 I'm going to try a project with raylib and WASM. Really liked 
 the idea of doing it with betterC to start my systems 
 programming journey (tough start, don't care, just fill me in 
 if you want to).

 Thanks :)


betterC is just a reduced D subset that was intended to help 
porting C code over to D to an unsupported platforms where the 
full D runtime (provides GC and other advanced language features) 
is not yet implemented or not feasible (like microcontrollers, 
although D is not very friendly to 8-bit hardware).

Because it turns off many advanced features it means there is no 
GC and runtime type information(RTTI), many of the phobos 
functions relies on these features.

All this makes it very advanced feature not intended for mass 
users.

- Don't confuse it with extern(C) linkage too, extern(C) is what 
makes it compatible with C ABI.
- Don't confuse it with an importC feature.

- It is not betterC to blame for lacking standard library support 
but because phobos is not implemented for it, of course you can 
do it yourself if you really wanted to but certain D concepts 
(like ranges) will be much harder to do without GC support.

- You can't have regular D classes (extern(D)) in betterC as they 
rely on RTTI, however you can have extern(C++) classes.

- If your C/C++ library provides atomics, you can do this, but 
probably you can use some of the phobos as this is pretty low 
level stuff.

---

What it is:
- reduced language subset to allow "easier" targeting to very 
modest hardware or other unsupported systems
- it makes the compiler emits errors if you accidentally use some 
of full D features

What it is NOT:
- it is not a C compiler
- it won't accept your C files as if it is D
- it won't just magically port C code for you
Jul 09
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/07/2024 8:43 PM, evilrat wrote:

 - If your C/C++ library provides atomics, you can do this, but probably 
 you can use some of the phobos as this is pretty low level stuff.


Atomics are provided by the compiler in the form of intrinsics.

If you do not do this, they cannot be inlined as you're forced to use 
inline assembly.

LDC and GDC like GCC and clang have an intrinsic based implementation 
for ``core.atomics``. DMD is the only D compiler that uses inline 
assembly currently.

It is all templated so yes it is accessible within a -betterC codebase.
Jul 09
parent reply kiboshimo <matheusmvpeixoto gmail.com> writes:
Thank you for the comprehensive responses

On 09/07/2024 8:43 PM, Richard (Rikki) Andrew Cattermole wrote:

 Atomics are provided by the compiler in the form of intrinsics.

 If you do not do this, they cannot be inlined as you're forced 
 to use inline assembly.

 LDC and GDC like GCC and clang have an intrinsic based 
 implementation for ``core.atomics``. DMD is the only D compiler 
 that uses inline assembly currently.

 It is all templated so yes it is accessible within a -betterC 
 codebase.


That is good to know. I should expect this kind of feature to be 
present, after all betterC must be a working subset of D. But, I 
wasn't sure enough.

Based on the responses I'm assuming my example of atomic is a 
special case, but I shouldn't worry about low level things like 
threads to be absent all the same.

That's betterC targeting native. What about WASM? Does LDC -> 
WASM pipeline supports functionality one needs in a C-level 
language? If not, aside from atomics, one should be able to use C 
libraries to supplant any other purpose, right? Since C has 
mature support for WASM.
Jul 09
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/07/2024 9:27 PM, kiboshimo wrote:

 Based on the responses I'm assuming my example of atomic is a special 
 case, but I shouldn't worry about low level things like threads to be 
 absent all the same.


Threads are indeed gone.

That is library code in druntime that needs to be linked in along with 
the GC.

If you want them, you'll have to call out to the system API and do your 
own thing.


 That's betterC targeting native. What about WASM? Does LDC -> WASM 
 pipeline supports functionality one needs in a C-level language? If not, 
 aside from atomics, one should be able to use C libraries to supplant 
 any other purpose, right? Since C has mature support for WASM.


I cannot comment about web assembly since I haven't done anything there, 
but some people have so hopefully they'll comment about where to go from 
here.
Jul 09
parent reply kiboshimo <matheusmvpeixoto gmail.com> writes:
On Tuesday, 9 July 2024 at 09:30:18 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 Threads are indeed gone.


Oh no.


If you want them, you'll have to call out to the system API and 
do your own thing.


I hope "doing my own thing here" could be linking to a C library 
that interacts with the OS on my behalf.


 I cannot comment about web assembly since I haven't done
 anything there, but some people have so hopefully they'll
 comment about where to go from here.


Some of them might know. And if they know, them I will know. And 
if I know, then, you know...
Jul 09
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 09/07/2024 9:58 PM, kiboshimo wrote:

 On Tuesday, 9 July 2024 at 09:30:18 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 Threads are indeed gone.


 
 Oh no.
 

 If you want them, you'll have to call out to the system API and do 
 your own thing.


 
 I hope "doing my own thing here" could be linking to a C library that 
 interacts with the OS on my behalf.


If you don't need to interact with an existing thread abstraction such 
as druntime, working with pthreads or Windows threading abstraction 
isn't an issue.

These API's are pretty easy to interact with, I've got my own -betterC 
threading abstraction (I have good reasons not to recommend it here).


 I cannot comment about web assembly since I haven't done
 anything there, but some people have so hopefully they'll
 comment about where to go from here.


 
 Some of them might know. And if they know, them I will know. And if I 
 know, then, you know...


Oh I've seen them do stuff with it, its just not something I've wanted 
to learn, I have a lot of other stuff before it.
Jul 09
prev sibling parent reply Sergey <kornburn yandex.ru> writes:
On Tuesday, 9 July 2024 at 09:27:30 UTC, kiboshimo wrote:

 That's betterC targeting native. What about WASM? Does LDC -> 
 WASM pipeline supports functionality one needs in a C-level 
 language? If not, aside from atomics, one should be able to use 
 C libraries to supplant any other purpose, right? Since C has 
 mature support for WASM.


Feel free to join our Discord chat.
Some info is saved there. Also many active authors of D libraries 
(including related to the betterC and WASM) are there as well
Jul 09
parent kiboshimo <matheusmvpeixoto gmail.com> writes:
On Tuesday, 9 July 2024 at 09:42:01 UTC, Sergey wrote:

 Feel free to join our Discord chat.
 Some info is saved there. Also many active authors of D 
 libraries (including related to the betterC and WASM) are there 
 as well


Already did, will try the search bar later. Sun is rising over 
here and I've not slept yet. Thank you :)
Jul 09
prev sibling next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:

If you haven't done so, I'd recommend reading the blog posts from 
Walter to get an understanding of why BetterC was introduced and 
how to use it: https://dlang.org/blog/category/betterc/


 - betterC does not need glue code to interop with C. Does it 
 achieve this by "gluing" behind the scenes? I've read in a 
 comment somewhere that the ABI is the same, but idk people say 
 lots of things.


You're declaring your D code extern(C), as you can see in 
Walter's blog posts, so yes, you're using the C ABI.
Jul 09
parent kiboshimo <matheusmvpeixoto gmail.com> writes:
On Tuesday, 9 July 2024 at 14:38:34 UTC, Lance Bachmeier wrote:

 If you haven't done so, I'd recommend reading the blog posts 
 from Walter to get an understanding of why BetterC was 
 introduced and how to use it: 
 https://dlang.org/blog/category/betterc/


 - betterC does not need glue code to interop with C. Does it 
 achieve this by "gluing" behind the scenes? I've read in a 
 comment somewhere that the ABI is the same, but idk people say 
 lots of things.


 You're declaring your D code extern(C), as you can see in 
 Walter's blog posts, so yes, you're using the C ABI.


The blog post contextualizes evilrat's comment too. It facilities 
code migration because conversion is also easier (given adequate 
attention to C's quirks). After that you can start using D 
features on top of converted code. That won't help much on my 
Wasm use case, but it might, now that I know more about the ABI 
thing.

Thank you.
Jul 09
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:

 I'm going to try a project with raylib and WASM.


use mine

https://github.com/crazymonkyyy/raylib-2024/blob/master/docs/examplecode.md


 - betterC can be compiled to WASM, but some of phobos can't, so 
 basically same worries as above. I'm afraid to lose some 
 essential systems stuff that I could not replace.


yes, and your not afraid enough


 Really liked the idea of doing it with betterC to start my 
 systems programming journey


Theres nothing even slightly pleasant or easy about d's wasm 
"support"; I wrote my own cos, sqrt functions, you get *nothing* 
from phoboes
Jul 09
parent reply kiboshimo <matheusmvpeixoto gmail.com> writes:
On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:

 On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:

 - betterC can be compiled to WASM, but some of phobos can't, 
 so basically same worries as above. I'm afraid to lose some 
 essential systems stuff that I could not replace.


 yes, and your not afraid enough


 Really liked the idea of doing it with betterC to start my 
 systems programming journey


 Theres nothing even slightly pleasant or easy about d's wasm 
 "support"; I wrote my own cos, sqrt functions, you get 
 *nothing* from phoboes


Writing my own math functions is outside of my range, I still 
have hopes of this not being so hard. So you get another 
opportunity to crush it.

You could have used a C library for those things you implemented 
yourself, right? I suppose you didn't because doing things is 
cool, or because C is "not ergonomic" to use as foreign code. 
Because of the quirks. Which would make for a not so pleasant 
experience when writing a small game.

What do you think about using C libraries like that?
Jul 09
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Jul 09, 2024 at 08:03:15PM +0000, kiboshimo via Digitalmars-d-learn
wrote:

 On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:

 On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:




[...]

 Really liked the idea of doing it with betterC to start my systems
 programming journey


 
 Theres nothing even slightly pleasant or easy about d's wasm
 "support"; I wrote my own cos, sqrt functions, you get *nothing*
 from phoboes


 
 Writing my own math functions is outside of my range, I still have
 hopes of this not being so hard. So you get another opportunity to
 crush it.


[...]

What are you planning to run your wasm on?  If in the browser, you could
just use the browser's JS math functions.  The performance won't be
stellar (the wasm-JS boundary is SLOW), but it'd work and you wouldn't
have to write your own math functions.  This is what I use in my own
D/wasm project.  (It'd probably still beat any hand-written WASM
reimplementation of math functions that you write.  Remember, wasm is
interpreted, so it won't beat the browser's built-in native math
functions, which in all likelihood use the CPU's hardware math
instructions.)

If you're planning to run your wasm in a native environment, you could
probably just use the C API to interface with the host system's C
library functions.

Don't reinvent the square wheel unless you're planning to ride it on an
inverted catenary road. :-P

//

On a larger note, if you're planning to write something small that runs
in a browser, you might be interested to check out:

	https://github.com/Ace17/dscripten

This is the D equivalent of emscripten. While it's nowhere near the
maturity of emscripten itself, it may be Good Enough(tm) for your use.
Rather than wrangling with the WASM/JS API (it's still early stage,
there are a LOT of bumps currently still in the road), just let LLVM
convert your D code straight into JS and run it as JS in the browser.
Then you can leverage all the existing JS APIs your browser already
supports, instead of having to reinvent yet another square wheel.


T

-- 
Some days you win; most days you lose.
Jul 09
parent reply kiboshimo <matheusmvpeixoto gmail.com> writes:
On Tuesday, 9 July 2024 at 20:24:14 UTC, H. S. Teoh wrote:

 What are you planning to run your wasm on?  If in the browser, 
 you could just use the browser's JS math functions.  The 
 performance won't be stellar (the wasm-JS boundary is SLOW), 
 but it'd work and you wouldn't have to write your own math 
 functions.  This is what I use in my own D/wasm project.  (It'd 
 probably still beat any hand-written WASM reimplementation of 
 math functions that you write.  Remember, wasm is interpreted, 
 so it won't beat the browser's built-in native math functions, 
 which in all likelihood use the CPU's hardware math 
 instructions.)


This cleared up some fundamental misunderstandings I had, thank 
you. I want to use raylib and betterC to build a small game that 
runs on the browser. For motivation I though Wasm had many 
advantages over Js, but now I don't know if that is necessarily 
the case.


 If you're planning to run your wasm in a native environment, 
 you could probably just use the C API to interface with the 
 host system's C library functions.


That covers native use-case. In the browser I can compile my 
programs to .js using emscripten/dscripten or I can just use JS 
API from WASM (but that is slow).

I though emscripten could target WASM directly, without 
conversion to .js first. And, since it supports C, I'm assuming 
they re-implemented C API to the OS on WASM, without the need for 
calling JS API or WASI. (that might not serve me still, see 
bellow)

I feel some fundamental misunderstanding remain, but now I have 
more material to research on my own, so feel free to ignore this 
if it is "too wrong".

- I though one could write an application with -betterC for WASM, 
because LDC can target it, then could build it linking to C 
libraries that already work on WASM and run the resulting build 
on the browser. That would avoid the JS-WASM bondary since 
everything would be WASM and I would not need to write my own 
abstractions.
// I'm guessing one can't simply do that, and the toolchain that 
compiles to WASM is not so flexible/similar to compiling a normal 
binary. Maybe WASM does not have support for dynamic linking, for 
example.

- Is WASI relevant to the browser context? Or just to native 
apps? I though WASI API could be used on the browser, but 
comments and blogs about it often bring up the native context 
only.

I tried to reply everyone here, since I think most answers 
converge. Thank you all for your help :)
Jul 09
parent reply kiboshimo <matheusmvpeixoto gmail.com> writes:
On Wednesday, 10 July 2024 at 01:48:54 UTC, kiboshimo wrote:

 - I though one could write an application with -betterC for 
 WASM, because LDC can target it, then could build it linking to 
 C libraries that already work on WASM and run the resulting 
 build on the browser. That would avoid the JS-WASM bondary 
 since everything would be WASM and I would not need to write my 
 own abstractions.
 // I'm guessing one can't simply do that, and the toolchain 
 that compiles to WASM is not so flexible/similar to compiling a 
 normal binary. Maybe WASM does not have support for dynamic 
 linking, for example.


I was able to generate a .wasm file from hello_world.d (main) and 
hello_lib.c using LDC for compilation to bytecode, then to 
webassembly with emscripten. So, in theory it works, just 
couldn't test it yet since I'm learning Web APIs and nodejs.

It would take sometime for me to figure how to print to 
javascript console from a generated .html file from emscripten, 
this is a small update so nobody gets too caught up that quote.
Jul 10
parent kiboshimo <matheusmvpeixoto gmail.com> writes:
On Wednesday, 10 July 2024 at 08:26:56 UTC, kiboshimo wrote:

 It would take sometime for me to figure how to print to 
 javascript console from a generated .html file from emscripten, 
 this is a small update so nobody gets too caught up that quote.


Got it printing quicker than I thought (node and browser with 
localhost). So stdio works. Any reason why other libraries 
wouldn't?

Just archiving this progress here for anyone reading, but won't 
pollute the forum further if this thread dies out. I'm very 
grateful for the help, would have lost a lot of time without the 
reference frame you guys gave me :)
Jul 10
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 9 July 2024 at 20:03:15 UTC, kiboshimo wrote:

 On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:

 On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:

 - betterC can be compiled to WASM, but some of phobos can't, 
 so basically same worries as above. I'm afraid to lose some 
 essential systems stuff that I could not replace.


 yes, and your not afraid enough


 Really liked the idea of doing it with betterC to start my 
 systems programming journey


 Theres nothing even slightly pleasant or easy about d's wasm 
 "support"; I wrote my own cos, sqrt functions, you get 
 *nothing* from phoboes


 Writing my own math functions is outside of my range, I still 
 have hopes of this not being so hard. So you get another 
 opportunity to crush it.


Honestly porting isqrt is easier then trying to get a half baked 
file io to work

but it is *everything* is gone and thats probaly overwhelming 
unless your prepared for it.


 You could have used a C library for those things you 
 implemented yourself, right? I suppose you didn't because doing 
 things is cool, or because C is "not ergonomic" to use as 
 foreign code. Because of the quirks. Which would make for a not 
 so pleasant experience when writing a small game.

 What do you think about using C libraries like that?


wasm *in general* breaks libc's fileio "for safety" (arguably the 
most important part of libc, morons), d's wasm libc in even more 
broken due to it coming out of no where and there being like 3 
guys doing 20 ours of work on the "runtime" or something(ignore 
ppl who say d supports 7 platforms, it supports 2).

While it can be a trivial port, I think you better off sticking 
to the raylib api as your ground layer as whatever work there 
seems to carry over.
Jul 09