The guy who made the "hide your kids, hide your wife" remix simply MUST make an album from your video beat boxes and ballads. I vote for "let's fucking go" for the single.
10:22 these are the callee saved registers. It's part of the System V ABI calling convention that these registers retain their value after a function call.
8:44 Reason for the pie errors is most likely since you were using instructions which operate on absolute addresses (any time you use addresses of static values), this is because of ASLR, which makes it so that the binary really can’t know what the label address will really be. Static labels are usually addressed relative to the instruction pointer instead (RIP relative addressing), so instead of using load label instructions, you’d use the LEA instruction (load effective address) first to get the actual address of the label and then do the load. With this, I think the pie errors would disappear.
The Commodore Amiga had one of the first preemptive multitasking operating systems running on home computers. On the original Amiga 1000, it was running on a 8 mhz M68000 CPU with 256Kb RAM. Can your C do that!? Huh!? Huh!?
@Tsoding Daily, just swap the dead context onto the end of the stack, then pop it off the stack. That is a way to release the data without corrupting the stack.
how about switching function call pointers in c. then the stack stuff would automatically switch internally by the compiler. then each thread function call only does small part of the thread work at a time. switching. then you only deal with stuff in memory, not in registers, those will be handled automatically, after the function call switches. in pure c. well, thread switching vs fully pipelined in single core. pipeline flow vs switch. function pointer call switching assumes each threading function has their own internal data in their own memory addresses. no manual thread management required. just c code. opencl c does not have malloc. static array allocations only. if you use c only, you only get to push and pop, not have to worry about the internals of the stack. c is for abstraction reasons. c is designed to avoid very low level stuff in asm. you are trying to do what a c compiler does with the environment switch code in asm. no function pointers in opencl c also. no assembler in opencl c c99. great, the program only can yield, back to os. partitioned workload would yield the better c-only definition and operation. so why did you make da_append as a macro, not a normal function. also why re-implement what is already native in c, the function call mechanism. pointless pointers. instead of yield function call in the partial functions, just make partial data processing in the functions. no need to mess with the stack. just use c function calls. so why not just code single core threads instead. then its not manually flow controlled but automatically by the single core threads. threads if you can specify that they dont run on a separate core specifically. on single core you are guaranteed to have sequential exec of instructions. in multi-core you are not. not cursed. *entrely.
Quite suprising that you can just allocate stacks, with all the modern non-execution, rop prevention, frame pointer and control flow protections. But I guess they are mostly opt-in.
Would it be possible to write the entire coroutines library in C3 only instead of depending on a dynamic C library? I saw that C3 also some inline ASM features, so I think yes.
"a language where you could += but also mod" That would be a ternary assignment operator which would be kinda weird. Like would it be written as "a +%= b, c" Or something like that? I think in c you can technically just do that with (a += b) %= c But that is definitely cursed
For `a = (a + 1) % b`, it's much faster to do `a += 1; if (a == b) a = 0;` because a == b is unlikely and therefore near free. Btw, (a += b) returns an r-value, so it can't be assigned.
Just make it a function. Or drop the mathematics way of writing expressions and go back to stack monke: "operator arg arg arg", where each individual "arg" can be (or, in fact, is, if you treat each name access as "read-from-name" operation) another expression. If you really incist on a mathematical expressions with priorities and other crap (instead of just grouping things by parenthesies and position on the stack or by assigning to a new names), then just introduce a special syntax, like double-parenthesies-enclosed expressions in bash "((x + y/2))".
Do you mean like llvm ir?.Then the problem will be that your code can only be compiled by a single compiler.Also yes gcc also has a ir but an ir is not necessary to make a compiler to begin with I think tcc does not have a ir.
because this kind of thing will not be abstracted away by an IR, the set of registers to save is very specific to the architecture and OS calling convention
@@ratchet1freak Yeah and if it's as trivial as a single pair of save/load, I'm definitely on the side that's saying it's easier just to hard code stuff sometimes too lol
I don't know if it would be quite so simple, but couldn't he use fasmg to code in a "high-level" assembly and just put the respective processor instructions file to make his code portable? I would like to learn more about this, could be a nice recreational programming live subject, ... just saying.
@@Tezla0 you're very wrong about C and its "close to assembly" features, my friend. C is just about working on things that can have addresses, "memory-oriented" design if you will. It does a lot of things that you would hope to just turn off but it's impossible by design, unless you make a compiler treat your C code way out of spec.
@@Tezla0 actually no, there are several examples where C compilers are unable to generate the machine code with the least amount of CPU cycles even with the -O3 flag (here is an example: ruclips.net/video/B2BFbs0DJzw/видео.html). One could have a program written in a x64 assembly style, but with a ARM or even RISC-V instruction headers that translated each given CISC instruction of x64 to an equivalent minimal number of instructions of a ARM or RISC-V CPU (like a simple dictionary). Thus guaranteeing that the code is the most efficient translation of your x64 assembly code into any other architecture for which you have this instruction header dictionary (modulo some strange way in which you could compress the translated instructions of a group of x64 instructions into a smaller set of instructions than a direct replacement, but I am not sure how this would be done and I doubt any C compiler to be able to do this anyway).
Welcome to yet another recreation of programming session with uh mistuh zozin
yessu yessu yessu
how bout that
@@desertfish74 kawai kawai desu
Mistuh uuuh zozin
gucci gucci tomagoochi
I like the "chat in subtitles" popup now, much better than finding it yourself
I wonder how many people know that they can grab the subtitles and drag them to a different position.
@@artemiasalina1860doesn't work on phones btw
sunny working low wage
"even though it's not supposed to segfault in my opinion"
The guy who made the "hide your kids, hide your wife" remix simply MUST make an album from your video beat boxes and ballads. I vote for "let's fucking go" for the single.
10:22 these are the callee saved registers. It's part of the System V ABI calling convention that these registers retain their value after a function call.
8:44 Reason for the pie errors is most likely since you were using instructions which operate on absolute addresses (any time you use addresses of static values), this is because of ASLR, which makes it so that the binary really can’t know what the label address will really be. Static labels are usually addressed relative to the instruction pointer instead (RIP relative addressing), so instead of using load label instructions, you’d use the LEA instruction (load effective address) first to get the actual address of the label and then do the load. With this, I think the pie errors would disappear.
Title goes hard
The Commodore Amiga had one of the first preemptive multitasking operating systems running on home computers. On the original Amiga 1000, it was running on a 8 mhz M68000 CPU with 256Kb RAM. Can your C do that!? Huh!? Huh!?
I studied that processor in the microprocessors course I took at university. That little Motorola demon was ahead of its time
Well yes
And so was Atari ST, it was surreal to watch everyone typing away in DOS while you had this graphic OS to play with.
@ The Atari ST didn't have preemptive multitasking, it was cooperative multitasking (as far as I am aware of how the ST worked.)
Yes. Unix was on even more crude hardware. PDP11 only had 64K of Ram.
@Tsoding Daily, just swap the dead context onto the end of the stack, then pop it off the stack. That is a way to release the data without corrupting the stack.
Digging this channel. You're a true 'c'had.
how about switching function call pointers in c. then the stack stuff would automatically switch internally by the compiler. then each thread function call only does small part of the thread work at a time. switching. then you only deal with stuff in memory, not in registers, those will be handled automatically, after the function call switches. in pure c. well, thread switching vs fully pipelined in single core. pipeline flow vs switch. function pointer call switching assumes each threading function has their own internal data in their own memory addresses. no manual thread management required. just c code. opencl c does not have malloc. static array allocations only. if you use c only, you only get to push and pop, not have to worry about the internals of the stack. c is for abstraction reasons. c is designed to avoid very low level stuff in asm. you are trying to do what a c compiler does with the environment switch code in asm. no function pointers in opencl c also. no assembler in opencl c c99. great, the program only can yield, back to os. partitioned workload would yield the better c-only definition and operation. so why did you make da_append as a macro, not a normal function. also why re-implement what is already native in c, the function call mechanism. pointless pointers. instead of yield function call in the partial functions, just make partial data processing in the functions. no need to mess with the stack. just use c function calls. so why not just code single core threads instead. then its not manually flow controlled but automatically by the single core threads. threads if you can specify that they dont run on a separate core specifically. on single core you are guaranteed to have sequential exec of instructions. in multi-core you are not. not cursed. *entrely.
Having chat messages as a subtitles is great idea.
Quite suprising that you can just allocate stacks, with all the modern non-execution, rop prevention, frame pointer and control flow protections. But I guess they are mostly opt-in.
Amista Azozin
1:11:47 Do paging instead of malloc and the stack would be aligned to 16 bytes automatically.
posix_memalign seems simpler than paging right?
40:28 I think more reasons for malloc returning null nowadays are cgroup or ulimit or Container limits
Would it be possible to write the entire coroutines library in C3 only instead of depending on a dynamic C library? I saw that C3 also some inline ASM features, so I think yes.
the stream is getting more interesting, awesome
New thumbnail 👍
1:19:00 let it leak, let it leak
@@yglyglya govnos in haskell when
1:20:27 no need to swap, just copy (if not last)
"a language where you could += but also mod"
That would be a ternary assignment operator which would be kinda weird. Like would it be written as
"a +%= b, c"
Or something like that?
I think in c you can technically just do that with
(a += b) %= c
But that is definitely cursed
Signed modulo (I use this for rotations from -360 to 360): x - x / y * y
For `a = (a + 1) % b`, it's much faster to do `a += 1; if (a == b) a = 0;` because a == b is unlikely and therefore near free.
Btw, (a += b) returns an r-value, so it can't be assigned.
Just make it a function. Or drop the mathematics way of writing expressions and go back to stack monke: "operator arg arg arg", where each individual "arg" can be (or, in fact, is, if you treat each name access as "read-from-name" operation) another expression. If you really incist on a mathematical expressions with priorities and other crap (instead of just grouping things by parenthesies and position on the stack or by assigning to a new names), then just introduce a special syntax, like double-parenthesies-enclosed expressions in bash "((x + y/2))".
>makes lagrange-uxn video unlisted
>references it in every subsequent video
why did he unlisted it lol?
There is some stuff that the refrence code missed in long jump. Specifcly it forgot that simd registers exist
This one is very satisfying. So glad I caught it live.
Why not program in an IR instead? It can be similar to architecture agnostic assembly.
Do you mean like llvm ir?.Then the problem will be that your code can only be compiled by a single compiler.Also yes gcc also has a ir but an ir is not necessary to make a compiler to begin with I think tcc does not have a ir.
because this kind of thing will not be abstracted away by an IR, the set of registers to save is very specific to the architecture and OS calling convention
@@ratchet1freak Yeah and if it's as trivial as a single pair of save/load, I'm definitely on the side that's saying it's easier just to hard code stuff sometimes too lol
I don't know if it would be quite so simple, but couldn't he use fasmg to code in a "high-level" assembly and just put the respective processor instructions file to make his code portable? I would like to learn more about this, could be a nice recreational programming live subject, ... just saying.
"High-level" assembly is called C
@@Tezla0 you're very wrong about C and its "close to assembly" features, my friend. C is just about working on things that can have addresses, "memory-oriented" design if you will. It does a lot of things that you would hope to just turn off but it's impossible by design, unless you make a compiler treat your C code way out of spec.
@@Tezla0 actually no, there are several examples where C compilers are unable to generate the machine code with the least amount of CPU cycles even with the -O3 flag (here is an example: ruclips.net/video/B2BFbs0DJzw/видео.html). One could have a program written in a x64 assembly style, but with a ARM or even RISC-V instruction headers that translated each given CISC instruction of x64 to an equivalent minimal number of instructions of a ARM or RISC-V CPU (like a simple dictionary). Thus guaranteeing that the code is the most efficient translation of your x64 assembly code into any other architecture for which you have this instruction header dictionary (modulo some strange way in which you could compress the translated instructions of a group of x64 instructions into a smaller set of instructions than a direct replacement, but I am not sure how this would be done and I doubt any C compiler to be able to do this anyway).
Hm Not sure if you can interrupt, but you can wrap io with a yield block
good stuff
1:45:10 coroutine id moves around when you get swapped into a freed Slot (ah you talked about it later)
What about LLVM IR ?
what about it?
He's saying you can write it in llvm IR to make It cross platform
Thank you....
Off topic but what's the name of the font hes using?
Iosevka
@drownwarlord7581 thanks!
this is truly epic, meine freunde
WAITT
how are you making money? I thought you stream _for_ money
🤙
Expecting to rewrite everything on C3 not only C, waiting C3 and preemptive concurrency =D
c-- is an interesting idea, currently it is unmaintained
With all the legalese in GCC documentation I guess they really believe that code is law.
That's why C was created in the first place :v
Mr zozin mr zozin
I think the lagrange video got deleted .
da_like
ASM is like Meta of C 😂
THUMBNAIL
bro, your YT-avatar looks more satisfied than you... something goes wrong😅
It says more about the programmer than the language, lol.
next time coroutines in wasm :p
hallo mista zozin!
The intro is stupid, I have no reason to watch the video now since I know how it ends
It's about the journey, not the destination.
@@RustIsWinning Good for you. That's wildly subjective, it ruins it for me.
@@theboomerperspective2478
You sure you are actually a boomer?
What do you think this is, TV entertainment so you don't want spoilers? 😂
Knowing bits of knowledge beforehand helps with easier understanding later.
@ If you are THAT slow then yes, maybe you shouldn't comment then
Hello memory_leaker69!