@@deschia_ We did testing on it back in college, comparing hand-coded assembly, C, Fortran 77, PL/1, and last (and least) Cobol. C and Fortran compilers did a reasonable job of producing something pretty close to what we did in assembly. PL/1 threw in some extra overhead which I think was related to memory management. And Cobol created a scary pile of machine code that we decided not to look into too deeply. I think it was summoning something from Cthulhu.
I don't care what other viewers say. Keep using paper! Sometimes you have to go the extra mile to make a point. I like your teaching style. Thanks for the videos. Very good info here!
+JP Aldama I agree. There is something I love in making notes on printed text. Plus, you can explain something so much quicker on paper because drawing and organising information is quick and intuitive, whereas doing such on a computer takes time to plan out.
They don't teach us that because the last forty years of computing history has been all about NOT reinventing the wheel. People got tired of having to start over every time a new computer came around, so we standardized our hardware, and operating systems (most notably, Unix) became portable between CPU architectures. Developers (the vast majority of them, at least) stopped caring about the low level stuff because they didn't need to anymore, and the computer science world progressed towards higher level things. They don't teach us how to actually do it because to go from nothing to even just a bare bones, functional shell environment by yourself would take years and years of development. So they just teach us the theory behind how it works and leave it up to you to do that stuff, if you want to. I feel where you're coming from, though. I used to feel the same way and I tried to learn things from the bottom up, but trust me; you'll be a lot better off if you start with the higher level systems and work your way down. It gives you kind of a bigger picture to see where the little things fit into.
It's not a problem, though. Nobody teaches 8-bit assembly because nobody uses 8-bit assembly anymore except hobbyists, and hobbyists already have many resources available them to learn from. Not to mention that most people interested in 8-bit assembly grew up with computers that ran it, and thus already know it! In fact, we have access to all the resources they did and more with the help of the internet. We can't expect the world to cater to our extremely niche interests. That's why we're all so grateful to Ben for sharing his knowledge and guiding us through the process
Not just hobbyists. Assembly language can also be useful for hacking. I'd imagine it be really useful for reverse engineering, finding certain exploits, and malware development.
When I first started programming in C (mid 80s) I wanted to make sure the compiler was doing a good job and would always check the assembly for timing critical code. After doing this for a while I realized I could write the C code in such a way to influence the compiler to output very efficient assembly. Nowadays, the few times I do this, I'm amazed at how good modern compilers have gotten at optimizing for speed.
@@user-iu8ps1yo1w theres not much you can do now in days lol. Also not really worth it imho because of how good compilers have gotten. But there are some reserved keywords in C and C++ that can tell the compiler certain things. All i really know about is marking functions inline can speed up the compilation process sometimes and can boost performance. Again, its not really worth doing that because the compiler should do all of that for you when necessary (if you mark the compiling command with -O3) its pretty easy to look up and youll eventually get the hang of it when you code more
@@user-iu8ps1yo1w Why would you? What's wrong with your compiler that you want to upgrade it already as a beginner? Maybe you should just try another one? Msvc, mingw or clang.
@@squizex7463 Maybe just due to curiosity? Or because a man wants to understand things better or just keen to do hard things? By your logic, one doesn't have to do anything because all the good things, by which you can do your software, are already written. So all you left to do is use them, which's boring af
Ah, I thought that the memory adresses were just chosen "ranndomly" by the compiler". But this makes me wonder though... how does the computer know how much space a variable takes up? Nothing in the machine code in the video shows that. What if the variable took up more than 4 bytes?
@@aurelia8028 in many languages you determine the datatype right? in "int x = 2;" an "int" is for example always 4 bytes and "double y = 5.4;" would make it 8 bytes etc *edit:* the size also depends on your platform... as mentioned by another commenter below, an int may be 2 bytes as well
The instruction at 0x10000f63 is moving the result of the printf function (the number of characters written) to a location in memory (even though it isn't used)
I never figured out what the printf() was supposed to be; It is implemented in 16-bit code that has to keep two registers pointed to the same address; It runs much much slower than what makes sense to me; A data-block like 1024 or whatever shroud be alloc at init; Like above while ( int ) I found much established C/S to be Horror Code of the Damned written by relatives of the Munsters to prevent use of sanity checks like if do while which works much much better due to zero based indexing
One of my college profs was in the Navy and needed to write assembly for the Navy to optimize COBOL code. He wrote it in FORTRAN and turned in the assembly. They had strict goals on lines of assembly to be written and debugged per day. He always met his goals. His reasoning was that FORTRAN was a pretty efficient language, and so he probably couldn't do much better. The Navy never knew they were converting their COBOL to FORTRAN.
You’ve reminded me of a talk I gave this year showing how some fortran code appeared in assembly. Fortran is still widely used in my field (supercomputing) and understanding the impact of such things like compiler optimisation is very helpful.
I like how the compiler optimised the while(1) into an unconditional jump instead of actually evaluating the expression "1". I know compilers have been doing that for decades, also it's a very basic optimisation, but I enjoyed seeing it on paper :D
@@_yakumo420 I think it is pretty interesting that even without any optimization, it became an unconditional jump, rather than test whether the int 1 evaluated to 1 (I'm pretty sure that's how while(..) works in C). I guess it's common enough that the GCC developers just hard coded that optimization construct into the compiler?
@@splashhhhhhhhhh Yes indeed but that wasn’t the point. The compiler detected that it’s a tautology and optimised it even without the optimisation flags set.
Even without optimizations on there are some optimizations that will always take place, such as not using hardware multiply/divide/modulus on powers of 2 etc
Regarding, moving eax onto the stack. eax contains the return value of the printf call. It's not actually needed by this example. It's probably saved to help a C debugger display what was returned and is likely a nuance of the compiler.
So basically, it's almost like the compiler turned "printf ("%d ", x);" into "int oX14 /* I chose the name as a mock of the memory location shown in the above assembly */ = printf ("%d ", x);"?
This makes sense, but I was wondering why this instruction only occurs after the prior 7 lines instead of right after the call instruction? I'm guessing this might be because the cmpl instruction will actually overwrite the value of eax to store the comparison result. Does this have to do with the compiler not being able to look ahead to see if the value will be referenced and just postponing storing the value for future reference until it absolutely has to? Also, this would mean the instruction wouldn't be there if the routine wouldn't reuse eax and just returned instead, correct? What code could have followed and still use this value at this point, without explicitly assigning it to a variable right away? Can you give an example?
Thanks for the explanation, but I'm still unclear on part of it. I understand that eax/rax contains the return value of the printf function and by the time "movl %eax, -0x14(%rbp)" gets executed, that's still the value of eax. From what you're saying, I get that trying to access -0x14 from assembler code would be a mistake, and I get that, but I don't see why the value needs to be kept around at all - it's clearly not referenced anywhere in the source code? What use is the return value of the printf function at that point? And why does it only get moved to that address at that point in time, instead of sooner?
Yes, I suppose so, in that I agree with you: it's really a question about the compiler and not so much about the program either in C or assembler. I'm a software engineer myself, and having written compilers, as well as tinkered with command interpreters in the age of DOS on an 8086, I can strongly relate to what you're saying. My curiosity was raised by the question raised in the video, about the meaning of that particular instruction - which was answered above by +Dameon Smith: it's the return value of the printf function that's being saved for whatever reason, independently of the program under consideration. I suppose I could look into the inner workings of the GCC compiler to find out, I more or less hoped someone might have an intuitive (and therefore short) reason off the top of their heads. But I agree with you, that's likely not the case - and certainly not the topic of the video, as the author rightfully stepped over the problem and seems to have taken some care to write their C code in such a way that the assembler would be as clean as possible for demonstration purposes.
The eax register will contain the return value of the printf function. Evidently it is being stored on the stack in the expectation that it will be needed later. Presumably you had the optimiser turned off when you compiled it.
I'm genuinely surprised C makes so much use of the hardware stack, since if you looked at the C2 compiler in Java for example it absolutely hates using stacks and almost always does everything in registers unless it has no other choice
@@theshermantanker7043 If you compile on any level of optimization, it usually doesn't make as much use of the stack. By default, GCC compiles with absolutely no optimizations on, though. I find it's easier to make sense of the compiler's assembly on -O1 (the lowest level for GCC), because it puts things in registers a lot more, like a human would.
@@theshermantanker7043Originally that is what the register keyword was for. It told the compiler you wanted it to store variables in registers if possible, but it was just a request and not a given.
I see, thanks for pointing that out, its interesting that the compiler still consider that [printf] would need to going back to where it come from even when it see that the loop is infinite
I guess it's tightly related to how memory and cpu work internally. And it is very limiting due to the binary nature as well as a frequency ceiling of the transistors. Dead end if you will in my opinion. Invention of multiple cpu cores bought us some time I suppose but the future is somewhere else.
I always thought assembly is useless and just a waste of time and money to take that class in uni but after I finished the class I realized how important it is, this might seem like an exaggeration but Assembly made me finally understand how Computers actually work and its diff one of the most important classes in CS . also its really useful for reverse engineering a TA in my uni showed me how to crack a program just by understanding assembly
@Adam Richard lol so true, I tried making more elaborated programs and instantly gave up. The fact it might be very different for each processor one might have makes it very discouraging. Or just raging, don't even need the "disco"
Just a little remark for people wondering why the code generated by the compiler contains strange and unuseful constructs. It is simply because the code was generated with the -O0 parameter which means, no optimization whatsoever. This means that the compiler basically does a nearly 1 to 1 translation of the C code to the assembly, without considering if the operation are redundant, unused or stupid. It is only when optimization is enabled that the compiler will generate better code. In this example, for example, it is stupid to read & write x, y, z continuously from memory. An optimizing compiler will assign register in the inner loop and will never write their values to memory. The spilling of the printf return value 'movq eax, 0x14'bp)' will of course not be emitted/
Interesting that clang -O2 results in the output values (1, 1, 2, ... 144, 233) being hardcoded into the binary. The clang compiler is evaluating the result of the loop at compile time.
@@zoomosis Hahaha, thats very interesting. I've always thought compiler does so complicated stuff that Im not gonna even try to understand it. So I always assume that they can do pretty much anything. I wish to write my own compiler one day, very simple though.
Can you define what you mean by 'spilling'? I mean, yeah, the return value of printf is loaded into this memory location, but it is never checked for success anyways, so why isn't it redundant?
@@lukasseifriedsberger3208 That 'redundant' store of the printf() result _IS_ the 'spilling'. The 'prototype' of the printf() function shows that it returns an int so, by default, the compiler will SAVE that value somewhere (even though the value is never used!) If the source code is compiled with some degree of optimisation (eg: -O1, -O2 etc), then it will remove this redundant store of the printf() result since it's never USED! For further reading, what does the returned value of the printf() function actually mean!!! (Not many people have ever USED this printf() return value, so they don't know what it actually signifies - It's probably more relevant for sprintf() or fprintf())
This is so cool, and I think this would be a way more fun/efficient way to learn Assembly than what's taught in colleges. It's way easier to see where these commands come from and what they mean if they're being directly compared to an actual C program. Much harder if a bunch of Assembly terms you've never heard are tossed at you and all of a sudden you're expected to code a program like this.
Try coding in machine language, now that was a chore. Assembly is just a higher level language that is converted/compiled into machine code. I originally started out studying electronics, so we had a course in machine code and had to write a program using it.
I taught myself BASIC then Pascal then C++. Learning was actually fun with some of the books they had in the '80s. I got a C64 for my 8th birthday, and I got the C64 Programmer's Reference Guide. It's just amazing the things that were in that book. It went from teaching you BASIC to showing you the memory maps, the pinouts for all the chips, and how to do graphics and sound. But it also had a 100-page chapter teaching assembly! It confused me because it made cryptic references to an assembler called 64MON which I had no idea how to get, but that made it more intriguing. The assembler class I took in college was also one of the only interesting classes I ever took. But I'm pretty weird. I was such a nerdy kid that in middle school I wrote letters to Brian Fargo and John Carmack asking for career advice.
@@captaincaption Brian Fargo actually wrote me back! That would've been about 1990 or 1991. I don't know what happened to the letter. I really loved Bard's Tale III and Wasteland. And today, 21 years later, I'm doing 2nd round interviews for L5 (senior dev) at Google ... but I just wanted to see if they offered anything interesting.
This is a good example on why learning coding without understanding how computer technologies layer on each other seems so daunting. Just learning a coding language is not really that difficult. But coding is complexity built on complexity, and each layer down it become exponentially more complex. From an outside perspective, like when when I first started learning code, it feels like you don't just need to know the top layer of knowledge, be it python or c++, but you need to understand what makes that work and how something else makes that work. At the end of the day Id have the impression I was going to have to learn how electricity works to understand the chipsets or ram to understand the next layer to understand the next layer all the way up to my code. The great thing is that these languages were made so we don't have to do that. OOP and modern tech has almost made everything so independent and modular that you can learn the end result without knowing fuck all about how it works. You don't even need to know to code to write games anymore.
You are right but there is one thing.. I dont think learning OOP or coding language is easy .. They are also difficult because if you want to learn really well they steal a loot of time from you :(
I was thinking this exactly today! I was wondering how much do I need to know about this stuff and how may It help me. Although I know I don't need to know all of this stuff is so interesting to me and I think It can give me a better understanding of computer science as a whole, so I'm planning on at least do some research. It's only been 8 months since I started learning Web Development but I am fascinated with everything related to computer science.
I love how you write on the disassembled code like that. Makes it so much easier to retain and understand. I've wanted to learn to read disassembled code, I'll be doing this to help.
Bvic3 Notice that something is being already saved to the position 0x04 at the top. And the number is basically an offset to the base pointer (%rbp) so 0x00 would be the base(?) of the stack frame. I don't know, maybe something is stored there
Man, well done to you, you perfectly explained in 10 minutes what a professor in University had 6 months to demonstrate and still wasn't able to. Really interesting.
Is it just me or you are feeling excited as well when you see machine language? I was learning python and working on stuff with for like everyday in 8 months. I started learning C and now it just feels a lot of fun language to work with! I even gave a break to python for the time being. Watching assembly feels interesting as well.
AKA "dry running", in the days when computer time was horribly expensive. It's still the best way to understand what's going on in code, and uncovering places for code optimisation, if performance is a problem. Don't optimise code before you've considered the algorithm, though.
@@thewhitedragon4184 they give you a block of code with a lot of unusual stuff and you have to answer what it outputs, or what are some elements of an array or something similar
frozen_dude - Yeah, I was hopping to have "otool" installed, but I didn't. I looked around and found this: stackoverflow.com/questions/137038/how-do-you-get-assembler-output-from-c-c-source-in-gcc There are lots and lots of ways to get gcc to output the intermittent stages of compilation. I love gcc! If people have never walked through the stages of compilation, I highly recommend doing it.
I thought I'd throw an example of the complete compilation stages out there... I guess because I find it interesting and informative. So when you compile a C source file, the process goes through 4 stages: Preprocessing, Compiling, Assembling, and Linking. 1. Preprocessing: 'gcc -E example.c -o test.i' < The example.c file is preprocessed with the include files, and other directives, #ifdef, #include, and #define. 2. Compiling: 'gcc -S example.i -o example.s' < The source file is compiled into assembly. 3. Assembling: 'gcc -c example.s -o example.o' < The assembly file is converted into an object file, a machine code file. 4. Linking: 'gcc example.o -o example' < The machine code file is linked together with other machine code objects and/or object libraries into an executable binary file. The *.i and *.s files can be examined in your favorite text editor. The *.o file and the final binary file are both binaries, so you'll need a hex editor to view their contents.
This is an excellent video that was easy to understand. You also managed to not skip anything seemingly trivial, which is rare for these types of videos and should be appreciated. Good job, man.
This actually makes sense. As mainly a C# dev, C isn't actually hard, first off. Pointers and such can get a bit complex, but they make sense. This code is certainly simple. The assembly makes sense too. It is beautiful how simple it is and how it uses such sinple functionality in order to create more complex end results. This helped my understanding of Assembly and it might be one of the things that help me finally make a PS2 game one day.
It seems simple, until you have to do implement data structures in C; then you find yourself crying for days on end, because you can't seem to resolve the clobbered memory errors that keep popping up on you!
@@IM-qy7mf AddressSanitizer makes this significantly easier to debug, though. It's like a plugin for compilers that instruments code using the compilers' own semantic information. You should also get in the habit of writing asserts for potentially incorrect or dangerous code.
This came up on my recommended. I remember using this video the night before my computer architecture exam several years ago back in college. Thank you, Ben Eater, for saving me on that one question.
Just fantastic to see how efficient the code produced by the C compiler is. I spent years writing assembler as a kid and used to have competitions with other on how fast and small we could make our code..
Spilling every value (including even the unused printf return value) on the stack isn't exactly the most efficient thing to do-however, that's exactly the thing to expect when compiling with optimization disabled.
Minor correction, because I used to program in 8080 and Z-80 Assembly: Those instructions from the disassembly are more properly referred to as assembly code instructions. Machine code would be represented by nice hex numbers for the opcodes and operands.
Actually Z80 machine language is relatively easy to program by hand, for each opcode there are few bits of prefix and then register addressing etc. Then you convert all the bits in a hex number and done
Early textbooks used to make a distinction between assembly mnemonics and machine code. Looks like those days are long gone and the terms are used interchangeably.
Z80... My computer life started programming a TK-82C at 1982... Good times... 15 Minutes to load a 15 KB program from a cassette tape (after many attempts)...
Since we're being pedantic here about the difference between assembly code and machine code, it doesn't HAVE to use 'nice hex numbers'. Some CPU architectures were more suited to OCTAL representations, and technically, binary would be equally valid! Footnote: Check out the MODR/M byte in x86 code and you'll see how well-suited it is to use octal in this specific case! Having said that, I willingly admit that I'm predominantly a binary and hex man... LOL
The mnemonics directly represent those hex numbers. If he did print out the instructions in hex, you may as well then complain that it's not really machine code because it's not stored electrically in a computer, but printed with ink. It doesn't matter how you represent something, it's the same thing.
this brings me back to my assembly class at university, in 2002. i liked that class a lot, but i've never used it again since i didn't go into a career in embedded
@@tamny9963 - So you think that because someone can't remember something from 20-years ago that they're automatically lying? Or, are you just looking for attention?
My 14 year old self back in 2003 would be extremely excited and thankful if someone would explain machine naguage in such a clear way. Thank you and well done!
great video. When I learnt about programming languages, I always wanted to somewhat understand how computers treat the information we feed them, but looking at assembly on your own is just like *question marks* comparing it side to side to C is really insightful!
Yeah, you're correct; machine code is literally just binary. Otool seems to be a disassembler; it tries to format the machine code into something a little easier for a person to read Trying to read an executable written for an operating system through a hex editor or something would leave all the header information and such in the output; making it a little more difficult to see what's going on
I could be wrong, but the actual machine code would be 1s and 0s of the low level language the CPU uses. The code shown in the video is that code translated into a kind of assembly.
Machine Code is binary ... The nemonic we use LDA ... etc is assmebly language and in hex because 255 ones and zeros take up a ton space on a line ... while ffff doesnt converting from binary to assembly you run an ASSEMBLER and to convert a langauge like C++ you compile it into assembly language then assemble it in to machine code ... because sending ffff is easier to handle than 255 ones and zeros in a line
Remembering my first programming. You looked up the op codes and entered them on a keypad in Hexadecimal. This literally was writing the cpu instructions directly. I miss the 6502.
Way back when I was in school, we had a lab course working with the M6800 (6800, not 68000). I used to write my programs in C then hand-compile them into M6800 assembler. And of course, hand convert that into machine code, which then had to get toggled into the machine.
Hey me too man! Learned Basic on my Apple II and when I wanted to include some heavy-duty math subroutines, I'd POKE the hex code into a memory location then call it when needed. Even on that old 8-bit processor it ran blazingly fast!
The 6502 instruction set was very nice and clear, as was the Z80's to some extent. The intel instruction set was ugly in comparison. ARM assembly language is even worse, it's not meant for humans. Every instruction can do something and can also do something completely different, depending on some weird prefixes. I hope no human being was ever forced to write ARM assembly code.
The compiler emits movb $0,%al because printf() takes a variable number of arguments. The ABI specifies that when calling such functions, %al must contain the number of floating point arguments. There are no floating point arguments passed to printf() in your example, so %al is set to zero.
Which ABI are you referencing? I tried to look for an appropriate OS X ABI that would cover the cdecl calling convention, but nothing I found mentioned this approach to counting floating point arguments.
Too late in this discussion, but the zero inside "movb $0,%al" is just an information, that the printed value should go into stdout stream (in normal circumstances it means that it will be printed on the screen). Anyway, this video and discussion have returned back a lot of memories... And last but not least, If anybody would like to, source codes for printf() are available, but be warned this function is really complicated one, because of a posibility to use variable list of of arguments with all kinds of types, formats and architectures.
I don't know why, but this video is very satsfying to watch as a programmer. It's very logical and makes sense. Like if you'd suddenly have a partial look into a womans brain and actually start understanding something.
Why, I think everyone learns backwards, If they would start at low level which is cold hard logic memory movement and work up the chain I believe they would learn how to program much faster. Lang like basic trigger bad habits that become hard to break such as never clearing your memory or initializing variables and things like C++ have turned into a cluster fuck due to the Total Over use of OPP everyone seems hell bent on these days. I would suggest if someone wants to learn to code go back to DOS, Get Turbo C and use that, It was a great lang with great documentation to help you telling what every single command did ect.
If he tried to learn Java before ASM hes going to be crying like everyone else on this video is about how hard ASM is to understand when its WAYYYYYYY easier to understand then any lang I have ever used including Basic. I think the Fail comes with most people because they don't comment their code and lose track of whats what but its simple top down programming that can be traced with ease.
I know I will catch a mess load of flak for saying it because I still get a lot of flak for using it from time to time but I honestly believe DarkBasic is one of the better things for a programmer to start in.... Hear me out before yall hate on me. Starting off a programmer wants results, ASAP. With darkbasic its as simple as Sync On Make Object Cube(1,10) Position object (1,0,0,0) Position Camera (0,100,0) Point Camera (0,0,0) do control camera using arrow keys 0,1,1 loop wait key That code above will draw a cube on the screen and point the camera at as well as allow you to look around with the arrow keys, it which is a great starting point for most hobby programmer since the will feel the excitement going right away with a 3d object they can manipulate. This same code in say C++ for instance would literally take hundreds or thousands of boiler plate code just to setup the engine to draw the cube and accept the input. Look into darkbasic. Its old but its effective and its fun as all hell to toy with.
I started on a TRS 80 Model 1 with 2k ram and a cassette tape player. Basic. Then a Commodore 64. Commodore Basic. Then C on my BSD systems at home, took online local community college courses for Visual basic .net and C - grew tiresome. Right about then it became evident that code monkeys had to compete with $3/hr dev teams in India. Writing on the wall was that the money would be in Java. I stuck with sys admin needs; Perl and C. FEAR of Java, FEAR of having to think about this stuff, FEAR of actually applying what I've learned in school... NEVER learned these basics. (been TAUGHT it many times!) Never formed this solid foundation. In other words; I can't code to save my life...but I have worked for years making money doing it. Flying by the seat of your pants every day...making it work, doing the seemingly impossible. There is reward in that, at least. It feels good to actually DO this stuff in the real world for real world paying client needs. I can't even last in a programming conversation for two minutes. My point? - Just *do* *it*.
When I was a newbie programmer back there in 2000, playing around with assembler, memory and registers really helped me to get a grasp of what pointers and references are.
This is a valuable analysis. Knowing what’s going on at this level I think is fundamental to truly understanding computing. And code and architecture. Great.
This brings me good memories from my first semester in college when I worked with MIPS assembler code. Probably one of the most interesting things I have studied so far.
Many thanks for a wonderful and insightful tutorial. I have been writing code for more years than I care to remember but this is by far the best explanation of how machine code relates to back to it's source code. Fantastic video.
I appreciate your effort to make this teaching video to share what you know and honestly say don't know to things you don't know. Well done. I'm not sure either what's the point of moving the contents of eax register on to stack.
so it can be formatted loaded and printed ... it has to strip the format out of the print ... the the data pointer then the data then print it ... and a stack is the best place to do that from as you can shift left and grab the format ... and then shift left and set format up then load the next chunk and shift left ... read data pointer ...and shift left ... load data .. shift left and finally print ...
I loved every second of this. Ive been recently learning C++ and viewed the asembly code and was lost this helped so much to see whats actually happenning
I miss programming in assembly. The first code I ever wrote was 6502 Assembly on an Atari 600xl. I also programmed in the following assembly languages over the years: 8088, 80286, IBM 360, R10000 and MIPS. After 20+ other languages over the years, assembly is still the one I liked best. It just felt natural. When I first learned C and was using the Turbo C compiler, I often wrote the function headers and variable declarations in C, and just inlined the guts in assembly. Those were the days...
I don't. At all. I wrote Railsounds II in Assembly because the processor (Microchip 17C42) had 2k code space and 160 bytes of ram. It ran at 4MIPS and at the time (93) was the fastest micro on the market. I couldn't wait until I could rewrite in C. Which we did. The hardest part was convincing Neil Young, my client, that we needed to do that. The rest is history. Over a million units sold.
Agreed. Very creative, very obedient. CPU does exactly what you tell it; nothing more, nothing less. If errors exist nobody to blame but yourself; and maybe the standard libraries which for assembly are minimal and usually just the startup code. I also wrote assembly for Honeywell DPS 8 mainframe; now THAT was programming!
@@thomasmaughan4798 Not so much on the obedient part. I remember seeing in a presentation that intel's 486 was the last x86 processor to simply run the instructions, in their order. After that came the out-of-order execution optimisations. And things like processing both outcomes of a check in the time the required value is fetch from memory and then simply using the correct outcome. So, nowadays, you don't really know what and how are things actually executing inside of a processor. Sometimes a less optimized code can be better optimized by the CPU optimzer.
I found your teaching so understandable by non programmers and beginners. I dont know to do programming and wanted to learn. I have interest in c programming and now assebly. Thank you for video you are great teacher
rax is a 64-bit register eax is a 32-bit register which refers to the lower 32-bits of rax ax is a 16-bit registers which refers to the lower 16-bits of eax ah is an 8-bit register which refers to the upper 8-bits of ax al is an 8-bit register which refers to the lower 8-bits of ax gcc -S -masm=intel program.c ATT syntax is ok, but I prefer Intel personally... you’re welcome and thanks for the good video!
@@wh7988 Pick a processor, read the documentation, the documentation will tell you what commands there are and what they do. You can look up youtube videos or books for the processor and how to program in assembly for the processor. The class I am taking right now has us using code-warrior (ide) for programming the HCS12 (mircro-controller). I am assuming going with an arms processor would be a better idea though, they are more popular.
School! A good (but expensive) Assembly book is "Assembly Language" by Kip Irvine. You can use Visual Studio, admittedly a "long" process to set up, to write, run, and debug MASM. Give it a go.
Really enjoy your videos, started my programming journey, if you will, about 5 years ago with the idea of wanting to make video games. i later found assembly programming and electronics engineering FAR more interesting than game design. I have been learning 8086 ASM on DosBox lately hoping i can get enough experience to understand how computers work entirely, i am currently in the process of learning how different IC's work on a breadboard and hope to build my own 8bit computer soon. Thanks for getting me started on such a fun hobby i hope to make my job someday, keep up the excellent videos! Hope to see your channel continue to grow :)
Maybe he figured out that using machine language in software makes your product un-portable. There are many reasons *not* to write in assembler. And there are distinct instruction sets for different CPU architectures, so you can learn one ISA (inst set architecture) or you can learn all of them; compilers *do* have their advantages. All digital computers work the same way (registers, storage, interrupts, etc) but the devil's in the detail level you can't avoid in assembler. Everybody should *know* what compilers do and appreciate that today's compilers (I've been doing this for 40 years) are very, very good. You should also understand the overhead of interpreted languages like Java & Python (and the list goes on) before you make an implementation/design decision. Knowing the heart of how most of your customers' machines work (x86_64 for {lap,desk}tops, ARM ISAs for phones/tablets) is a valuable datum, should motivate us all to write code that's as efficient as possible. I still check my assembler output most of the time, but I'm about ready to retire ... probably an "old skool" type. But today's typical bloatware sucks. *Fight it.* Take pride in your work, know what you're delivering :-) _and good luck on your autodidactic journey!_
8:15 I believe that line puts tge x value to the aex, where it can set a flag. The next line sets the flag, and the next line uses it to determine wether to jump or not.
you can tell the presenter really has a finite grasp on the information when he says 'i'm not sure what this other thing is' but hey i'm really glad you enjoy this hobby of yours
I'm studying IT, and coursing a few subjects that include C, C++, Assembler and Pentium processors architecture. And this is one of the best, and more interesting video that I've seen. Great work!
In my last year of college. I now finally understood this! Thank You! What I realised is that the teaching (at my was good but they didn't put enough efforts to link this to higher level of programming we were practising daily. But now it makes sense. Thank you again!
Almost a year late... On x86-based computers, eax is usually for return values. Don't forget that printf is not void, it returns a length. The compiler is a macro-assembler so it stores it on the stack anyway. What you can do is ignore the stack & use only the registers ebx, ecx & edx to store x, y & z, so in theory, it should execute faster. If i remember well, if you only want 8 bits, you can use even bx, cx & dx, or even b, c ,d
Simple and interesting explanation, I have experience with assembler, and C ++ is my main language, but I tried to watch this like i'm a beginner. And in my opinion, that was very easy to understanding. Big respect!) Sry for my bad eng)))0
Thank you for a nice explanation. It's great that the compiler generates so clean code. Of course it could do better, that is the registers should be used to x,y and z variables, but it probably would with optimisation option. One remark: The addresses of x,y and z differ by 4 (0xc-0x8=4 0x10-0xc=4, since the long type is used, so each variable takes four bytes.
Oh man! This is awesome. This takes me way back to early software engineering classes at Purdue in the 90s. We used C. Great to understand how it compiles into machine code!
This brings back the nightmares from writing mainframe assembler in college in the mid 80's. It was frustrating, fun, gave me an excellent appreciation for what's going on behind the scenes, and here I am 40 years later and damned thankful I haven't ever needed to program in assembler since ♥.
gcc is likely an symlink to clang on 2015 macbooks. otool is specific to OSX's mach-o executable format. On Linux, you'd use binutils' objdump with `-d` to disassemble. The line you drew to separate the assembly separates the "prolog" which backs up the previous frames' base pointer onto the stack, then sets the frame pointer to this stack pointer so that the current stack pointer can be advanced for the call to printf (think of the base pointer as being the base of the current stack frame, while the stack pointer is adjusted for local variables, and will be the future base pointer for child stack frames, like printf in this case). The movb %0x0, %al is to specify that the variadic function printf is not receiving any floating point arguments as per the sys-V ABI. I can't work out what's being stored at -0x4(%rbp) or -0x14(%rbp) though, and why 32 bytes was allocated to the current stack frame (the stack needs to be 16 byte aligned on x86 to invoke calls, but idk why it didn't just allocate 16 bytes since we only need room for 12 bytes, rather than allocating 32 bytes (0x20 == 32)). I wonder if the assembly had stack canaries (I seem to recall OSX adding them) and the author removed some code, but not all of it (missing -0x4(%rbp) or -0x14(%rbp))? %eax would be retaining the return code from printf at that point, but based on the source code shown, it's never used so there's no point to repeatedly only write it to the stack and never check it. Otherwise, I don't think this is actually the disassembly from the source code shown (close, maybe a slide modification where the author removed some of the assembly, but not all of the parts they should have). The epilog is omitted, but the compiler may have noticed that there's no return from main(). The prolog is still needed otherwise printf() and functions it calls cannot allocate things on the stack correctly. Well, just the stack pointer adjustment, the frame pointer on x86 was meant for debugging, but is not used with optimizations turned on (and you'd probably just want to use DWARF tables to unwind the stack anyways, not as fast at unwinding, but faster happy path, smaller code, less instruction cache pressure, external to program). Great video though!
Learning little by little. This is a great explanation! Note: Everytime I see your name, I can't help myself but remember the song "Maneater" by Hall & Oates. It would be a perfect fit if you change the chorus to "He is Ben Eater" 😆
I also check the assembly output of my c++ program to check the efficiency of the compiled code. Also sometimes I'm curious to see how will the compiler optimize polymorphed codes (vtables, etc)
Thank you so much for this tutorial. Thanks to you i understand those concept now. Please make more of those C vs Assembly Tutorials. You are explaining it so good :D
I've always regarded C as a sorts of macro generator. You can almost see the result in asm when you write C. Although with any level above O1, things get totally too much for a human to read, unless you wrote the compiler.
Excellent simple explanation. I will refer to your video in a comparison discussion between classical CPUs and Quantum Computers. For those commenting on the efficiency of the assembled code, (correct me if I am wrong) the C compiler options did not seem to specify optimization options. Optimized code can be more difficult to relate to the original C code and would not have helped the simple explanation. What you should expect with using the optimizer is that registers would be used instead of memory where possible and unused code removed (among other things). Before optimizers were standard, we used to deliberately assign registers to key C variables by using the "register" C modifer.
