Re: Remove CRT (C's runtime) from betterC binaries?
There are other ways to do minimalist programming in D without -betterC. See https://dlang.org/changelog/2.079.0.html#minimal_runtime Well, what would be the difference between betterC and writing my own minimal runtime? For the time being doing betterC looks preferable, so I don't need to reimplement some runtime stuff. Just recompiling the same program with empty object module gives me few errors like size_t, string and etc not implemented in object module.
Re: Remove CRT (C's runtime) from betterC binaries?
printf() and exit() are part of the CRT. Well, yes, but there is implementation for them in msvcrt.dll, which is installed on all Windows platforms. So I can link to it and use it for free, without adding the whole CRT to my executable. Otherwise I could use MessageBox and ExitProcess for testing hello-world application, which reside in user32.dll and kernel32.dll respectively.
Re: Remove CRT (C's runtime) from betterC binaries?
On Tuesday, 14 August 2018 at 13:11:57 UTC, Rel wrote:
Can I or is it even possible to remove the CRT (C's runtime
library) completely from my executables compiled with betterC
flag?
Okey, it seems I figure out how to do it with MinGW linker:
import core.stdc.stdlib;
import core.stdc.stdio;
extern (C) void start() {
printf("Hello World!");
exit(0);
}
// dmd -c -m32mscoff -betterC -of=test32.obj test.d
// dmd -c -m64 -betterC -of=test64.obj test.d
// gcc -o test32.exe -m32 -nostdlib -s test32.obj -lmsvcrt
// gcc -o test64.exe -m64 -nostdlib -s test64.obj -lmsvcrt
Remove CRT (C's runtime) from betterC binaries?
Can I or is it even possible to remove the CRT (C's runtime library) completely from my executables compiled with betterC flag?
Re: Signed DMD binaries
Feedback is welcome ;-) The latest DMD installer seems not to be flaged by Kaspersky Antivirus, thanks!
Kaspersky Endpoint Security 10 flags the DMD installer as malicious!
To be exact as a "HEUR:Trojan-Downloader.Win32.Agent.gen". Few other AV software does the same: https://www.virustotal.com/#/file/0aa364c5cb90630a5757aacc0c3c05a2273f5fdb88e14e2b80d4c19ee5b16d10/detection I think, we should do something about it, at very least report for false-positive to Kaspersky or something.
Re: D vs nim
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. So what's a big deal in having 'static if' construct? Most of the new programming languages that compiles to native code like Nim, Crystal, Rust, Red and etc have good enough meta-programming support anyways.
Re: What stops DMD from cross-compiling?
On Friday, 27 April 2018 at 15:31:37 UTC, Jacob Carlborg wrote: DMD can cross-compile between 32-bit and 64-bit on the same platform. To targeting a different platform than the host the code in DMD needs to be reorganized a bit. When compiling the compiler it will only include support for targeting the same platform as you're compiling on. Currently it's using #ifdefs to decide which target should be supported. This occurs the compile time of the compiler. This needs to occur at runtime instead. It doesn't depend on anything expect for the standard C library so it should be fairly straight forward to fix. Well, that's a good news. That would work, but it requires a lot of effort. It's not only depending on the C standard library, it also depends on other system functionality that are not part of the kernel. For example, the thread local storage implementation depends on the platform. If we're only using the kernel that would be needed to be implemented as well. Something like memcpy and similar stuff is easy to implement. If we are talking about Linux stuff like open, malloc and etc can be implemented either by using syscalls or by generating the binding to the libc.so of some minimal version that we decide to support (like Pascal compiler do). If we are talking about Windows all of the needed functions can be reimplemented using API provided by kernel32.dll and friends. It's possible to use the libraries provided by the target platform when cross-compiling. I've done that with LDC and created two Dockerfiles, one targeting Windows [1] and one targeting macOS [2]. Note, the SDKs for macOS and Windows are downloaded from Dropbox accounts. Downloading some SDK's from dropbox accounts is the thing I'd like to avoid, I'd like the Dlang compiler to be a self-contained toolchain. This doesn't mean something, just a personal preference.
What stops DMD from cross-compiling?
So, okey, bare with me here. As I once told here before the only one thing I love about Golang is the ability to easily cross-compile code from any supported OS targeting any supported OS. So I was thinking what actually stops DMD from doing the same thing? DMD has own backends targeting X86 and x64 already, it seems to work well with LLD (at least for me) that was integrated not so long ago, and LLD has the ability to cross-link. So I'm not a compiler expert here, and I'm not familiar with the DMD code base, but from a user perspective the one huge showstopper for bringing the same level of cross-compilation to DMD like Golang has seems to be the dependency on C-library. As of 2.079 we can write code that is not dependent on the druntime and libc, so technically we can reimplement the needed parts of cruntime in D and make it the part of druntime itself. What do you think about it? Also we will need some libraries that would generate bindings from extern functions to actual OS library code, like for example kernel32.lib on Windows. The library doesn't have actual code, it just binds the symbol to the executable import table. Pascal programming language doesn't seem to have the same notion, when you declare extern function you just declare it with the actual library name (like kernel32.dll on windows) and the compiler generates the proper imports. Can the behavior like this be implemented for DMD? How we can solve this problem otherwise? And any other thought on the topic is welcomed, I like talking about compilers and stuff with some wise and experienced people. Thanks!
Re: D vs nim
In case you guys like to take a quick look at new emerging, but somewhat unknown systems programming languages: * https://www.red-lang.org/ (own handwritten backend) * https://crystal-lang.org/ (llvm-based backend) * https://ziglang.org/ (llvm-based backend) * http://nitlanguage.org/ (c-based backend?) * https://www.xojo.com/ (llvm-based backend)
Re: D vs nim
As for me, I find the Nim programming language interesting. However I dislike syntax a bit, in some cases Python+Pascal syntax style of Nim looks very ugly in my opinion. Also I strongly against relying on C compiler for code generation, knowing how slow it can be. Obviously it was easy for them to use C as a pure-text backend, but I think these days LLVM should be used instead.
Re: LDC 1.9.0 beta
On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote: * `-link-internally` able to (cross-)link Windows, Linux and macOS binaries. This is nice to hear, but just to make it clear, what steps do I need to take to for example build a Mac OSX binary on Windows or Linux? Can I just download libs from prebuilt LDC for Mac OSX, put them somewhere in my current LDC installation and it will work? I'm also waiting so much for LDC to be independent of MS Visual Studio libs, and ship MinGW libs with the installation or something. I thought you had some troubles getting LLVM to work with MinGW libs, is it still true?
Re: So what is the state of cross-compilation in D?
On Wednesday, 17 January 2018 at 12:31:35 UTC, Kagamin wrote: https://wiki.dlang.org/Build_D_for_Android https://wiki.dlang.org/Building_LDC_runtime_libraries https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412 As far as I understand I will need a C toolchain that allows cross-compilation to target OS in order to build runtime libraries, is it correct? Why is D's runtime library is written in C? I thought that D is pretty much capable to have runtime libraries written in D, especially after the introduction of -betterC flag. I'd like to cross-compile from Windows machine to Linux and Mac OSX. Where can I get C toolchain that will allow me to cross-compile D's runtime libraries from Windows to Linux and Mac OSX?
So what is the state of cross-compilation in D?
Well, to be completely honest with you the only one thing I like about the Go programming language is the ability to easily cross-compile your Go program from any supported OS to any supported OS. So I was wondering what is the story of cross-compilation for different D language compilers? Is it possible to some extent now? Do you guys have interest in it? Basically as far as I understood what makes Go suitable for cross-compilation is their own linker implementation, and D compilers use current system linker.
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote: I can answer #1, I know a few things there but that's more something he should talk about as I don't know how public he's made that knowledge. Well, I know that DMD in particular made a trade off not to collect garbage during the compilation to improve the speed, so it is really interesting to look at their compiler sources to find out what they did to make it compile so quickly. On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote: I also put forward to him a case with regards to compile time execution and code generation. Say you've got a global variable that you write to, and reading from that changes the kind of code you will generate. Thus, your outputted code can be entirely different according to whenever the compiler decides to schedule that function for execution and compilation. His response was, "Just don't do that." That's essentially the philosophical difference there. Jonathan wants a language with no restrictions, and leave it up to the programmer to solve problems like the above themselves. Whether you agree with that or not, well, that's an entirely different matter. At very least it is interesting to have this feature, I don't know if I ever will need it in my code. For the game development use case it may be useful, for example to package all of the game assets at compile time. I've seen similar thing being very popular in different Haxe-based game frameworks, though Haxe seems to be a bit more restrictive in this regard.
Jonathan Blow's presentation
What do you guys think of the points explained here: https://www.youtube.com/watch?v=gWv_vUgbmug Seems like the language shares a lot of features with D programming language. However there are several features that caught my interest: 1) The compile times seems very fast in comparison with other modern programming languages, I'm wondering how he managed to do it? 2) Compile-time execution is not limited, the build system is interestingly enough built into the language.
Re: So what about -betterC flag?
On Wednesday, 11 May 2016 at 06:49:51 UTC, Rel wrote: So... Has anything changed about the -betterC flag lately? It is now documented as a compiler flag, but there is no documentation on how to properly use it. Is it considered to be stable now or it is still a hack? What language features are forbidden when using this flag? Anyone?
Re: So what about -betterC flag?
So... Has anything changed about the -betterC flag lately? It is now documented as a compiler flag, but there is no documentation on how to properly use it. Is it considered to be stable now or it is still a hack? What language features are forbidden when using this flag?
Re: So what about -betterC flag?
On Saturday, 5 September 2015 at 14:32:39 UTC, Laeeth Isharc wrote: On Saturday, 5 September 2015 at 12:56:48 UTC, Adam D. Ruppe wrote: On Saturday, 5 September 2015 at 10:51:23 UTC, Rel wrote: I remember that there was some buzz around undocumented -betterC compiler flag that should allow people get away from hard druntime dependencies and write bare metal code, drivers or kernel modules in some limited D subset. -betterC used to exist, not sure if it still does, but it does very little and I don't think it helps much; you're still basically on your own in making such code work right. switch still there. don't know what it does, if anything. https://github.com/D-Programming-Language/dmd/search?utf8=%E2%9C%93=betterC I see, it seems that all that flag does is prevent module info generation, I don't really know if it may be helpful or not in using D as a "better C" (without druntime). But thanks!
So what about -betterC flag?
I remember that there was some buzz around undocumented -betterC compiler flag that should allow people get away from hard druntime dependencies and write bare metal code, drivers or kernel modules in some limited D subset. Could you make some comments about it. Does it exists and is it practical thing to do? What limitations does it require for your code? Is anyone using it right now and in what context? Thanks!
Re: D as A Better C?
On Wednesday, 19 February 2014 at 15:46:38 UTC, Tim Krimm wrote: On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote: On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: The subset would disallow use of any features that rely on: 1. moduleinfo 2. exception handling 3. gc 4. Object I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos. What do you think? So may I ask, what is official decision on the subject? Quite a lot of people were begging for it for a long time. Obviously I'd like to have this feature in D because it would finally allow game, embedded, system (and operating system) developers to use good, modern and beautiful language for their needs. As for me I've been waiting for this for a long time. Hacking on compiler and phobos in order to make it generate stdlib-indepentent code may be interesting from time to time, but keeping such kind of project up-to-date with each new version of the compiler can be quite hard. Supporting a subset of D language features suitable for system/embedded programming and porting seems to be the best decision in this case. I have also been waiting for something like this for a long time. Well in my opinion the language should be started with a fixed number of features, that are not dependent on runtime, then improve the language by adding features supported by runtime library. Too bad that D doesn't officially support a subset without runtime depemdencies, so we have to either use C/C++ or keep on trying to hack on of D compilers. On the other hand Rust can be used without runtime libraries.
Re: Bounty for -minimal compiler flag
So? Is anyone working on these features?
Re: D as A Better C?
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: The subset would disallow use of any features that rely on: 1. moduleinfo 2. exception handling 3. gc 4. Object I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos. What do you think? So may I ask, what is official decision on the subject? Quite a lot of people were begging for it for a long time. Obviously I'd like to have this feature in D because it would finally allow game, embedded, system (and operating system) developers to use good, modern and beautiful language for their needs. As for me I've been waiting for this for a long time. Hacking on compiler and phobos in order to make it generate stdlib-indepentent code may be interesting from time to time, but keeping such kind of project up-to-date with each new version of the compiler can be quite hard. Supporting a subset of D language features suitable for system/embedded programming and porting seems to be the best decision in this case.
Re: D: pay for what you use?
On Thursday, 13 February 2014 at 21:08:01 UTC, Mike wrote: [1] https://github.com/ldc-developers/ldc/issues/551 [2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.0-Introduction [3] http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22 [4] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World! (watch the ending '!') [5] http://wiki.dlang.org/Runtime_Hooks [6] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d [7] http://forum.dlang.org/post/jynxfglpulguvqbiv...@forum.dlang.org [8] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/master/source/memory.d [9] https://bitbucket.org/timosi/minlibd [10] https://github.com/CyberShadow/SlimD [11] http://arsdnet.net/dcode/minimal.zip [12] https://github.com/yebblies/dmd/tree/microd [13] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study [14] https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d Oh, that's a huge list, I'll take a look at it, thanks for your answer!
Re: D: pay for what you use?
On Thursday, 13 February 2014 at 19:03:14 UTC, Martin Nowak wrote: It already is, though it might not be fully implemented yet. Try 'dmd -betterC'. So you mean the latest DMD release already has it?
D: pay for what you use?
Hello! I really enjoy D and some brilliant concepts in the language, like scope(exit) for example. But what I dislike about D is the druntime, where each single function depends on 100 other functions. I'd like to be able to develop system level code in D (like windows drivers or linux kernel modules or do osdev), but I can not do it, as D is very dependent on the druntime. It would be great if D would have the same pay for what you use way, as C/C++ do. So I'd like to ask several questions: 1) Is it possible to fully disable exceptions? Generally I tend not to use exceptions in C++ as well, as exception path may take a whole lot of a time. Also returning error codes or using something like ExpectedT is more readable in most cases. Obviously I'm not going to use exceptions in my code, and I won't be linking with code that throws/catches exceptions. 2) Is it possible to fully disable runtime type information? I understand that being able to get different information about object type in the runtime may be very useful, but I've never used it. However D compilers do generate RTTI-tables no matter what with all class names, module names and etc. 3) Is it possible to fully disable garbage collection? Sometimes having GC is a good thing, but I'd rather do manual memory management or use automatic reference counting instead. 4) What compiler is better to use when I want to compile and run D on bare bones (running code without operating system)? Is it DMD? Or is it LDC? Or GDC? 5) Does anyone try to make a tiny druntime library? Did it work out well for you? And can I have a look at it? PS I know that these kind of questions come out in the D community from time to time, but there's a lot of things I'd like to discuss on this subject, so I decided to make a new thread... sorry...
Re: D as A Better C?
On Thursday, 13 February 2014 at 18:07:00 UTC, inout wrote: -no-moduleinfo -no-exceptions -no-gc -no-object There is absolutely NO need to give any name to that beast. Otherwise, it's an excellent idea! You could still use classes e.g. with C++ linkage. I've been waiting for these features in D for such a long time! I really hope that finally it will be possible to use D for osdev, embedded programming, drivers, kernel modules, high performant games and etc without struggling with druntime and phobos!
Re: D: pay for what you use?
On Thursday, 13 February 2014 at 17:14:05 UTC, Adam D. Ruppe wrote: Don't implement _d_throw in druntime and they won't link. I'm pretty sure the tables are still generated but they won't be used (and are pretty small anyway. Maybe I'm too pedantic about my code, but I don't want to have useless tables in data sections. Sadly on practice this stuff isn't cut off by optimizations. http://arsdnet.net/dcode/minimal.zip That's one with exception support (you can remove that sort of with a -version switch but i like exceptions), classes, and much the rest of the language but only comes out to ~30 KB executable, zero outside dependencies (see also Makefile.bare that can make a bare metal image bootable with grub). It might not compile with the newest dmd, I'm not sure since I haven't kept up with the changes over the last several months. Ripping out druntime and doing it all yourself is liable to break without warning. An independent try at doing the same thing is here: https://bitbucket.org/timosi/minlibd I haven't used it myself though. Thanks, I will look at it. But I agree that in general it may be hard to keep your own minimal runtime library up to date with the latest compiler version. That is a bad thing about it too...
Re: D: pay for what you use?
On Thursday, 13 February 2014 at 17:15:06 UTC, Gary Willoughby wrote: It's a good job i don't believe in conspiracies. http://forum.dlang.org/thread/lddug4$jgv$1...@digitalmars.com Oh, that is funny! I didn't notice that topic, as I haven't been much into D community. Thanks for pointing it out! I really hope that these features will be included in D compiler eventually...
