*A reminder: Do not reply to **_this post_** if you want me to see your comment. Post your words as a new comment, not as a reply, unless you are addressing the contents of **_this comment_** specifically. KZbin does not show creators new replies, it only shows new comments. If you reply here **_I will not see it_** unless I manually check for it.* If you are addressing a comment someone wrote, then you _should_ reply it, though. ---- You may have seen parts of this video previously in my other videos, even if those videos were published many years ago. Either this means I am a time traveler, or this video has been in the works for a long time. In any case, I decided to finally push it to production & publication. Because the topic is so incredibly broad, I decided to limit it to register-to-register move instructions only. If we allow other kind of moves, we get _plenty_ of new use-cases. The x86 instruction set is not small by any measure. For example, we have VPGATHER{Q,D}D / VGATHER{D,Q}P{S,D} which can perform up to four 64-bit loads from completely unrelated memory addresses in a single instruction, and the VPSCATTER{Q,D}D / VSCATTER{D,Q}P{S,D} which do the same with stores instead of loads. There are also VPMASKMOV{D,Q} which work much like the BLEND operation (sieve) but with memory. Then there is the LEA instruction which has already existed since 8086. It can do not only a load of a constant into a register, but it can also do addition and multiplication in the same instruction. It was made even more useful in 386 which added scaled-index addressing, so much so that pretty much every compiler utilizes this instruction for multiplications of constant values. IA64 sadly never became popular, because it was thought that the architecture puts too much responsibility on compiler developers. But even today, as intelligent as the x86 processors are with their register renaming and multi-insn-per-cycle pipelinings, there are several instructions in the instruction set that are designed to improve performance, but which compilers _never_ generate without explicitly being asked to. For example, all the prefetch instructions. And the whole thing about dozens of instructions that only differ in the type hinting… Yeah. That is the role of compilers to choose from. *Nitpicking:* All this study about instruction names concerns _language,_ i.e. culture, not CPU design. It is just what Intel decided to _call_ certain operations. They could have had “MOV EIP, 1234h” instead of “JMP 1234h”, and they could have had “MOV AX, BX+SI” instead of “LEA AX, [BX+SI]”, and they could have had “MOV EAX, SIG BL” instead of “MOVSX EAX, BL”, and they could have had “MOV MM1, MM0” instead of “MOVQ MM1, MM0”, and they could have had “MOV GDTR, [label]” instead of “LGDT [label]”, and they could have had “MOV [++ESP], EAX” instead of “PUSH EAX” … without changing a single thing in the CPU design. But they did not. I’m not criticising… much. I am just documenting. :-) *Errata:* - I neglected to mention that the number of XMM registers was initially only 8. When AVX was introduced, it extended the number to 16, the width to 256 bits and name to YMM. - I got the B/C and D/E wrong way around in my BC and DE pairs. B is higher, C is lower; same for D and E. Thanks theALFEST! - There _is_ a byte-size shuffle instruction, PSHUFB. I also missed PSHUFW. Thanks Jan De Kock! And of course I acknowledged on screen that I neglected VSHUFF{,I}{32x4,64x2}. - Didn’t list VPBROADCAST{B,W,D,Q} and VBROADCASTI{32x{2,4,8},64x{2,4},128}, which are integer versions of the broadcasts, or VBROADCASTSD, which was added in AVX-512. - Didn’t list VPERM{B,W,Q,ILP{S,D},{I2,T2}{B,W,D,Q,PS,PD}}, even though I did VPERM{I,F}128 oddly enough. - Didn’t list VPMOV{,S,US}{QD,QW,QB,DW,DB,WB} which do integer conversions from large to small, much like the {V,}PACK{SS,US}{DW,WB} that I did mention. - Didn’t list {V,}PMOV{S,Z}X{BW,BD,BQ,WD,WQ,DQ} which do integer conversions from small to large, being vector parallels to MOV{SX,ZX} which I did mention. - Didn’t list VPMOVM2{B,W,D,Q} and VPMOV{B,W,D,Q}2M, which do conversions between mask registers and XMM registers. - Didn’t list {V,}P{SRA,SRL,SLL}{V,}{W,D,Q} which do bit-shifts, but compilers (ab)use these as a combined mov & clear. - Didn’t list {V,}PALIGNR or VALIGN{D,Q} which is like a combined SRL (shift right) and UNPCKL (interleave). - Didn’t list any instructions that do conversions between floats of different sizes or conversions between floats and ints, which at least on AVX-512 are possible to do without memory operands. - Didn’t list conditional moves: CMOVxx or VPTERNLOG{D,Q}, even though I did list blend instructions which also do conditional moves. *Instructions that I did list:* - MOV: Copy entire Ⓑ (same size) - MOV{SX,ZX}: Copy entire Ⓑ (into larger size) with sign/zero extension - {V,}MOV{D,Q}, KMOV{B,W,D,Q}, MOVDQ2Q, {V,}MOV{SS,SD}, {V,}MOV{{A,U}{PS,PD},DQ{A,U}{8,16,32,64}}: Copy from Ⓛ to Ⓛ - {V,}PINS{B,W,D,Q}: Insertion of ⓁⒷ into ⓈⓋ - {V,}PEXTR{B,W,D,Q}, {V,}EXTRACTPS: Extraction of ⓈⓋ into ⓁⒷ - {V,}INSERT{I,F}{128,32x4,32x8,64x2,64x4}: Insertion of ⓁⓋ into ⓈⓋ - {V,}EXTRACT{I,F}{128,32x4,32x8,64x2,64x4}: Extraction of ⓈⓋ into ⓁⓋ - {V,}INSERTPS: Insertion of ⓈⓋ into ⓈⓋ with clearing of ⓈⓋ - {V,}BROADCAST{SS,F{32x2,32x4,32x8,64x2,64x4,128}}: Copy ⓁⓋ into all parts of Ⓥ - {V,}MOVS{L,H}DUP: Subdivided broadcast - {V,}PBLEND{,M}{W,D,PS,PD}: Sieve Ⓥ into Ⓥ - {V,}PUNPCK{L,H}{BW,WD,DQ,QDQ} and {V,}UNPCK{L,H}P{S,D}: Interleave Ⓛ or Ⓗ of two Ⓥ into single Ⓥ - {V,}PSHUFD, {V,}SHUFP{S,D}, {V,}PERM2{I,F}128: Copy multiple ⓈⓋ into Ⓥ - {V,}PSHUF{L,H}W: Shuffle but only for Ⓛ or Ⓗ, copy other half verbatim - {V,}PACK{SS,US}{WB,DW}: Pack from two Ⓥ into half-size slots in Ⓥ with saturation Ⓛ = Low part of Ⓗ = High part of Ⓢ = Selectable part of Ⓑ = Base register Ⓥ = Vector register *FAQ:* *Q)* 4K is fine, but what's the point of making a powerpoint presentation 60fps? (thinkingobserver) *A)* When I create a project in kdenlive, it is usually at a point where I don’t yet have all the footage, nor have I entirely decided all the footage I want to add later. For example, here I added the little camera clip of my Z80 almost at the last moment. I just do all my projects in 4K 60fps so that I don’t need to change it later, which usually would break havoc on the project. Also, 60fps gives you smoother transitions & other animations. *Q)* Register is pronounced very differently from resistor. You are pronouncing them nearly identically and it's the first case where my ears are having trouble following what you are saying. (DoomRater) *A)* My native language does not have the English z,sh,ch,j,th,r sounds, so every time it takes some conscious effort to produce them. When there are rapid alternations between those and similar phonemes /l/ and /s/ that we _do_ have in Finnish (we also have trilled /r/), I can’t keep up. The word "register", and especially compound terms like "general-purpose register" are practically tongue twisters to me. I know exactly how they should be pronounced, but my tongue just does not cooperate. For more information: kzbin.info/www/bejne/iXu9nXyHps-JiZY *Q)* The background music is a little loud. (Lego Guy Two One Seven) *A)* I tried it with my headphones and I set the volume levels to whatever I felt that I could still comfortably hear the talk. I actually spent several hours working on this. *Q)* This [...] music is terrible and distracting. There is no need for it. (proteusx) *A)* I actually _needed_ some music for the record needle scratch joke to work. There are several other reasons why I prefer to have some background noise. But I always try to choose the music thematically. For example, the battle theme when describing Zilog’s challenge to Intel resting on their laurels. I often also try to match crescendos and other flourishes to particular situations in the story, editing the track if necessary. It is _my_ artistic style. Sorry that you didn’t like it. It is impossible to please everyone! *Q)* Do compilers even use any of this? I just don't see a situation where you'd need these operations. (Chyza) *A)* Yes, they very much do. Sometimes better, sometimes worse. See some of these examples: godbolt.org/z/aMjzRd (simple vector moves), godbolt.org/z/-xgsvv (VPBROADCASTW), godbolt.org/z/z9RjBG (destruction and mayhem with examples of MOVZX, PACK, UNPCK, BLEND, SHUF, INSERT and EXTRACT across the three compilers). In the third example, the init2 function is written hand-holding the compiler to get them to produce the code that I _wanted_ them to produce for the first init function. If you enable -mavx512f, ICC goes bonkers again. Auto-vectorization is an ongoing field of R&D for compiler development. Sometimes the compiler does not get it at all, sometimes it does it very well, and sometimes it crafts a rube-goldbergian monster for simple code. ___________ Previous content: This is the pinned comment. Sorry, I posted much information here earlier, but KZbin nuked my post when it changed the video (from unlisted) to private temporarily for the scheduled publication. Nowadays, _apparently,_ KZbin permanently _erases all comments_ on videos that are made private. In this case, the video was private for exactly zero seconds, because I set the scheduled publication time to be in the past. Isn’t it exciting to learn new things by surprise rather than e.g. them being announced somewhere? Eventually _I_ nuked _the video_ because of reasons. This is the new upload, version 2. I will re-type the information that I intended to have here after I am well slept and no longer worked up.
@willmcpherson25 жыл бұрын
I would love a more opinionated overview of different ISAs, with comparisons between them. x86 is very complicated, it would be cool to see a comparison with ARM or RISC-V.
@hammerheadlemon5 жыл бұрын
Incredible amount of detail - must have taken months. Just starting to learn about assembly (via learning gdb) and this blows my mind somewhat. Thanks for making it..
@karolszymczyk81705 жыл бұрын
Great video man. Actually I am learning architecture of PC and it also helped me :D I am always willing to see some videos about hardware level/low level programming :D
@yumiwatanabe4405 жыл бұрын
when i was watching i was thinking it sure reminds me of something... and indeed it does ! starts normally, but then... kzbin.info/www/bejne/fJLZhqN6lK6djLs
@YourTVUnplugged5 жыл бұрын
Bis{D,Q}wit! So you do love more than just 6502! Yes it is fun to mess about with 6502 and old nes games code but I have to acknowledge that is just tinkering and for fun... Getting any serious work done is for our modern processors but that which as shown here is way more advanced and can feel quite complex at times (until you work with those instructions enough and get used to how they work) which is why it can be nice to retreat into some 6502 coding or similar as it provides a break from the advanced modern architecture(s) and timewarp almost into a simpler time! lol So yea more C++ stuff and reversing nes is always welcome but writing some pure assembler by hand for some specific purpose or program would be really cool too, you'll like it!
@Jack41EL5 жыл бұрын
I'm terrified of what x86 might evolve into after another 40 years. Maybe we will be talking about how vjkamov32mskntpsid doesn't require as many uops to permute the rjzmm registers as the virtual address aliasing hack of 2053.
@CodeParade5 жыл бұрын
I always knew there must be some convoluted history of maintaining compatibility, while simultaneously adding more and more instructions, while also occasionally changing their minds... Having worked with both types of architectures, it really gives me a new appreciation of RISC.
@veda-powered5 жыл бұрын
Ah yes the classic VPUNPCKHBW instruction, I truly have no idea why some people think x86 is complicated.
@hobbified5 жыл бұрын
I know why. It's because they're fools who think they're clever.
@moth.monster5 жыл бұрын
Instructions unclear, moved data into resistor.
@skilz80985 жыл бұрын
HAHA!
@ZomB19864 жыл бұрын
Instructions unclear, d*** stuck in resistor. (data)
@TheHippyhopp5 жыл бұрын
I love when Bisqwit tries to pronouce words that shouldn't be
@esra_erimez5 жыл бұрын
+1
@thomass31935 жыл бұрын
"rrrrrrax"
@alicewyan5 жыл бұрын
Little well known fact: if you pronounce all x86 instruction mnemonics out loud, Cthulhu will rise back from the oceans.
@ZomB19864 жыл бұрын
What's a "particle'r byte"?
@wessmall79574 жыл бұрын
Ceramic
@CuriousMarc4 жыл бұрын
Your pronunciation of assembly instructions is impeccable. You have a very special talent there. We should hire you to read aloud pages of assembly source code (the 2000 pages of our AGC computer listings comes to mind). Very well done video.
@Techokami4 жыл бұрын
Zilog's Z80 was a direct competitor to the 8080 because it was made by the same guy, Federico Faggin. He waltzed out of Intel after making the 4004, 8008, and 8080 CPUs, and founded Zilog with Ralph Ungermann to create CPUs on his own. This mirrors what happened with Motorola at the same time frame; Chuck Peddle made the 6800 CPU, but then waltzed out of Motorola and founded MOS Semiconductor to create the 650x line of CPUs.
@Nerdule5 жыл бұрын
Goodness me. I'd heard that the x86 instruction set was messy, but *yikes*. (Also, "twelvety-eight" is an excellent way to say 128. I've never heard anyone say that before, but it's endearing.)
@charlesrosenbauer31355 жыл бұрын
Wait until you check out the binary encodings of these instructions. Intel's full x86 manual is 5038 pages long.
@vikiai42415 жыл бұрын
It is a bit of a victim of its own success. Intel themselves have tried to move to a new cleaner architecture at least twice! But x86 has an awful lot of inertia in the desktop and server space.
@KuraIthys4 жыл бұрын
@@charlesrosenbauer3135 That's a lot. But on the other hand, the current 6502 family manual (yes, 6502 is still a 'current' design sold as new parts. XD) is some 460 pages, and that's for an architecture that basically hasn't changed at all since 1984. (though it does cover 4 variants; 6502, 65C02, 65802 and 65816, but aside from the latter two having a bunch of 16 bit instructions, there's not all that much difference. nearly 500 pages to describe no more than 255 instructions.) Add in the datasheets which contain considerable addtional information, and are often at least 150 pages and you could get into the 1000+ range for the family. (but the modern iteration of the family is basically the 65C02, 65816 designed as processors along traditional lines, and 65C134S and 65C265S which are microcontroller equivalents with built in RAM, flash ROM, and even a set of tone generators, timers and other support features. Kinda weird to think about honestly. If they weren't slower than the dedicated CPU versions, they'd be fascinating for a retro style computer build.)
@thetastefultoastie60775 жыл бұрын
The new "Bisqwit" title animation @ 0:54 looks awesome!
@k1ngjulien_5 жыл бұрын
So awesome he used it twice 10:05 :)
@tacokoneko5 жыл бұрын
"there should only be one MOV instruction" well that went out the window pretty fast
@T3sl45 жыл бұрын
Protip: MOV is Turing complete. github.com/xoreaxeaxeax/movfuscator
@yigitpolat5 жыл бұрын
@@T3sl4 have you checked binary sizes of the compiled output of this garbage?
@nokkonokko5 жыл бұрын
@@yigitpolat yep, but it does indeed do what it purports to.
@yoshi3145 жыл бұрын
@@yigitpolat that doesn't disprove it in the slightest. you still get a functional binary as a result.
@yigitpolat5 жыл бұрын
@@yoshi314 real computers arent turing complete since they have limited amount of memory and turing completeness requires infinite memory by definition. Yes, you wont notice that your machine is not turing complete but only as long as you dont hit the boundaries. thus, wasting memory like this will push you further away from being truly turing complete.
@Link-channel5 жыл бұрын
I only knew the instruction sets until 8080 and 8086, thank you! ❤️ *All your videos are incredible,* this is easily the best channel on KZbin for me, along with the *8-bit guy!* (i can only hope being so smart is not a curse in your everyday life)
@Bisqwit5 жыл бұрын
By "until" do you mean you were familiar with 4004 and onwards until 8086/8088, or with Pentium and 386 instructions even down to 8080? Thank you for your kind words!
@Link-channel5 жыл бұрын
@@Bisqwitonly from 8080 and 8086, to 8088. I mainly used it to optimize Pascal/C code, i.e. graphics; rarely to debug. I also did some basic crackme for fun on Windows era (with Softice) but never really learned to remove any commercial protections. Thank you for sharing your knowledge! ❤️
@Bisqwit5 жыл бұрын
Where did you work with 8080? I am curious.
@Link-channel5 жыл бұрын
@@Bisqwit I did some 2D videogames with sprites on DOS, with optimized routines in Assembler, and then some 3D games on Windows with DirectX. But everything as a hobby/passion, never worked any commercial title or any IT job ☺ i am glad i talked to you at least once in my life, i watch your videos all the time the stuff you do is awesome!
@Bisqwit5 жыл бұрын
But I specifically asked about 8080 - since you mentioned it - a chip that came and went before IBM-PC (or let alone DOS) was even a thing.
@moth.monster5 жыл бұрын
x86 is the perfect example of why "if it ain't broke, don't fix it" isn't always the best way to do things
@XTpF4vaQEp5 жыл бұрын
I hate that expression... The progress of mankind is litterally the continous improvements we accomplish, i.e "fixing things that already work", thus making them better. But yes, x86 is exellent, but there will be greater things, just not yet discovered or adopted. :)
@DbugII5 жыл бұрын
I would have agreed until recently, but now the performance increase of the new x86 models is just incremental, and if security researchers were not discovering possible exploits every few months.
@hobbified5 жыл бұрын
Well it depends. Do you want to be "best", or do you want to be *successful*?
@ericcartmann5 жыл бұрын
x86 has terrible power to performance because of all those instructions. The CPU is very inefficient. This is why ARM will eventually take over. Power consumption is becoming more of concern as we see the end of Moore's law. The only thing x86 has going for it is legacy support.
@hobbified5 жыл бұрын
@@ericcartmann only... in the real world it isn't so. Top-end x86 chips aren't spending very much of their power budget on instruction decoding (Hirki et al 2016 refers to it as a "common myth"), so the efficiency gain achievable from the *best possible instruction set* for the uArch is no more than a few percent compared to x86. There's a reason why the performance/watt benefits of ARM have never materialized in the data center, and that's because they fundamentally don't exist. Design has a million times more to do with efficiency than ISA does. AMD and Intel have designs that own performance/watt in the server and high-performance desktop space; other people have designs that own performance/watt in spaces like handheld and STB. The instruction sets don't come into it except as a second-order factor, something for students and fanboys to argue about.
@willmcpherson25 жыл бұрын
Nobody: Bisqwit: pinsrrrrrq
@salvatoreshiggerino68105 жыл бұрын
He should do a video on Common Lisp and its variations of CAR and CDR.
@dakotadanderson5 жыл бұрын
Excellent video ^_^ Recently had to go back to Assembly, and learning about why it is so messy is helpful!
@axtran5 жыл бұрын
Had the opportunity to meet Pat Gelsinger a few years ago. After that, I decided to delve into the 486... then all of this... glad to see this content still being discussed, as I think a lot of it is lost in time!!
@xotmatrix5 жыл бұрын
I've studied 8080/8085 and am now learning Z80. It is really interesting to see the progression of Intel architectures 4004 to x86 - and then the nightmares start.
@theIEndYOU5 жыл бұрын
i really enjoy that the video is not only informative but really funny because of the ridiculousness of the x86 architecture. Really liking the new intro as well.
@SteelHorseRider745 жыл бұрын
A great overview video, bisqwit! I also draw my hat to those guys who develop the compilers (e.g C, Fortran etc), taming such cpu instructions into logical and correct order...
@johnwhite77005 жыл бұрын
Yes, probably these instructions are so terrible because of they are useful to very small amount of people, while others write code in higher level languages.
@TheBlackMusicBox5 жыл бұрын
I like how you pronounce all those instructions
@Fopenplop5 жыл бұрын
when he said PINSRB, he came perilously close to invoking the name of a Great Old One.
@omfgbunder20085 жыл бұрын
Too complicated, I'm going back to 6502 😂
@esra_erimez5 жыл бұрын
Or, 6809 :-)
@allmycircuits88505 жыл бұрын
I'm now struggling with TTA, that is Transport Triggered Architecture. It has just one instruction: MOV, but as it is the only one, there is no point naming it. All my code is pairs Dest, Src. But there are lots of special addresses. By writing to PC (program counter) we jump, there is ALU which performs operation when new value is put into it, memory access can be indexed in many ways. But overall, I like it :)
@vityazpp194 жыл бұрын
Or Z80
@sophiacristina2 жыл бұрын
4004 is fine...
@fredg83285 жыл бұрын
The Z80 also had a copy of most of the registers AF', BC', DE' and HL'. It was often used to switch between 2 contexts when entering an interupt. The AF and AF' could be exchanged with the EXAF instruction, and the other ones were swapped with EXX. The IX and IY register could be swapped with the current word on the stack: EX (SP), IX and EX (SP), IY
@Bisqwit5 жыл бұрын
Indeed. I did mention the copy registers on screen, but not in the narration.
@amir328065 жыл бұрын
This video is very helpful for understanding of the basics of programming in assembly language. Thank you!
@jonnybriggs75315 жыл бұрын
6:03 huopping 10/10 video btw.
@beron_the_colossus5 жыл бұрын
Informative video, nice intro as well. Thank you!
@baconinvader5 жыл бұрын
It's my theory that Bisqwit is stalking me and makes videos about whatever I happen to be searching up on Wikipedia at the time.
@KuraIthys4 жыл бұрын
I've had feelings like that with some content producers at times. XD Not in that exact form, and not Bisqwit in my case, but it's still quite weird. I swear someone wrote a webcomic at some point that is way too close to my life for comfort. (thankfully nowhere near identical, but still close enough to be disturbing.)
@Fopenplop5 жыл бұрын
the combination of his cadence and the weirdly mixed midi music incredibly disorienting. love it.
@Dimi-Tech5 жыл бұрын
Thank you @Bisqwit, this was beyond awesome!
@alienozi5 жыл бұрын
Thank you Bisqwit. Very cool video.
@grazingrockproductinformat26874 жыл бұрын
nice overview, well done! Although... HL has NOT been turned into BP, and BX is not the old BC either. Instead, BC has become CX (think of Z80's DJNZ and 8086's LOOP), while HL has evolved into BX. The dead giveaway for that is BX's ability to address BL and BH separately, while BP cannot do that - but for the automated software translation from 8080 to 8086, it was necessary to have a clear "successor" register for HL, so this must be BX (yes, software like WordStar was actually mostly converted from 8080 binaries to 8086 binaries - conveniently, MSDOS offered all CP/M system call functions with identical parameters). So, the new kid on the register block really is BP, not CX
@baltazarus33075 жыл бұрын
Excellent video Bisqwit!
@ScottMaday4 жыл бұрын
RISC-V: let's have 47 instructions Intel: Wait was it VBROADCASTF32x2 or VPUNPCKHDQ?
@ihspan68925 жыл бұрын
I've already said it before, but it constantly hold's true. You are brilliant.
@mosvan5 жыл бұрын
Thanks for the upload, currently I'm taking a class on x86 in school so this information ties in nicely for me. I also just wanted to let you know that at 5:03 in the video, the date overlaps the title of the slide.
@Bisqwit5 жыл бұрын
Thanks. It was intentional. The date ribbon kept creeping right to indicate movement on the timeline, so it was inevitable that it would overlap with the title.
@johnedgar61255 жыл бұрын
Thank you for this video. I was looking for something like this. Thanks you absolute genius. I wish I was as smart as you
@zazkegirotron5 жыл бұрын
This is gold 😍. Thank you
@Ikkepop5 жыл бұрын
my favourite part is where Bisqwit pronounces the names of the instructions XD VMOVSHDUP :DDD I'd hate to be programming Assembler these days, it was much simpler back in the 386 days
@KuraIthys4 жыл бұрын
Based on Micheal Abrash's books, I'd wager that the PC was never all that pleasant to work with at a low level... It's amazing how convoluted some architectures can be...
@EasyBCLS5 жыл бұрын
I don’t understand any programming or computer science whatsoever, but I still like your channel and videos lol
@Lattamonsteri5 жыл бұрын
Same here x)
@Chriva5 жыл бұрын
Very informative. Thank you :)
@ivelinkarageorgiev31115 жыл бұрын
ahh, awesome video. keep rocking !
@sabriath5 жыл бұрын
Just FYI, you can "call" the opcodes whatever mnemonic you want.....it's all just numbers to a cpu anyway. This is more of an ASM parser problem at that point, most of the commands could take a single "MOV" instruction for nearly 90% of the commands, simply by parsing the commands that follow to determine which opcode to use. If the commands themselves are noted for what it is, then the command can be used for 99% of the time....it's all about the compilation. For example: Instead of MOVSX AX, BL and MOVZX AX, BL it could be MOV AX, BL.S and MOV AX, BL.NS (for "signed" and "not signed") The compiler, if done properly, would be able to replace it with the correct code. The issue is that compilers aren't usually built that way, and there aren't many ASM compiler makers left to care to change it, which is sad really. Most work in C/C++ or higher, so a lot of that stuff is done under-the-hood.....eventually it will become a lost art, since everything is improved through a T graph, nothing from scratch anymore.
@Bisqwit5 жыл бұрын
It is absolutely true that the names of the instructions are entirely a convention/culture issue. The CPU only cares about bytes. And it is both this culture, as well as the internal design, that I am documenting here.
@YourTVUnplugged5 жыл бұрын
Yes Robert... For example that's why there's at&t syntax versus the superior and more pleasantly readable intel syntax (they got it right). With the destination operand on the left: mov dest,src compared to at&t's opposite mov %src,%dest and the unnecessary and noisy %'s sprinkled everywhere. Which your destination is more important since that's where the result of your operation is going to so that's first, and then your source register or memory location and written cleanly without extra characters that aren't needed and just decrease readability rather than add anything. Yea C++ is cool and all but you know what would be really cool? An ASM++ type of hybrid machine code/high level language features modern built assembler (or ASM compiler as you've called it). Like you can think of it like ASM with classes but much more than that! It would give you the direct processor control and the extreme power and flexibility that offers, but with high level features like you get in C++ so that you wouldn't have to absolutely everything you do by hand from scratch pretty much on your own without much help. So yea I don't think you're right about the T-graph thing it is like a lost art but it is not and I don't think it ever will be... There will always be some people where even C++ is not good enough, and they want to get even closer to where the magic is happening! As long as CPUs speak this language we will speak it too, and sing it sweetly to them in a lullaby xD
@sabriath5 жыл бұрын
@@YourTVUnplugged ... "ASM with classes" that sounds like HLA. "T-graph is a lost art"....no, it's not, that's how compilers are made now. You take an LLVM and process whatever language you want through it, then you produce the compiler through itself to produce itself as the base, and any improvements you make are built on the initial....that's a T-graph. You don't have many people creating "new" compilers anymore (from scratch), except possibly college students, but all those come out as Tiny-C copy-cats. As for "always be some people where even C++ is not good enough"....C++ has built-in ASM compiling, so they can put their code directly into a function wrapper, no "new" compiler there.
@YourTVUnplugged5 жыл бұрын
@@sabriath Thanks for the +1 Robert but you partially misinterpreted my comment (sorry I wrote it fast... Like I write my assembler and is also the speed at which it runs :D): "Most work in C/C++ or higher, so a lot of that stuff is done under-the-hood.....eventually it will become a lost art" Writing assembler by hand by inclined individuals won't become a lost art, if you say it will then it already is because even on the masm website it says: "MASM has never been for the faint of heart, it is an uncompromised tool that has never been softened into a user friendly toy and it required the development of expertise to use correctly but for the programmer who already has experience in low level C and similar code, MASM offers power and flexibility that the best of compilers cannot deliver and contrary to popular opinion it can be developed and written at about the same development time as C code." I am not the faint of heart it describes and while I guess most people are, we are not since we have even dared to revel in the direct communication between us and our computer processors and so if you're saying people like us will disappear I would say you're wrong because it's always been something reserved for those that want to do it simply because they can! If I couldn't write assembler or was never introduced to it by someone who could I would probably writing crappy java too... But because we can, we do! Started with x86 32bit ASM and added C++ to my abilities and because of that being my rooted have always snubbed my nose at java and other 'higher level' languages because they always compromised my speed and my security of knowing if there's a bug it's my fault in my code not in somebody elses (like that develop the java api for example). If you fked up it's on you and that's a discipline that these higher level developers don't have because they always have the out that oh my code is fine it's the java developers that have their jvm convert my code into machine code that have made the oopsie which made it exploitable... I don't place my bets on others ensuring my code is bug free, that is purely on me! :D
@sabriath5 жыл бұрын
@@YourTVUnplugged ... I +1ed your statement because I agreed with the syntax and your overall sentiment in that reply. When I say "lost art," I mean that in the mainstream of software development. Yes, some people still do assembly, but usually as a hobby, not seeing many dedicated masm game developer companies....or any at all actually. The masm forums traffic is about 10 per day, and posts are averaging 1 every 2 days, so you can see how little compared to other higher-end languages it gets used. I'm not putting down the language, I actually like working low-level, but I'm not a fool either.....it's nostalgic to work in it. The comparison is like using a chisel to carve decorative wood edges versus using a CNC machine for mass production, assembly is the chisel.
@biggusmunkusthegreat5 жыл бұрын
15:45 mvsesorliBOOP
@lefrise55 жыл бұрын
My favorite one without a doubt!
@10vid5 Жыл бұрын
17:20 Actually, there is a byte size shuffling instruction starting with SSSE3 which is PSHUFB, and then in AVX2 which is VPSHUFB and so on. People use these instructions mostly for holding small look-up tables of 16 or 32 entries, mainly useful for reversing strings of data.
@Bisqwit Жыл бұрын
Indeed, somehow I missed PSHUFB and PSHUFW while making this video.
@Mozto4 жыл бұрын
Ok , I love low level stuff + the Descent Sountrack !
@uncoherentramblings28265 жыл бұрын
Very good video!
@biggusmunkusthegreat5 жыл бұрын
This deserved a sub. The way you pronounced the instructions was brilliant.
@esra_erimez5 жыл бұрын
Knuth's MMIX instruction set is so elegant compared to Intel's mess.
@everestmountain88894 жыл бұрын
I'm the fan from China, and you are doing the unbelievable work,👍👍
@everestmountain88894 жыл бұрын
I'm like you background music, it's fantastic! And you voice is so unique.
@chilinouillesdepommesdeter8195 жыл бұрын
4:09 "another company:AMD,no wait Zilog" LOL
@jeremiefaucher-goulet33655 жыл бұрын
That's why I much prefer ARM... At least I don't get lost with RISC. I applaud compiler coders attempting to make sense out of all this ;)
@rolandbrake5 жыл бұрын
thanks for the video it was very informative
@davidvanson17865 жыл бұрын
cool video Bisqwit nice one
@PandorasLuckbox5 жыл бұрын
I didn't mean to be snide in my comment on the earlier video, I was just joshing about the music.
@Embedonix5 жыл бұрын
Thanks mastero :) I learned some new stuff :)
@Bravo-oo9vd5 жыл бұрын
watching this video made me understand why we need risc-v. thanks!
@torytatsumaki5 жыл бұрын
Yay new opening
@spicybaguette77065 жыл бұрын
Chip manufacturers: Just add another instruction!
@vvb0x5685 жыл бұрын
Thank you bisqwit, nice inctruction :)
@Suppboio5 жыл бұрын
thanks
@mb50585 жыл бұрын
Owner of zilog was the original designer of the 4004.
@DaveChurchill5 жыл бұрын
Hi Bisqwit! Great video, really interesting technical history and very informative. I thought I'd give you a little tip on some of your pronunciation in the video (if you would like feedback). If not, tell me and I won't make the comments again in the future :) - Ceramic is pronounced with a soft-c 's' sound, like seramic - Scheme is pronounced 'skeem' with the ch being a hard sound, not like 'sheem' - SIMD is usually pronounced SIM-DEE instead of just trying to read the word
@Bisqwit5 жыл бұрын
Thanks. As for acronym pronunciation, that’s just a thing I do for flavor and for fun - and often people’s opinions on “correct” pronunciations of them varies greatly anyway. For example I have lost count how many different readings of “MySQL” I have heard.
@DaveChurchill5 жыл бұрын
@@Bisqwit Something else you may be interested in: Blades of Steel for the NES can generate different demos (pseudo-randomly) from power on with no user inputs. Might make an interesting video how it does that
@Bisqwit5 жыл бұрын
How many different demos? In any case, on the NES, the CPU and PPU run on different clocks (produced by dividing a master clock at different integers), with the PPU running faster than the PPU (3 times faster on NTSC, 3.2 times faster on the PAL). On system power-on it is actually random where the clocks align; which PPU cycle is the one that ticks _exactly_ at the same time as the CPU. The CPU can detect this difference from the latency of certain operations when communicating with the PPU. So that is where randomness can arrive. In addition to that, the contents of the RAM are random (and depend on the exact console unit) when the system powers on. This is _more likely_ what the game uses.
@DaveChurchill5 жыл бұрын
@@Bisqwit I've been told that Blades of Steel zeros the RAM, so in that case it would have to be the CPU/PPU misalignment. Thanks for the explanation!
@bastardtubeuser5 жыл бұрын
Great video, we should be wiping off tears thinking about a memory mapped x86 running on a pc with no mysterious memory management.
@BlizzetaNet5 жыл бұрын
God bless you too. Stay awesome. :)
@adamjansadowski5355 жыл бұрын
Hello Bisqwit, I love your mercilessly technical videos. Apologies if you have answered this before, but can I ask what tools & OS you use, and how did you teach yourself to do what you can do?
@Bisqwit5 жыл бұрын
I use whichever tools I need for some particular task. My OS is Linux. I prefer Debian distribution, but as long as I can install whichever software I want, the choice of distribution matters very little.
@adamjansadowski5355 жыл бұрын
@@Bisqwit Thank you very much for your reply. Can I ask if you are self-taught in what you know in C++?
@Bisqwit5 жыл бұрын
Pretty much. I did read one or more books on _C_ in the early/mid 1990s. Most of what I know comes from doing a ton of programming and reading source code, as well as keeping up with newest news when Internet became a commonplace thing.
@adamjansadowski5355 жыл бұрын
@@Bisqwit Thank you again. I just asked out of interest and admiration. I studied and do research in structural engineering, yet we never learn to truly use computational resources. I will take you as an example. Best wishes!
@eone199 Жыл бұрын
@@adamjansadowski535 is this structural engineering like building architect thing?
@derekgeorgeandrews2 жыл бұрын
4:07 *competitor arrives on scene* *tense conflict music starts*
@BirchTreeReborn3 жыл бұрын
I'm very interested in computers considering that I grew up as home computers were really starting to take off but I have no idea where to even start with the understanding of how a computer REALLY works. I'm an engineering student so I have a love for the very tiny details of how something works but for a computer I just don't know where to start. Will you ever be doing a video that discusses how a computer takes wall power and goes through the entire process of creating binary and all of the subsequent steps to creating and executing a simple code on something like an 8-bit computer? I think that would be a very fascinating video! Additionally, do you have any sources for extra reading with regards to how each part of a computer works and how a code that the computer can execute is created and read by the computer?
@Bisqwit3 жыл бұрын
I am working on it! (No promises on schedule though)
@BirchTreeReborn3 жыл бұрын
@@Bisqwit I'm excited to see it when it comes out! :D
@byterot5 жыл бұрын
I would love for someone to upload a cut video of Bisqwit trying to pronounce the instruction mnemonics like actual words :)
@BinaryReader5 жыл бұрын
Thanks for the video, this is great :) It would be cool if you could make one on RISC too, id be curious to hear your thoughts and comparisons on the different architectures. Learning a lot !
@pepe66665 жыл бұрын
holy shit it never ends. there are so many ways to move data from a register to another one. i kinda wish that was some way we could specify in a more human-readable way that we wanted to move data from one memory location to another, which was translated to the right opcode.
@muhdiversity7409 Жыл бұрын
Just call all of the mov :) That'll make it more readable with the src/dest,IMM providing the extra context.
@unosturgis3 жыл бұрын
The trumpets were an excellent choice
@ToonTownHaze5 жыл бұрын
What bank did you use for Tales of Phantasia - Oasis? I tried all 66 from ADLMIDI but haven't been able to recreate the track in the video. Thanks in advance!
@Bisqwit5 жыл бұрын
Bank 1, I think. Where did you get the Oasis MIDI from, though?
@ToonTownHaze5 жыл бұрын
Bisqwit I think I just googled the name of the track and found it from some guys MIDI dump, that’s probably why, did you rip yours directly from The game? I think my MIDI might be a recreation
@Bisqwit5 жыл бұрын
Well, you found someone’s cover for the song. It is no wonder the instruments don’t match. You can find the MIDIs I created at: bisqwit.iki.fi/music/
@ToonTownHaze5 жыл бұрын
@@Bisqwit Thanks so much! I've got the file!
@theALFEST5 жыл бұрын
B is high byte in BC pair and C is low. Same with DE. (for Z80 and 8080)
@Bisqwit5 жыл бұрын
Ah, thanks for correcting! I didn’t actually check these, but just assumed so.
@wyc24622 жыл бұрын
This is Wing Command isn’t it? So great!!
@tib72095 жыл бұрын
im learning 8086 assembly and im struggling to understand how the sp and bp registers work, it would be great if u made a video about them. thanks 👍
@Bisqwit5 жыл бұрын
Thanks! I will keep that in mind. I have covered the bit _somewhat_ in this video - kzbin.info/www/bejne/mHrZmml8g96cgKM - albeit from 64-bit perspective, not 16-bit, but the principles are still pretty much the same.
@xc_gwpl5 жыл бұрын
Are you going to be doing more live streams?
@Bisqwit5 жыл бұрын
I mostly do them without much planning.
@k1ngjulien_5 жыл бұрын
Ever wanted to know what really CISC means? This😂
@T3sl45 жыл бұрын
x86: RISC: *stares away conspicuously*
@KuraIthys4 жыл бұрын
@@T3sl4 Well, modern systems are generally using hybrid approaches. Pure RISC & CISC designs basically don't exist anymore. (example: Note the absurd register count of the x86 architecture at this point; that is NOT a CISC style feature) That doesn't even get into the fact that x86 exists as an abstraction layer with microcode internally translating to the often much less complex and more RISC-like underlying CPU architecture. (which varies considerably even among different generations of x86 CPU...)
@aatishsingh11835 жыл бұрын
sir from where i should learn vga basics, ports, video ram, sound etc but as a beginner and also embedded programming?
@aaleeksii5 жыл бұрын
Keen to hear an answer to this
@Bisqwit5 жыл бұрын
If it is PC architecture in specific that you are interested in, the PCGPE is a good start (qzx.com/pc-gpe/). It covers things that were relevant to game programmers in 1990s working on DOS and the PC hardware. It is not so useful _today,_ because you no longer interface with hardware directly, but you use operating system facilities. This is because your operating system’s task is to make sure that everything plays nicely and that no program can crash the system or interfere with another program. That is why no program can take over sole ownership and communication with some hardware piece. But in the DOS days, things were different. Computers were not multitasking, so if you launched a game, you did _not_ also have an email client running at the same time, or anything else really. All the computer did at that point was just run the game, and all the hardware resources were dedicated to the currently running program. If you want to relive this experience, the cheapest way is to use a DOS emulator like DOSBox, which emulates a fair bit of common hardware on the PC as well, such as a SVGA-compatible graphics card, a few popular soundcards, etc. Then, inside this emulator, you can write programs that take full control of these emulated cards just like it would have been done in DOS days. As for modern embedded programming, with platforms like STM32 or AVR, where you do communications directly through I/O, I2C, SPI, etc., maybe the most popular way to get started is to get your hands on an Arduino or something, and study the Arduino IDE which has a reference manual if I recall correctly. It also helps to know a thing or two about electronics.
@thda815 жыл бұрын
Speaking of basic vga/video programming, I can recommend the links on this wikipedia page: en.wikipedia.org/wiki/Mode_13h. The content the linked pages provide gave me a pretty good low-level understanding of these topics.
@dripman785 жыл бұрын
Hey Bisqwit, what do you think of RISC vs CISC based on today's hardware capabilities? Are you planning to cover this in near future ?
@Bisqwit5 жыл бұрын
Instruction decoder is not where the most complexity lies in today’s microprocessors. The question is quite moot. Internally, all x86_64 processors essentially run a totally different processor that operates on hundreds of registers and which breaks down the CISC instructions into small pieces that can be more easily parallelized. Even if you have a RISC CPU, you still need such a component, because there is no way that an instruction set could accurately describe the internal state _and_ simultaneously be future-proof. No matter what, you will need an instruction to microcode translator with all the complex rescheduling, dependency tracking stuff and so on. The difference is mostly out of convenience to the programmer. Also, if you redesign the instruction set from scratch, chances are that you will end up with shorter opcode encodings by average than x86 has today. This would bring tangible improvements, but by how much, that I cannot say.
@cesteres5 жыл бұрын
I doubt many people hand optimize these days
@blarghblargh5 жыл бұрын
Probably just as many as always, but there's a ton more programmers these days, and a lot of higher level programming has been opened up, so it is a smaller percent
@NathanDrake55 жыл бұрын
Finnish Demoscene coders still do that! It's a tradition. :)
@KuraIthys4 жыл бұрын
A lot of the most extreme optimisations are off the table once you have an operating system as complex as Windows, linux or anything like that. Not just because the operating system is complex to deal with, but because it actively fights against you doing low level things, like say, directly accessing graphics hardware, or straying outside your program's allocated memory space, or any number of things a programmer working on an older microcomputer or even on a DOS system would happily do. Of course, that doesn't stop you optimising your own routines as long as you stick within the confines of what the OS will allow. (nothing like causing a general protection fault by mistyping a line of code though. XD)
@JamieBainbridge3 жыл бұрын
Nobody hand-optimises, but people still need to hand-debug. People like me, who need to look these things up to see the side-effects to understand why a value should have been valid one instruction before but one instruction later contained zero, because a not-obviously-named instruction actually zero-extended the top half of the register. Ah I love my job.
@zyxwvutsrqponmlkh5 жыл бұрын
I am blessed.
@tsonez5 жыл бұрын
God bless you too!
@johnwilson31585 жыл бұрын
you are the man ✌🤙👍
@НегодяйМолодец5 жыл бұрын
♫ Bodyrockers - I Like The Way You Move
@bitterlemonboy3 жыл бұрын
I was wondering how many times in a second the cpu can rewrite the reigister? Because registers are the fastest memory in a computer
@Bisqwit3 жыл бұрын
Several times per clock cycle, due to superscalar execution and register renaming.
@xabab5 жыл бұрын
First thing that came to mine mind is the assemble lang lector's nickname in my university: "Outstanding MOV" P.S. Tasks were easy enough, but when you are lazy to even do them, you read your groupmates'es uncomented code in panic on the lecture... That's was rough...
@paulwratt4 жыл бұрын
According to the 8bit Guy 2nd roadtrip into Dallas (?) a company originally named Computer Equipment (???) gave Intel the design schimatics for the 1st CPU and said "build this" (the 4001 maybe? or the 4004?) - Also FYI the space shuttles were still using 4004 and 8008 CPU's in their intrumentation and control electronics right up to their de-comission. They just dont make electronics to last as long as that anymore (see: Google hardware & Apple i devices : yay for eco-terrorism, world enslavement, and Overlord anime as a training tool)
@Fopenplop5 жыл бұрын
This is probably a much more complicated question than can be answered in a 20 minute video, but in designing new iterations of these architectures, how do they decide which specific functions would be worth including?
@Bisqwit5 жыл бұрын
Sometimes they get feedback from developers, and based on that feedback decide what warrants new instructions. For example, the fused-multiply-and-add instructions were introduced that way. Sometimes they try to predict what the users will need, or what could be marketed to boost the sales. The AES acceleration was maybe added through that kind of process. It significantly speeds up throughput for AES-encrypted network transmission.
@DanDart4 жыл бұрын
Love the way you pronounce these instructions, as if they were words with barely any vowels...
@Waccoon5 жыл бұрын
Wow... I'm designing my own CISC CPU just for fun, and I'm still debating whether to join masking operations with moves. Just about all operations more complicated than that have been rejected since they wouldn't be used enough to justify including and can be done better with a coprocessor. Intel basically included every single thing I rejected, and with a cherry on top. It's like, every tiny edge case justifies a new instruction. Good thing I studied the differences between 68K and SuperH for inspiration instead of x86. Also, my guess as to why MOV{D,Q} is needed for MMX is locality. Most CPUs don't allow you to move directly from the integer unit to the FPU since even though they are on the same die they are still physically separate hardware units. Normally you push the data into the stack to do that kind of transfer. Intel was probably doing all kinds of silly low-level stuff with MMX and separate instructions were more convenient for unit synchronization. After that, they just said "screw it" and added a plethora of special MOVs. I don't know how to program x86, though, so... [shrug].
@Bisqwit5 жыл бұрын
Locality has nothing to do with it. This is an issue with nomenclature, or language. The assembler can _call_ these instructions whatever it likes. Why Intel decided to give these instructions different names I don’t know. They did just fine with segment register moves (e.g. MOV AX, CS) and control register moves (MOV CR0, EAX). But they added special instructions for some other moves (like _LIDT mem_ instead of _LEA IDT, mem,_ or _SMSW AX_ instead of _MOV AX, CR0_ ). There is no reason why an assembler couldn’t do with the other name.
@shahabmeteor89755 жыл бұрын
Second guy to comment :)) Thanks for the intro of computer architectures
@UpstreamNL5 жыл бұрын
Nobody: Bisqwit: vpinserew and vpinsered and of course vpinsereq
@hotmultimedia5 жыл бұрын
It would be nice to have instrumentals of these videos as well.
@Bisqwit5 жыл бұрын
One of these months I will add the new music tracks on my extra channel.
@MKVideoful5 жыл бұрын
Are you planning to make compiler for x86? =D
@Bisqwit5 жыл бұрын
I actually created a compiler video series here on KZbin. kzbin.info/www/bejne/gajTlIKPgMuLkMU (Although the final few episodes are still WIP.)
@teckyify4 жыл бұрын
nice, but the music is a little too loud 😅
@xscitobor12335 жыл бұрын
this like listening to Dexter (From Dexter's laboratory) rant about computer history. :)
@crusaderanimation69672 жыл бұрын
POV: You try to get your saniti back by finding it in the comments.
@kahnfatman3 жыл бұрын
Tell me what moves you today!? MOVDQ2Q or MOV?
@TheBodgybrothers5 жыл бұрын
Great explaination of why the future is RISC processors.
@eone199 Жыл бұрын
ARM, zilog, and literally any processor company in the world will also do this if you let them lead the market... "You either die a hero or you live long enough to see yourself become the villain"