DMD Compiler as a Library: A Call to Arms
dlang.org
dlang.org
This is kind of like a blind man clapping to echolocate his way around a maze. It's better than nothing but the issue is that the compiler just isn't amenable to non-batch work (e.g. the semantic analysis is all or nothing, it uses WAY too much memory[0], and it can't serialize it's state to the disk).
You could already use the frontend as a library, almost no one does. It's not because the API.
[0] SDC can pack a lot of types into a few bytes. This is the kind of thing real refactoring allows — this change (packing types, to be specific) is something I would happily chip in and help out with.
Memory layout and locality is where performance lies in a compiler (that and doing less work).
Being able to serialise is good and valuable and useful, and enables some very interesting things, but you can still do a lot of useful things with just a persistent process working on in-memory structures.
Asymptotics do always win but consider but consider the price of the win i.e. bitpacking is cheap (and fun) — not even just an academic exercise, this is where you get to use your hard won intuition.
And my initial post did mention doing too much work in the first place.
#!/usr/bin/env rdmd
import std.stdio;
void main()
{
writeln("Hello, world with automated script running!");
}
> ./myprog.d
Hello, world with automated script running!
https://dlang.org/rdmd.html1. Statically linked executables (essential but not crucial)
2. Dependency management (import tripleo.rtfm from "git:...#1234567")
3. A good AST API (jdt/roaster, javapoet, etc)
4. Tooling (cf spoon/soot)
(I approve this comment, even given it's limited usefulness/expressivity)
Not built into the compiler, but Dub, the official package manager distributed with the compiler, should be what I think your concise statement is referring to.
2. no
3. that's what this topic is about
4. yes
You dont care if in the AST some functions are doing too much. In my opinion the most important is the ability to _drive the compilation_, for example stop after lexical, stop after semantics. Then if too much code got compiled into the *.a that's unfortunate but not dramatic.
BTW there's is also the split between the driver and the frontend, but I think this is done.
But it's taking A LONG TIME to become usable.
What warnings are you seeing? What operating system?
I did it on my Winows 10 machine, it's kinda too late to start it up now and run it but I'll do it tomorrow and post both the code and the error message.
Update: I did this quickly on my MBP.
Code: #include <stdio.h> #include <stdlib.h>
int main() { puts("Hello, world!"); return EXIT_SUCCESS; }
Command: dmd test.c
Error: ld: address=0x0 points to section(2) with no content in '/Users/james/.asdf/installs/dmd/2.107.0/dmd2/osx/lib/libphobos2.a[3233](config_a98_4c3.o)' clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1
I think windows threw a similar error.
https://github.com/dlang/dmd/actions/runs/8023469412/job/219...
#include <stdio.h>
#include <stdlib.h>
int main()
{
puts("Hello, world");
return EXIT_SUCCESS;
}
with the following command:
dmd main.c
gives the following error:
main.c(1): Error: C preprocessor directive `#include` is not supported
main.c(1): Error: no type for declarator before `#`
main.c(2): Error: C preprocessor directive `#include` is not supported
main.c(7): Error: no type for declarator before `return`
main.c(8): Error: no type for declarator before `}`
Running the c code using docker just says that it cannot process c extensions.
docker run --rm -it -v .:/src dlanguage/dmd dmd main.c
The solution was that I had to install Visual studio and add the workload (plugin?) "Desktop development with c++".
The only thing needed to be checked was "MSVC v143" and "Windows 11 SDK", the rest is bloat.
After that I had to put the following path from Visual studio "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\Hostx64\x64" into my PATH.
This is because I needed the "cl.exe", "sal.h" and probably a couple of other files to be available to dmd.
(Also, the outdated version of dmd was another factor of the issue)
Finally, the compilation with main.c went smoothly. I had no idea the compiler needed external tooling, I thought it was self sufficient.
It used to be self-sufficient. But, we had to give up on our linker because we didn't have the staff to keep a linker up to date, and decided to stop chasing windmills and just use what was available. ImportC, in order to work, needs a preprocessor. We do have our own Standard compliant preprocessor, but it had a major problem. All the C preprocessors predefine a ton of macros (cpp predefines up to 400 macros). Different combinations of compiler switches turn on or off those predefines in poorly and usually undocumented ways. It differs from preprocessor to preprocessor, and was a hopeless nightmare.
So, ImportC uses the C preprocessor of the associated C compiler, and that works like a champ. The downside is you'll need to have that preprocessor installed and on the path.
The burden to maintain such a preprocessor doesn’t seem that rewarding compared to using existing ones.
For an analogy, if you walk to work every day instead of driving, you are accomplishing something useful beyond just the exercising.
My dad always tried to get a residence that was about a 15 min walk to work.
You don't say. Appalling, even!
Looked interesting.
[0]https://discourse.llvm.org/t/lld-status-update-and-performan...
[1]https://discourse.llvm.org/t/rfc-revisiting-lld-as-a-library...