Re: Release fluent-asserts 0.6.0
On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote: Hi, I just made a new release of fluent-asserts: http://fluentasserts.szabobogdan.com/ https://code.dlang.org/packages/fluent-asserts Since my last announcement I improved the library with: - better error messages - better exception api - integration with ranges - new asserts `executionTime` for callable and `containsOnly` for ranges - a new `Assert` utility for those who don't like the BDD style of writing asserts Any feedback is appreciated. Thanks, Bogdan Great job with this! I absolutely love it. It's made my tests less ugly that's for sure. Why this kind of library isn't already a part of D is beyond me.
Re: Beta 2.075.0-b1
On Tuesday, 4 July 2017 at 20:41:08 UTC, Martin Nowak wrote: On Tuesday, 27 June 2017 at 07:51:07 UTC, Dsby wrote: what about DIP1000? Is it default? We'd definitely mention such a big change in our changelog. At the moment scope support is still experimental with a couple of known issues (https://issues.dlang.org/buglist.cgi?quicksearch=%5Bscope%5D). Fixing those and adding safe unique, ref-counted, and weak-ref primitives to druntime/phobos is a major focus for the 2nd half of 2017. Will add in language : @ref @weak? is it DIP47? Or in library？
Re: Work on ARM backend for DMD started
On 7/4/2017 2:25 PM, Stefan Koch wrote: I am not sure how much of this really lends itself to be applied on arm. The code generator started out as 16 bits, and was that way for 10 years or so. x87 got added in later. Then it was adapted for 32 bits. Another 10 years went by, then 64 bits, and then XMM vector instructions. So I think it has proven itself to not be horribly locked in to one architecture. x86, x87, and XMM are quite different. There were also at one time back ends for the 68000 and the PowerPC that used the same optimizer and IR.
Re: Work on ARM backend for DMD started
On 7/4/2017 4:09 PM, Johan Engelen wrote:
On Tuesday, 4 July 2017 at 21:10:45 UTC, Walter Bright wrote:
The backend has also been accused of not doing data flow analysis. It does as
good a flow analysis as any compiler.
Please...
DMD: https://goo.gl/wHTPzz
GDC & LDC: https://godbolt.org/g/QFSgaX
With this PR:
https://github.com/dlang/dmd/pull/6968
The code:
int basicfunc(int i) {
return i;
}
int dataflow(int b) {
int ret;
if (b==4)
ret = 3;
else
ret = 5;
if (ret == 4)
return 0;
else
return 1;
}
Produces on Win32:
_D5test49basicfuncFiZi comdat
ret // this is not a bug, as `i` is passed in EAX
_D5test48dataflowFiZi comdat
mov EAX,1
ret
I'm sure you can find a case where LLVM does a better job. But I think I've made
the point :-)
Re: Work on ARM backend for DMD started
On 7/4/2017 2:25 PM, Stefan Koch wrote: At a first glance it looks highly x86 specific. The algorithm is not. The details are, of course, since if you read the Intel CPU manual there is an incredible amount of detail. I am not sure how much of this really lends itself to be applied on arm. The backend-IR does not seem to be able to express some ARM concepts such as predicated instructions. Predicated instructions are just a larger pattern to the code generator. I didn't see anything in the LLVM IR that is specific to it. While those maybe shoehorned in, it is likely to be impractical to reuse most of this code. The algorithm (which is not trivial) can be used. The rest is constructing the table of dependencies and special cases.
Re: Work on ARM backend for DMD started
On 7/4/2017 4:14 PM, H. S. Teoh via Digitalmars-d-announce wrote: Also, loop unrolling is only the beginning. Other loop optimizations are just as important, like strength reduction, hoisting, etc.. (Caveat: I haven't checked whether DMD specifically performs these optimizations. It does. But based on looking at previous dmd output, I'm leaning towards no.) I wish people would look at it before assuming. It's not like it's a secret. https://github.com/dlang/dmd/blob/master/src/ddmd/backend/gloop.c Read the comments.
Re: Work on ARM backend for DMD started
On Tue, Jul 04, 2017 at 02:10:45PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 7/4/2017 1:15 PM, Stefan Koch wrote: > > Most arm implementation are not as forgiving as contemporary x86 > > processors when it comes to bad register scheduling and the like. > > The backend's scheduler is actually very effective. It mattered with > the Pentium and Pentium Pro processors, but not anymore. But the code > is still there, and still works, and the algorithm is sound. > > https://github.com/dlang/dmd/blob/master/src/ddmd/backend/cgsched.c > > The backend has also been accused of not doing data flow analysis. It > does as good a flow analysis as any compiler. > > Where the backend has fallen behind are: > > 1. loop unrolling > 2. better inlining I'd argue these are most important for output code quality, because performance bottlenecks are usually found in loops, and inlining is a key component to enabling further reduction of loop complexity during loop optimization. Inlining is also critical in range-based code, which is fast becoming the de facto D coding style these days. Also, loop unrolling is only the beginning. Other loop optimizations are just as important, like strength reduction, hoisting, etc.. (Caveat: I haven't checked whether DMD specifically performs these optimizations. But based on looking at previous dmd output, I'm leaning towards no.) It would be nice if the dmd backend at least got a facelift in these areas, even if you didn't have the time to do a full-fledged backend update... > 3. SROA This may be important in optimizations of range-based code. T -- The trouble with TCP jokes is that it's like hearing the same joke over and over.
Re: Work on ARM backend for DMD started
On Tuesday, 4 July 2017 at 21:10:45 UTC, Walter Bright wrote: The backend has also been accused of not doing data flow analysis. It does as good a flow analysis as any compiler. Please... DMD: https://goo.gl/wHTPzz GDC & LDC: https://godbolt.org/g/QFSgaX -Johan
Re: Work on ARM backend for DMD started
On Tuesday, 4 July 2017 at 21:10:45 UTC, Walter Bright wrote: On 7/4/2017 1:15 PM, Stefan Koch wrote: Most arm implementation are not as forgiving as contemporary x86 processors when it comes to bad register scheduling and the like. The backend's scheduler is actually very effective. It mattered with the Pentium and Pentium Pro processors, but not anymore. But the code is still there, and still works, and the algorithm is sound. https://github.com/dlang/dmd/blob/master/src/ddmd/backend/cgsched.c At a first glance it looks highly x86 specific. I am not sure how much of this really lends itself to be applied on arm. The backend-IR does not seem to be able to express some ARM concepts such as predicated instructions. While those maybe shoehorned in, it is likely to be impractical to reuse most of this code.
Re: Work on ARM backend for DMD started
On 7/4/2017 1:15 PM, Stefan Koch wrote: Most arm implementation are not as forgiving as contemporary x86 processors when it comes to bad register scheduling and the like. The backend's scheduler is actually very effective. It mattered with the Pentium and Pentium Pro processors, but not anymore. But the code is still there, and still works, and the algorithm is sound. https://github.com/dlang/dmd/blob/master/src/ddmd/backend/cgsched.c The backend has also been accused of not doing data flow analysis. It does as good a flow analysis as any compiler. Where the backend has fallen behind are: 1. loop unrolling 2. better inlining 3. SROA 4. vectorization
Re: Beta 2.075.0-b1
On Tuesday, 27 June 2017 at 10:46:38 UTC, Mario Kröplin wrote: It' not really intended to disallow comparisons between const(Status) and Status, isn't it? Sure not, please file a regression. BTW: There's a regression: running dmd with option -deps results in a segmentation fault. We can try to reduce the example. Yes, please do. Maybe dustmite can help you https://github.com/CyberShadow/DustMite/wiki/Detecting-a-segfault-in-dmd-itself.
Re: Beta 2.075.0-b1
On Tuesday, 27 June 2017 at 07:51:07 UTC, Dsby wrote: what about DIP1000? Is it default? We'd definitely mention such a big change in our changelog. At the moment scope support is still experimental with a couple of known issues (https://issues.dlang.org/buglist.cgi?quicksearch=%5Bscope%5D). Fixing those and adding safe unique, ref-counted, and weak-ref primitives to druntime/phobos is a major focus for the 2nd half of 2017.
Re: Work on ARM backend for DMD started
On Monday, 3 July 2017 at 23:16:07 UTC, solidstate1991 wrote: While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. ARMv5 is being considered if it doesn't need a lot of work, although I don't see a lot of reason behind doing it besides of the possibility of enabling the development of homebrew GBA, NDS, GP32, etc stuff. As I became unemployed recently, I have a lot more time for development, so time now isn't an issue. Or at least until I find a job, which is hard due to my state as a college student, which I'm on the verge of losing it. I would accept your input on various things, like if I should do some adjustments to the in-line assembly stuff, whether I should care about thumb (reduced size instruction set, not available on some newer targets) or not, etc. Got my hands on some official reference manual, it wouldn't hurt if I could research other ones too. Far be it from be to discourage such efforts. But you should be aware that writing a backend for dmd from scratch is not an easy task. It will take time alot of time. Even if you have previous experience with codegen. And it is unlikely to yield satisfactory results. Most arm implementation are not as forgiving as contemporary x86 processors when it comes to bad register scheduling and the like. What exactly is your motivation for doing this ?
Re: Work on ARM backend for DMD started
On Monday, 3 July 2017 at 23:16:07 UTC, solidstate1991 wrote: While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. Nice initiative. Let me still point out the obvious, we already do have working ARM backends from both gdc and ldc. https://gdcproject.org/downloads https://wiki.dlang.org/LDC#ARM If you're interested in spending that amount of time into ARM development, you might find improving bare-metal ARM support for embedded systems (noeabi) or AARCH64 support of druntime/phobos equally interesting projects with a bit more impact.
Re: Release candidates vibe.d 0.8.0-rc.1 and vibe-core 1.0.0-rc.1
On Thursday, 22 June 2017 at 20:59:51 UTC, Sönke Ludwig wrote: Am 22.06.2017 um 20:52 schrieb aberba: [...] Agreed, there are several places in there that can be improved or made more consistent. The HTTP package (including WebSockets) is the next big part that is up for a complete redesign, also (finally) including HTTP/2 support. Since I'm really busy with another project I can't state a reliable schedule for this, but I'll try to start in the near future and will also to try to involve interested people in the design/development process as early as that makes sense. I can help... How can I contribute?
Re: Work on ARM backend for DMD started
On 7/3/2017 11:50 PM, Iain Buclaw via Digitalmars-d-announce wrote: On Monday, 3 July 2017 at 23:16:07 UTC, solidstate1991 wrote: While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. ARMv5 is being considered if it doesn't need a lot of work, although I don't see a lot of reason behind doing it besides of the possibility of enabling the development of homebrew GBA, NDS, GP32, etc stuff. As I became unemployed recently, I have a lot more time for development, so time now isn't an issue. Or at least until I find a job, which is hard due to my state as a college student, which I'm on the verge of losing it. I would accept your input on various things, like if I should do some adjustments to the in-line assembly stuff, whether I should care about thumb (reduced size instruction set, not available on some newer targets) or not, etc. Got my hands on some official reference manual, it wouldn't hurt if I could research other ones too. I'm aware that this is a topic that's occasionally brought up, but as someone is proposing to go from idea to implementation. It seems like a good time to point out. Someone did this 5 years ago as part of splitting the backend into interfaces - or at least as a working concept that the new interfaces actually allowed you to implement a new target. Maybe you should use their work as a starting or reference point. You'd probably save yourself most the trouble of working out how things connect. Iain. Unless someone else toyed with it also, it was me. There's a branch called 'arm' in my fork of dmd that has a lot of groundwork. I'm sure it's somewhat bitrotten in the few years since I last looked at it. I got as far as being able to emit some _extremely_ basic functions (like calls to libc -- printf worked) and link. I wrote the asm code -- as an exercise to force being able to encode much of the arm instruction set (if I remember right, pretty much everything except the neon vector instructions, and maybe even part of that set) in code structs. But I didn't get to writing the arm version of almost any cd* functions to translate the ir into actual code objects. Honestly, it's a pretty bad proposition. I did what I did as much to learn about the arm instruction set as to get an arm dmd backend. It did teach me a lot and I don't consider it entirely wasted time, but if the aim is to do anything beyond learning, I'd urge looking for a different project. Just getting code of really bad quality emitted will be a lot of work (on top of all the parts I did). Getting mediocre code will be another large amount of work. Getting code close to ldc or gdc is unlikely to ever happen. So, look closely at your motivations and available time.
Re: Release fluent-asserts 0.6.0
Thanks for the appreciation! On Monday, 3 July 2017 at 15:07:48 UTC, WebFreak001 wrote: Cool! I just tried it and it is really magic how good unittests can be, I love it showing the source code where it went wrong, I Yes, a lot of programming languages have such assert libraries... and they are so helpful guess that might be a security risk but if anyone uses asserts in a production environment and it's leaking passwords it's their fault anyway. If you are referring to the the fact that the source code is displayed, it should be ok, since if the files are not found near the test build, the code will not be displayed. Anyway... it might be a good idea to allow the library on the release build only if you provide a certain flag. Failing the release build if the library is included it might be useful since there is no reason to link it with the production code. I am not really a fan of the a.should.be(b) thing but I like the Assert.equals() function, just looks more natural and easier to read to me + it is understandable by people who can't speak english better. I thought that not anyone likes the BDD approach so I added `Assert`... I think it's good to have options
