I just want to say thank you for these videos. I've researched dozens of online comp sci videos and tutorials, and none of them come close to the clarity, elegance, and thoroughness of explanation I find in your vids. I've really come to rely on them a lot.
this was way ahead of its time. Not the information itself but the quality and dedication and kind of content which was being provided. Great explaination brian will
To be clear, I'm legitimately not an authority on these details, but calling foul when your objections are at best arguable just isn't very helpful. For future corrections, please keep in mind the audience. Spreading misinformation is bad, for sure, and I make plenty of mistakes, but often I elide over details for a reason.
OMG I just found your channel today! I am a graphics programmer and even though I am aware of a lot of these things, I feel I learnt something just because of how well presented and interesting your videos are. And even if it is a known topic, they are an absolute joy to watch! Thank you for these!
There's a mistake in minute 12:56 : "The figure to the right should flip the memory while keeping the index the same. Example: [0A => 'a+3 '], [0D => 'a' ] "... it was correct in the previous slide, but wrong in this slide. Thanks!
I was studying most of this last semester in my college and your small class is way more intuitive, congratulations! Also, I love how they used Gulliver as a mnemonic jab at the order of bits in memory.
I appreciate any corrections, but I don't think I was wrong in these cases. I never said Intel created the first 64-bit x86 processors. The byte size issue is very arguable: did the industry adopt the 360 standard because it was popular or because it was a sensible choice that also happened to be popular? Besides, I believe my wording was "mainly because 8 is a power of two and not too large". You're assuming I don't have the right story because I'm not necessarily giving the full story.
Yes, IA-64 was the non-x86 compatible and now defunct Itanium, x86-64 and x64 are actually informal names for 64-bit x86. The official AMD name is AMD64. The official Intel name is EM64T. Everyone else just call it x86-64 or x64.
Thank you for your videos. I have been programming for a while but I had always neglected to actually think about HOW the computer executes my instructions. This was very interesting.
I'm not saying you actually weren't saying this, but, to clarify, the intuitiveness of big-endian vs little-endian is about more than just the reading left-to-right vs right-to-left convention. What matters more is the fact that we say and read the big end FIRST and the little end LAST. Interestingly, numerals are written with the big end on the left and the little end on the right in Arabic, just as in English, meaning that that, even though numbers are written in the same physical direction in both languages (when written with Hindu-Arabic numerals), the convention is big-endian in English, and little-endian in Arabic. Funnily enough, Arabic, Sanskrit, German, and archaic English (as well as modern English for 13-19, noting that "-teen" means "ten"; "-ty" means "groups of ten", FYI) all use the little-endian convention in speech specifically for 2-digit numbers, with the big-endian convention only applying with hundreds, thousands, etc. Generally, whatever convention is used with smaller numbers is the older convention (except sometimes with very small numbers like 0, 1, and 2, and with other special numbers), since, for the most part, bigger numbers used to be very rare (so the conventions for how to say them were ad hoc and easily changed) and bigger and bigger numbers have become more and more commonly mentioned over time, with new standards developing and growing more entrenched.* Given that we cultural descendants of Europeans often call them "Arabic numberals", the fact that Arabic uses little-endian numerals and the fact that Arabic and disparate Indo-European languages (FYI Arabic is not Indo-European) say the ones' place before the tens' place combine to form a strengthened suggestion that maybe a lot of Eurasia used to use a little-endian convention in saying numbers. However, even if that's true, it's not why Arabic uses a little-endian convention. That's because they're actually HINDU-Arabic numerals, and the Brahmic scripts are all written left-to-right, and, despite the fact that Sanskrit said the ones' place before the tens' place, their numerals were written with a big-endian convention, which meant big end on the left, little end on the right, since they wrote left-to-right. (I've confirmed that some pictures of ancient Indian artifacts on Wikipedia When the Arabs (and Islamized Persians, notably) adopted the Indian system of writing numbers, I guess they must have preserved the physical direction of the writing, which the Europeans also preserved when they adopted it from the Arabs. Thus, an originally big-endian convention became little-endian and then big-endian again. *One example of this is how so many languages that used to use other bases or mixed bases, like 20, 5, 12, or 60, now use essentially base 10 for large numbers (look up French, Danish, Wolof, and Mesoamerican languages), even if they have remnants of other bases in smaller numbers, and many languages actually borrow a number system from a completely different language to count large numbers, like people using Spanish instead of their native Native American language to count, or languages that only have number up to 2 or 4 or something and have all the larger numbers borrowed from a neighboring language. For example, I believe usually uses Chinese numeral words (called the on'yomi, or Sino-Japanese pronunciation, of the numerals) for any number larger than 10, and usually only uses native Japanese numerals (kun'yomi) for numbers smaller than 10, and not in all situations.
great..awesome lecture..thanks a lot.. I am totally addicted to your videos(Javascript,OS,C etc)..you are a awesome teacher .. just one request -Could you please speak a little bit slowly Waiting for more lectures .
+deen john Check out the gear icon in the player window. Clicking that brings up a menu which has a "speed" sub-menu. You can slow the video down to 0.5 or 0.25 speed. I like to do this for particularly dense sections because it lets my brain do more processing per word and sometimes this leads to better understanding and retention.
13:11 Little endian is neither "arbitrary" nor does it "not make sense with modern hardware". First off, the picture suggesting that CPU registers in little endian machines use big endian is wrong. The best example to prove that are bitshift operations in assembly. The second best example are probably SIMD registers. Secondly, dereferencing the memory location of an unsigned long long as a 32 bit integer truncates the value correctly. That's not easily achievable with big endian machines...
This is very interesting, I always thought the OS or something would manage the cache, now I looked more into it after this and see that it's literally a hardware implementation. Cool!
Tirando o fato de um leve erro (eu acho que é um erro) em 13:13, esse maluco é um monstro! Quanto conhecimento em um só vídeo. Passei horas fazendo anotações! Parabéns e obrigado pelo conteúdo.
Wonderful video, oldballs here, actually the licensing agreements go back to the late 70’s as a prerequisite for government contracts. intel has weaseled all the other manufacturers out of x86 land but amd, cyrix, ibm, national semi, shit even NEC was a licensee! Again great video, I have always struggled with computer science and your videos are concise and illuminating!
Is an Arduino a good way to get started learning low-level programming and working with hardware? I'm asking for a friend. This particular friend happens to have a very particular set of skills. Namely, that he can serve as a substitute for myself when asking embarrassing questions, such as if an Arduino is a good way to get started learning low-level programming and working with hardware? So my friend would like to ask that?
Yes it’s a good way to learn about low level programming. I’d also recommend Ben Eater’s channel as well as Nand2Tetris course on Coursera(where it’s offered for free)
Amazing series but I personally disagree about big vs little endian :) Big endian makes more sense for HUMANS to read them as numbers going left to right. The advantage of little endian however is that the least significant digit of ANY size number is always in the same place. So code operating on numbers can start at the same index and grow in the same direction regardless of storage class. This yields a lot of benefits especially in instruction decoding like branches that jump near or far. Personally don't like x86 as an ISA or anything else really but i do feel like they (and 6502) got this right.
Little-endian is useful for data types that don’t use the full byte or word. Little-endian ensures that the first bit in the byte is meaningful and not just 0 padding.
Yes :D You should consider uploading them as a whole, like you already do :) Great tutorials! :D Even though you cover the same topic, you can always learn something new you haven't mentioned yet :) I really enjoy watching your videos =D Keep it up :) Always happy when I see a new video of you ^.^
10:50 - This is inaccurate. It was *AMD* that announced x86_64 (officially with an underscore) and it was later called AMD64 by partners. Then, after a cross-licensing agreement, Intel released their own x86_64 implementation in the Core processors, and they called it EM64T, which Microsoft later rebranded x64.
@13.08 One thing I thought of, an argument for little endian: when converting a large numeric data type to a smaller one -- assuming you know the 'start addr' of it in ram, you only need to take as many bytes as needed starting from that address. If it were in big endian, you would be required to know the *original size*, and take the bytes from the end. Is this valid? Casts to smaller data types would be more efficient because no calculation (base + original_size) is needed, you simply take as many bytes as desired - and you are not required to know the original size of the data. (?) edit: I'm not sure how useful this is, but it seems to make sense - especially if dealing with raw pointers, where you are not given the 'original size' of the data.
+Andrew Buckau Yes, little-endian does have a few efficiency advantages in certain cases. Not sure if what you describe was one of the Intel's considerations. My argument though is that big-endian is definitely the more 'natural' choice, despite what I've seen argued in many places that both are equally sensical.
I do not understand the "big-endian vs little-endian" part. On the figures at 11:05, the "OA" is copied to "a+3" address in little-endian order, however, at 13:00, the "0A" is copied to "a" address. The arrows seem to make sense, though. Is it just a mistake or am I missing some point? Thank you!
Yeah, the diagram is messed up at 13:00 for little-endian. The arrows are correct, so the bytes in memory should read 0D 0C 0B 0A. In big-endian, the most-significant register byte 'corresponds' to the lowest memory address. In little-endian, the least-significant register byte ' corresponds' to the lowest memory address.
I was just trying to find out what different parts of the computer did and how they interact with each other. I stopped understanding anything after about 4 minutes and 30 seconds. I think I clicked on the wrong video. @.@
Dude, don't get me wrong. I like your videos. But since I'm a computer science engineer. I found several mistakes in the video. This is just one. Consider this as a feedback. Wanna another one?, You said 1 byte is standardized as 8 bit because of 8 is power of 2. What if I say, that is may be a reason but not the actual reason. (hint:IBM360)
I just want to say thank you for these videos. I've researched dozens of online comp sci videos and tutorials, and none of them come close to the clarity, elegance, and thoroughness of explanation I find in your vids. I've really come to rely on them a lot.
Your channel is a gold mine on TH-cam. Thank you.
The quality of this content is way ahead of its time.
this was way ahead of its time. Not the information itself but the quality and dedication and kind of content which was being provided. Great explaination brian will
this is the first time I've ever found any one explain how a computer works. instead of they all try to explain how programs work
To be clear, I'm legitimately not an authority on these details, but calling foul when your objections are at best arguable just isn't very helpful. For future corrections, please keep in mind the audience. Spreading misinformation is bad, for sure, and I make plenty of mistakes, but often I elide over details for a reason.
What do you expect, you're intimidating egos here...
You know, if I correct you on something, then it must mean I'm smart, right ? LOL
Great videos !
THANK YOU SO MUCH! Please please keep making videos Brian they're so rare on TH-cam 🙏
OMG I just found your channel today! I am a graphics programmer and even though I am aware of a lot of these things, I feel I learnt something just because of how well presented and interesting your videos are. And even if it is a known topic, they are an absolute joy to watch! Thank you for these!
There's a mistake in minute 12:56 : "The figure to the right should flip the memory while keeping the index the same. Example: [0A => 'a+3 '], [0D => 'a' ] "... it was correct in the previous slide, but wrong in this slide. Thanks!
i didnt even notice that mistake ^^
I was studying most of this last semester in my college and your small class is way more intuitive, congratulations!
Also, I love how they used Gulliver as a mnemonic jab at the order of bits in memory.
I appreciate any corrections, but I don't think I was wrong in these cases. I never said Intel created the first 64-bit x86 processors. The byte size issue is very arguable: did the industry adopt the 360 standard because it was popular or because it was a sensible choice that also happened to be popular? Besides, I believe my wording was "mainly because 8 is a power of two and not too large".
You're assuming I don't have the right story because I'm not necessarily giving the full story.
Yes, IA-64 was the non-x86 compatible and now defunct Itanium,
x86-64 and x64 are actually informal names for 64-bit x86. The official AMD name is AMD64. The official Intel name is EM64T. Everyone else just call it x86-64 or x64.
"typical for servers to have 8 or more cores each"
Threadripper: "Am I a joke to you?"
So.Much.Knowledge.
Thank you for your videos. I have been programming for a while but I had always neglected to actually think about HOW the computer executes my instructions. This was very interesting.
I'm not saying you actually weren't saying this, but, to clarify, the intuitiveness of big-endian vs little-endian is about more than just the reading left-to-right vs right-to-left convention. What matters more is the fact that we say and read the big end FIRST and the little end LAST. Interestingly, numerals are written with the big end on the left and the little end on the right in Arabic, just as in English, meaning that that, even though numbers are written in the same physical direction in both languages (when written with Hindu-Arabic numerals), the convention is big-endian in English, and little-endian in Arabic.
Funnily enough, Arabic, Sanskrit, German, and archaic English (as well as modern English for 13-19, noting that "-teen" means "ten"; "-ty" means "groups of ten", FYI) all use the little-endian convention in speech specifically for 2-digit numbers, with the big-endian convention only applying with hundreds, thousands, etc. Generally, whatever convention is used with smaller numbers is the older convention (except sometimes with very small numbers like 0, 1, and 2, and with other special numbers), since, for the most part, bigger numbers used to be very rare (so the conventions for how to say them were ad hoc and easily changed) and bigger and bigger numbers have become more and more commonly mentioned over time, with new standards developing and growing more entrenched.*
Given that we cultural descendants of Europeans often call them "Arabic numberals", the fact that Arabic uses little-endian numerals and the fact that Arabic and disparate Indo-European languages (FYI Arabic is not Indo-European) say the ones' place before the tens' place combine to form a strengthened suggestion that maybe a lot of Eurasia used to use a little-endian convention in saying numbers. However, even if that's true, it's not why Arabic uses a little-endian convention. That's because they're actually HINDU-Arabic numerals, and the Brahmic scripts are all written left-to-right, and, despite the fact that Sanskrit said the ones' place before the tens' place, their numerals were written with a big-endian convention, which meant big end on the left, little end on the right, since they wrote left-to-right. (I've confirmed that some pictures of ancient Indian artifacts on Wikipedia When the Arabs (and Islamized Persians, notably) adopted the Indian system of writing numbers, I guess they must have preserved the physical direction of the writing, which the Europeans also preserved when they adopted it from the Arabs. Thus, an originally big-endian convention became little-endian and then big-endian again.
*One example of this is how so many languages that used to use other bases or mixed bases, like 20, 5, 12, or 60, now use essentially base 10 for large numbers (look up French, Danish, Wolof, and Mesoamerican languages), even if they have remnants of other bases in smaller numbers, and many languages actually borrow a number system from a completely different language to count large numbers, like people using Spanish instead of their native Native American language to count, or languages that only have number up to 2 or 4 or something and have all the larger numbers borrowed from a neighboring language. For example, I believe usually uses Chinese numeral words (called the on'yomi, or Sino-Japanese pronunciation, of the numerals) for any number larger than 10, and usually only uses native Japanese numerals (kun'yomi) for numbers smaller than 10, and not in all situations.
great..awesome lecture..thanks a lot..
I am totally addicted to your videos(Javascript,OS,C etc)..you are a awesome teacher ..
just one request -Could you please speak a little bit slowly
Waiting for more lectures .
+deen john Check out the gear icon in the player window. Clicking that brings up a menu which has a "speed" sub-menu. You can slow the video down to 0.5 or 0.25 speed. I like to do this for particularly dense sections because it lets my brain do more processing per word and sometimes this leads to better understanding and retention.
13:11
Little endian is neither "arbitrary" nor does it "not make sense with modern hardware".
First off, the picture suggesting that CPU registers in little endian machines use big endian is wrong. The best example to prove that are bitshift operations in assembly. The second best example are probably SIMD registers.
Secondly, dereferencing the memory location of an unsigned long long as a 32 bit integer truncates the value correctly. That's not easily achievable with big endian machines...
This is very interesting, I always thought the OS or something would manage the cache, now I looked more into it after this and see that it's literally a hardware implementation. Cool!
Tirando o fato de um leve erro (eu acho que é um erro) em 13:13, esse maluco é um monstro! Quanto conhecimento em um só vídeo. Passei horas fazendo anotações! Parabéns e obrigado pelo conteúdo.
Wonderful video, oldballs here, actually the licensing agreements go back to the late 70’s as a prerequisite for government contracts. intel has weaseled all the other manufacturers out of x86 land but amd, cyrix, ibm, national semi, shit even NEC was a licensee! Again great video, I have always struggled with computer science and your videos are concise and illuminating!
I wanted to move comments to the playlists, but apparently playlists can't have comments.
Is an Arduino a good way to get started learning low-level programming and working with hardware? I'm asking for a friend. This particular friend happens to have a very particular set of skills. Namely, that he can serve as a substitute for myself when asking embarrassing questions, such as if an Arduino is a good way to get started learning low-level programming and working with hardware? So my friend would like to ask that?
Yes it’s a good way to learn about low level programming. I’d also recommend Ben Eater’s channel as well as Nand2Tetris course on Coursera(where it’s offered for free)
You are so good at this. And your voice is pleasant. I wish you’d keep making these :)
Very good video. Took 3.5 pages of notes from it😎Thank you very much!🎉 Keep up the good work.
Amazing series but I personally disagree about big vs little endian :) Big endian makes more sense for HUMANS to read them as numbers going left to right. The advantage of little endian however is that the least significant digit of ANY size number is always in the same place. So code operating on numbers can start at the same index and grow in the same direction regardless of storage class. This yields a lot of benefits especially in instruction decoding like branches that jump near or far. Personally don't like x86 as an ISA or anything else really but i do feel like they (and 6502) got this right.
This channel is a gem, thanks!
10:45, It's AMD who did x86-64, Intel's 64bit arc. name is IA-64 (not compatible, nor similar). Then Intel licensed x64 from AMD.
Little-endian is useful for data types that don’t use the full byte or word. Little-endian ensures that the first bit in the byte is meaningful and not just 0 padding.
Excellent introduction.
Yes :D You should consider uploading them as a whole, like you already do :) Great tutorials! :D Even though you cover the same topic, you can always learn something new you haven't mentioned yet :) I really enjoy watching your videos =D Keep it up :) Always happy when I see a new video of you ^.^
Great video =D! & your tutorials are awesome and correct :) Thanks for the work you put into this!
10:50 - This is inaccurate. It was *AMD* that announced x86_64 (officially with an underscore) and it was later called AMD64 by partners. Then, after a cross-licensing agreement, Intel released their own x86_64 implementation in the Core processors, and they called it EM64T, which Microsoft later rebranded x64.
Should just have a byte ordering that switches between little and big at an interval
Your videos are absolutely amazing man
"Hand-held" lol
YOURE VIDS ARE SO FUKKIN GUD BRIAN, , , , WE MISS U
what do mean "WE MISS U"?
He's not with us anymore :(
he'll live on in this work...
thanks Brian 😇
@13.08 One thing I thought of, an argument for little endian: when converting a large numeric data type to a smaller one -- assuming you know the 'start addr' of it in ram, you only need to take as many bytes as needed starting from that address. If it were in big endian, you would be required to know the *original size*, and take the bytes from the end. Is this valid? Casts to smaller data types would be more efficient because no calculation (base + original_size) is needed, you simply take as many bytes as desired - and you are not required to know the original size of the data. (?) edit: I'm not sure how useful this is, but it seems to make sense - especially if dealing with raw pointers, where you are not given the 'original size' of the data.
+Andrew Buckau Yes, little-endian does have a few efficiency advantages in certain cases. Not sure if what you describe was one of the Intel's considerations. My argument though is that big-endian is definitely the more 'natural' choice, despite what I've seen argued in many places that both are equally sensical.
awesome work..
Excellent. Nicely done!!!
My favorite computer is a toaster...
I do not understand the "big-endian vs little-endian" part. On the figures at 11:05, the "OA" is copied to "a+3" address in little-endian order, however, at 13:00, the "0A" is copied to "a" address. The arrows seem to make sense, though. Is it just a mistake or am I missing some point? Thank you!
Yeah, the diagram is messed up at 13:00 for little-endian. The arrows are correct, so the bytes in memory should read 0D 0C 0B 0A.
In big-endian, the most-significant register byte 'corresponds' to the lowest memory address.
In little-endian, the least-significant register byte ' corresponds' to the lowest memory address.
great video, thank you
thank you
why did you stopped making videos?
mr Will is no joke!
Excellent
From Computer Class II :)
The interesting thing is most of this video would have been valid 30 or more years ago.
thank you a lot!!!
hm there is a repetition at 4:00, the same phrase is said twice
GOooooood
hey why did you disable comments on your latest video? :)
I was just trying to find out what different parts of the computer did and how they interact with each other. I stopped understanding anything after about 4 minutes and 30 seconds. I think I clicked on the wrong video. @.@
13:13 there is a big mistake in picture representing little-endian
Please use a pop filter in front of your microphone, or at least do some audio post processing.. I really want to listen but it's too hard to listen..
Note: NOT ADHD friendly lmao
Dude, don't get me wrong. I like your videos. But since I'm a computer science engineer. I found several mistakes in the video. This is just one. Consider this as a feedback.
Wanna another one?, You said 1 byte is standardized as 8 bit because of 8 is power of 2. What if I say, that is may be a reason but not the actual reason. (hint:IBM360)