From to ~mpu/qbe
As my compiler gets more and more able to properly parse text and output error messages, I'm thinking to also start writing the backend so I can have a final product little by little. But in the mean time, I thought about making this question. // Skip this paragraph if you don't like to read. The main idea was that my backend should output code in C. This has two advantages: 1. I can use all of the amazing C compilers that exist out there with all the advantages this brings. 2. Portability in a lot of OSs and ISAs. // Skip this too However, there is a HUGE disadvantage and this is compilation times. This is super important and the reason I don't use so many programming languages that are out there and I want to make my own. You see, at first, I thought about using TCC to compile code super fast and use GCC for the parts of your code where performance matters. However as the time goes and the more I think of it, the more I see how this, while it seems to work in theory, it will be a pain in action! Using this model, means that the developer will have to compile every new part of his/her code multiple times to see if the gains in speed are worth it. Of course, that's not absolute, as we could have some ways of knowing what kind of code will see bigger gains from GCC but still, it will be very uncomfortable and annoying in action. I think that's the reason that other language that output to C (like Nim, Zig, V) don't do that. So here's where QBE comes in play! QBE compiles code very fast and has about 70% of the performance of "GCC -Ofast" (in the worse case). The performance can be better (and maybe worse?) but at least, that's the performance I got when I tried to compile QBE with Cproc vs GCC. So my question is, what kind of optimizations QBE doesn't do that GCC does (of course, I know that GCC makes tons of optimizations and I don't expect a list of every single one of them, I'm talking about the most important ones)? And also, can I improve things significant in the frontend of my language? I know that GCC makes aggressive optimizations going as far as to profile the code and change it for you and I don't care about things like that as they will probably not give any significant performance boosts and because also, I promote people properly learning how to write good an efficient code and be rewarded by that. But I do care about things like the proper use of CPU registers, constant folding (which I can do in the frontend I guess), inlining (I can also do in the fronend), aliasing, loop unrolling and anything that will give significant performance boost. I would like to know how QBE goes on these and if it is planned to add more optimizations in the future. 70% of GCC's performance in the worse case is in general very good. I would like to know if it can be worse for specific cases as my language will be general purpose so I don't want people to feel limited. I made the same question on TCC's mailing list but I didn't got an answer that actually answered my question the way I expected so I thought about giving my shot and see if I'll have any luck with QBE. Thanks for the amazing work on QBE and thanks for your time reading that even if I don't get any answers!
From to ~alextee/zrythm-discuss
20 Μαρ 2022, 15:18 Από alex@zrythm.org: > I think this covers it well: > https://librearts.org/2022/01/2021-recap-2022-preview/#zrythm-progress > > IMO Ardour is more suited for audio engineers and audio recording, > while Zrythm is more suited for electronic music using lots of MIDI. > > -- > Alex > Thanks a lot!
From to ~mpu/qbe
17 Μαρ 2022, 20:54 Από ori@eigenstate.org: > Quoth rempas@tutanota.com: > >> >> ``` >> export function $_start() { >> @start >> syscall(w 60, w 0) >> ret >> } >> ``` >> >
From to ~mpu/qbe
17 Μαρ 2022, 18:46 Από quentin@c9x.me: > On Wed, Mar 16, 2022, at 20:41, rempas@tutanota.com wrote: > This is pretty niche. Syscalls are entirely platform dependent and > will likely be used only very sporadically in wrapper functions. > Also, like Drew showed, it is very easy to wrap syscalls in regular > functions. For all these reasons, syscalls will never have il support. > > For the sake of clarity on the directions the il might take, here are > a couple of features I find desirable: thread local storage, volatile > memory accesses, blit, computed jumps, simd instructions. > Both you and Drew are totally right! Like I said, I know that it possible to do that, I just said that it would be nice to see built-in support for it.
From to ~mpu/qbe
15 Μαρ 2022, 23:49 Από quentin@c9x.me: > Hi, qbe is now in a state where I think it > is reasonable to make a release. You can > test the candidate commit > cec9855fa0c8d9566d4c9755ef7677f49634bc60 > and let me know if you observe any > problems. It is also time to shout if > you think I oversaw something important. > > Recent notable changes are: > - inclusion of Michael Forney's riscv > backend > - abi fixes for riscv to offer proper
From to ~mpu/qbe
14 Μαρ 2022, 12:32 Από bgs@turminal.net: > I see, we'll fix this in harec then. Perhaps it would make sense for qbe to > error out in such cases instead of carrying on. > +1. Please, more info and warnings! Us beginners will really appreciate this!
From to ~alextee/zrythm-discuss
I want to go get into music production (for fun) and I want to choose between Zrythm and Ardour. I know this is a hard question to give a simple answer but what I'm more interesting in how promising Zrythm is. Are there any features that make it easier and more enjoyable to use than Ardour? Maybe better performance? I know that Zrythm is currently on Alpha but I don't mind if it is not super stable and I know that probably more features will come in the future but I just want to know the general idea and goals behind it. I suppose you've been inspired by Ardour and you probably wanted to make a DAW that people will like to use more than Ardour and I suppose that you know what are the weak points of Ardour and you made Zrythm with the idea to not have these weak points. I don't know what I'll get from this cause like I said, it's very hard to answer this question but I thought about doing it anyway... Thank you in any case!
From to ~mcf/cproc
After trying to play with some GNU attributes like "constructor", "deconstructor" and "cleanup", I found out the while cproc will compile the program that uses these attributes, they will not have any effect. So yeah, I would like to ask what's the state and if you plan to support them (or some of them) in the future.
From to ~mcf/cproc
Oh, that makes sense! Thanks a lot for the info! The truth is that I'm just trying to read the source and figure how it works from the top to the bottom. I haven't read someone else's source (not talking about simple stuff like functions) so it's a little bit hard and new (yay!!!) for me. Tbh, QBE seems UNREAL consider the time it takes to compile and the quality of code (runtime speed) it produces. Cproc, is a true C front-end to QBE that is capable to compile a lot (I'm pretty sure way more and bigger projects that the one that are referred) of true big and complex C programs. So yeah, I'm amazed and I want to make my own language by understanding how cproc works and build upon it. Thanks a lot for your time! I really appreciate it! P.S. Sorry I'm also new to mailing lists (and sending mails in general) and I accidentally send this to your mail rather than the conversation. I suppose
From to ~mcf/cproc
After reading the code, the switch case in the "ARGBEGIN" seems to have a case for "t" but when I'm trying to pass the option when running "cproc", it says that the option is unknown. Maybe I don't understand something right?