~rempas

Recent activity

Re: Stack head using the clone3 system call 4 months ago

From to ~skeeto/public-inbox

Thank you! Everything works as expected now! I do love how you know
EXACTLY what I understand and what not, and you explain it PERFECTLY!
I really have a loooong way to go but hopefully, I'll find people willing to
help and explain. Sharing knowledge is amazing! Hope I can also help a
lot of people at some point in my life!

Finally, I wanted to ask something else if you don't mind. Why is there a
"futex" when there is only one thread spawned and there is no need or
communication? Is it there just for demonstration or there's something
else I don't understand?

Stack head using the clone3 system call 5 months ago

From to ~skeeto/public-inbox


> I'm glad to see that you've given this a shot! You're quite close, but there area a few subtle details to sort out.
>
> First, unlike clone(), clone3() takes a pointer to the low end of the stack, which is mentioned on the man page. The original clone() does not know the stack size, so it takes a pointer to the high end, as otherwise the kernel could not find it. That simplified my demo, too. So you must modify newstack() to return both ends of the stack, the high end for you to populate and the low end to give to the kernel. I defined this to be returned from newthread():
>
> typedef struct {
>  void       *tail;
>  stack_head *head;
> } thread_stack;
>
> Where "tail" points to the address returned by mmap, and "head" is the original return value.
>
> Second, you were passing the wrong address for the stack, using "&stack" instead of just "stack". That means you were using the local variable as the low address for the bottom of the stack, and disaster ensued. At this very low level it's not possible to type check, so this hazard comes with the territory.

Re: Stack head using the clone3 system call 5 months ago

From to ~skeeto/public-inbox

It seems that the "waitid" version link is incorrect for some reason.
Sorry about that and here is the right one:

https://opengist.thomice.li/rempas/507560d6dfc649769d47bbc6b886a8ef

Stack head using the clone3 system call 5 months ago

From to ~skeeto/public-inbox

Hello! I'm trying to learn how I can spawn threads as I'm going to need it
for the system library of the new language I'm making. So, I have read the
stack head example and I understood it for the most part (and probably the
parts that I don't fully understand are what cause my problem). I'm trying to
create the example using the "clone3" system call as this is the system call
I want to use, but I have no lucky doing it.

I have created the "CloneArgs" structure and I have modified the "newthread"
function to take a "CloneArgs" type argument instead as, the stack head is
stored on its "stack" field for "clone3". I have also tried to do it using "futex"
and as this didn't work, I thought that this might be the problem as I know
NOTHING (other than reading the man pages and understanding a little bit
how they work in theory) about a "futex". I also thought about trying to use
the "waitid" system call". But in that version, the "waitid" system call also fails.

PURE quality of code outputed with QBE vs GCC? 1 year, 11 months ago

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!

Re: How does Zrythm compares to Ardour? 2 years ago

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!

Re: Release 1.0 candidate 2 years ago

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
>> }
>> ```
>>
>

Re: Release 1.0 candidate 2 years ago

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.

Re: Release 1.0 candidate 2 years ago

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

Re: bug in amd64 emit 2 years ago

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!