Don't mind the post-written analysis but definitely prefer the live coding because your process / train of thought is what I find most valuable about your videos!
For those complaining about goto, that's literally how all conditional constructs are implemented, just by a different name, such as je, jg, jl, jz, jnz, etc. As for the data storage for a todo app, I wouldn't do it any other way. Pascal strings are quite apt since you'd have to be insane to need more than 255 characters for a single entry in your todo list. As to the format, I like the problem solving process more. To see you solve problems in real-ish time is more satisfying than just seeing a rundown of the code after the fact, but I feel like more people would respond to the shorter video format, so do whichever you feel like.
I really like the realtime format as well. Seeing the obstacles and process of thinking through potential routes forward is invaluable. Not to mention just watching how you use your tools and environment is just as educational and a great bonus. This "retrospective" way could be good too if done well and would be nice for conciseness, but the realtime format is very satisfying.
I personally think that writing the code is more engaging, as it automatically brings you to explain what the thought process is and if something doesn't work how to fix it. I think that when there's code that's maybe very tedious or not very interesting it makes sense to do it like this though. For example, you wrote all the HTML off-camera which isn't very interesting, so that's fine.
I enjoy hearing you explain things and if the streams weren't good that's understandable, but there is something about watching you while you try to solve a problem that I like so much more. Even still: Great video!
18:51 calling conventions between syscalls and regular functions are actually not quite the same. Both specified by the systemV C abi, and they are extremely similar, but the sequence of registers for userspace is actually rdi, rsi, rdx, rcx, r8, and r9 (and it supports additional args which go on the stack and also floating point args which go in vector registers) while syscalls use registers rdi, rsi, rdx, r10, r8, r9 (rcx is switched for r10 for some reason) and only supports up to six arguments no more on the stack nor any vector arguments.
You are correct though that the calling convention for 32 bit is completely different. In 32 bit userspace code, all arguments are on the stack, while for syscalls, the args go in ebx, ecx, edx, esi, edi, ebp
discovered you recently. love the cut of your jib ! listening to you while i bang my head against a wall trying to learn SDL. thanks for the varied and unique programming content, that is obviously produced simply for the love of the game.
I like this format of just running through your code and explaining it. Do you plan on having an "archive" channel where you hold an archive of your streams? I really enjoy and find it very educational when I am watching you go through the process of solving a problem, it helps me see new ways of approaching and solving problems I come across when I am playing with programing and or math problems. Cheers, thank you for all the amazing work you are doing.
To add to this comment. It is also nice to see small bits of the code being run. You get to see the pathway of how the code and features grew to become the final application
whoa this channel is treasure trove.... everything from lowest level machine op codes to web coding and CI style build systems (with good UX for dev in mind) with C.
The live coding format is incredibly valuable! Curating what you post on the main RU-vid channel makes sense but please at least keep the full VODs on twitch permanently or archive them someplace
Both formats are good and fun. Variety is my favor. Live coding shows process and gets less work done. Summary forgets process but shows more work. They show unique valuable things.
OMG this new approach for videos is wonderful. After watching the stream and if something we are unable to get initially, this will accelerate the process of our understanding. Thanks @tsoding
I wonder if the ASM code would've been simpler if you passed data as a path parameter instead, e.g. POST /new/coffee. This way there is no need to parse body at the end of the http packet. But you would need to write a bit of JS though.
@@TsodingDailywhy bother with methods and query string at all? Isn't it more logical to just search for the body and parse it? Assuming that it is a single user app and we won't send anything but text anyway..
i am personally more a fan of the "explaining while coding" format. you seem to be less focused while coding, so we get more of the interesting side tracking into other topics and so on.
Have you ever considered trying Odin? Seems similar to Jai which I know you seem to enjoy but try to avoid using because your viewers cant use Jai. Odin accessible for all your viewers. Seems like an interesting language and Id love to get your thoughts on it.
I really hope you find a minute in the near future to do many very compact, clear and concise tutorials, which take the time needed to explain/teach especially on all the single core concepts which can be applied in whole sets of languages, cross-platform, generic - pure Tsoding, like the Generative Sessions have shown again and again. It's easy to rush over that point of microgravity god-certified birdeye-view where everything just makes sense and it flows naturally, unitl you get lost and stuck in the possibilities and limitations. Your hands-on and go-for-it approach and the testing and deductively discovering realities and assumption proving is old school, with core tools and most welcome. Thanks for sharing!
Regarding what style to follow in the near future for your "program": You have a lot of super solid schemata in action be it via Stream or VoD. The paths you walk regularly should remain a fixed component. What i personally would like to see is - coding: everything that allows to stay compact and fast but foremost be easily portable to other languages, second be versatile and binding/module-firendly in both directions - porting: in-depth streams where you do 1-to-1-ports of your released, tested and working tools - first for fun into a language you don't know - as a bonus (if you feel like it - meaning it can be an optional part of the stream) a rapid repetition of the pitfalls, rules, guidelines you came up with before but this time you do the same port into a language you really know but haven't it ported to, yet - who knows maybe a group of people decides to try it, maybe a regular on your channels? If so, how about inviting someone - screensharing is enough - and it doesnt have to be a live-stream, even as a VoD on YT it would give the feeling of watching over the shoulder (and on that topic ...) - pair-programming: as mentioned before, if someone is willing to make the effort and show some persistence/tenacity and shares a specific interest - how about pair-programming style tutoring and while the "student" does the "now its your turn to do it" you explain it to the viewers in other wording. Tutoring doesn't need to be uni-directional, too .. - designing/structuring/exercising: lots of mini-vids just showcasing all the little things that always repeat - from a language-agnostic perspective or language-category-dependent, just abstract enough to allow to follow your explanations/comparisons between similar languages and direct enough to be of use and easily memorizable with some practice - (compare rosettacode) - redesigning: How about you take an existing example (e.g. a todo-app written in assembly) and showcase in a session how much difference it makes to use non-regular vs. generic types - be it using nowadays not so often used 6-/10-/20-/31-bit or custom or variable bit-width, or creating custom flags/register-sets, make an app stateless so it can be fed in a JSON on initialization defining its scope/capabilities - leading: make use of your mindset and use your effectiveness to (re)create apps, that can have different states depending on the available IO, like: Generalize your ToDo-App, make it fully modular, make it generative and generate the app but make it speech-only or based on audio-icons or purely visual, or detect if a joystick or a pad or other controllers are attached and make the exact same app controllable in that way too, bring in the different bit-width, custom datatypes, show how to restructure a small app that is in itself already complete but show us all the ways we can explore ways not yet known to us or even you that way. .. just not alongside a stream, but in a nice portioned size as a preproduced short vid on demand on yt etc. basically just do you, explore the possibilities .. including those to create fixed series of stream/vids in a not all too varying length inside their specific genre. On a personal note: Just listening to your ramblings helps me reconfiguring my brain back into something usable. Going virtually through the examples, guided by your descriptions, anecdotes, metaphors and on-point explanations is kind of a mind-exercise, waking up (thought of as long lost) memories, rewiring the brain to grasp new concepts, etc. I wonder if it would be possible to teach coding purely by narration. Sure this would require building your own sub/super-set of nomenclatures/wordings but i think you may be able to manage it - with the experiences you made and constantly add on top and your awareness of all of the pieces and concepts, structures and flows and how they interact and affect each other unwanted or at will. Lol, built another wall .. Hope this helps!
Great series, while it is more intertwining to see you come up with the concepts, I find this format just as entertaining and educational! Next series. can be building a Forth in Fasm, then the same app in Forth . >:D thank you for the series!
Around 18:00 - the Linux syscall and userland call conventions do differ actually - particularly in the 4th argument. In userland, it's passed via rcx, while in syscalls it's passed via r10. The syscall instruction actually overwrites rcx.
@@cluelessamerican9931 I suppose that's a possible line of thought, but since it could overwrite any register they want it to overwrite, why RCX instead of literally any other?
Hey Tsoding, I hit you up on twitter. Can I send you a Mac to do some swift/obj c and see how you would do the same stuff on a different OS/arm processor?
29:25 - I agree 100% about not doing this in production. But here is a little piece of history... Amazon's first webserver was written in C++ and it eventually became an insane mess to maintain. It took more than a decade to eventually be replaced with something more web-2.0-ish. So, it is not a far-fetch to do some production-level shenanigans using code-for-fun techniques... 😆
I don't like the lack of string instructions (starts_with could just be repe cmpsb, if you are comparing 4 bytes you literally only need one cmp instruction) and the overuse of memory over registers, but this is pretty cool anyways And no, linux syscalls use different registers than sysv calling convention (default) because rcx is clobbered by the syscall instruction, so syscalls had to use a different set of registers.
This format is nice, as it gives a good overview of the system which is sometimes difficult to follow in the coding streams, however I think if we have to choose one, I would pick the coding streams.
Your livecoding EXTREMLY educational. Density and quality of information are so high that I already use in daily work many of your problem solving techniques. Some things are so high quality that I cant use them on work not because I can't but because I didn't paid so much. Братан, харош. Понятия не имею где ты там работаешь с такими знаниями, мне кажется тебе пора с Джоном Кармаком работать, а не в стране третьего мира сидеть смотреть как все рушится вокруг. Давай лучше лайвкодинг все таки.
I've watched Andrew Kelly, in improving zig compiler, explains, CPU is fast, Memory Access is slow. Use indexes instead of pointers, etc. Is it possible to apply his ideas in this assembly todo.asm file? How can asm be benchmarked to look for areas of improvement, like how much memory is required for various decisions?
I was curious on how this all works under the hood and came across Hands On Network Programming with C. Great book with a public repo that has examples.
I'm no expert but I don't think it will die. Zig offers nice toolchain and interop with C, so why would't it stand a chance of becoming a standard for writing modern C? Also people behind it seem to be passionate about it. It may take some time though. I would say that you can be sure that you won't lose time learning Zig after C
Summary videos on youtube and coding vlogs on twitch should work for everyone, imo. If you just want a shorter self contained video on the topic, watch the summary, otherwise go to twitch and watch the whole thing. It would be great if you uploaded the vlogs to youtube too, since twitch deletes the vlogs after some time. Maybe to a separate channel? Maybe to the old channel?
@@irenicsuspense Yeah, _everyone_ was not the correct term. Apparently you can connect twitch to youtube, meaning it's possible to mirror twitch vlogs to youtube, which would be amazing, since twitch deletes the videos after some time. Not sure if Zozin wants that though.
> manage huge applications in assembly You simply don't. It is pointless to manage anything "huge" in assembly when C exists. C is very good at writing assembly, better than most men.
Почему же? IMHO, этот чел в одиночку и чисто по фану уделывает всех нарциссических клоунов, что выкладывают 10-минутные ролики, наполненные самопиаром, да весёлыми мемчиками и созданные исключительно ради рекламных интеграций 💪 Причём делает это не особо напрягаясь )
What would it take to create a minimal asm toolkit/framework for building http servers. Can we compose middlewares the same way we do in high level languages. The concept of "generic" programming doesn't really exist on such a low-level.