Great start! And wonderful to see an 8088 rather than all the Z80 and 6502 projects (not that there’s anything wrong with those, in fact I’m building one myself), the weirdness of the 8088 multiplexed address-lines, 16-bit registers, and segments and so on, is really nice to see demonstrated in such a calm and professional way! Love the disassembly overlay, as well as the binary+hex numbers! Maybe consider adding small (paper) labels for the signal LEDs for those of us who forget which is which ;) Again, looking really good - can hardly wait for the next part!
The labels to the LEDs is a great idea, but I'm going to get rid of them in the 4th video, so for now I'll just add an overlay description in the upcoming video. Thanks!
Thank you so much. I'm currently working on the next video which, from what I can see, may be a little longer than the the previous ones, still, hopefully providing some interesting info on the 8086. See you there!
Ah, 8086/8088... It was part of my childhood. It's so lovely to see it working outside of a retro computer case... :) Also, I'm astonished on how many clock cycles are wasted without a pipelined CPU...
This video was a lot better than previous one. Keep making these videos. This is something that can help practically rather than just being something done purely for fun.
You're a hero interfacing a breadboard computer with the x86 architecture :) It is not the easiest one to toy around with, but most certainly most people have not seen a slo-motion x86 processor ever before! :)
Well, thank you very much! The major difference really is the multiplexed data/address bus, so once you add the latches it's not that different from, for example 6502 interface. I know 6502 well enough (it was my first CPU I ever programmed), but since there is plenty of videos on 6502 I thought it could be fun doing something slightly different :)
Really great video! Very interesting and easy enough for someone like me to understand. I hope this channel grows big, it is really underrated right now. Looking forward to seeing more
Thank you. Well, honestly, at the beginning I didn't expect for this channel to grow like it has until now. It is only two videos (the third one is coming this week), so hopefully it will grow even more. I guess it all depends on people's "likes" and comments - Google's algorithms seem to recommend videos which are commented on and these getting more "likes". Sadly, before the channel gets 1000 subscribers I cannot even publish a so-called "community post" just to say, for example: "Hi everybody! The next video is coming this week" kind of thing.
Good job. I had plans to build a microprocessor system myself but designed a relay logic calculator and a few video games instead. Then I learned what I needed to convert to integrated circuits. Your 6 ic project will maybe help me to do an microprocessor project project
I'm sure you don't plan to take it this far, but how much distance would there be between your breadboard computer and a PC-like 8088 computer? Would it just be a matter of selecting the right hardware to place at the right addresses, or is there a large amount of additional complexity in the PC-like design? Looking forward to the next video!
As a matter of fact, I did plan to build a proper x86 computer at some point. I planned it as a "future project for anyone to soldier themselves" kit, if they wish so. My main worry is to be able to make sure that the required chips are still easily available to purchase and that they can provide what we need. Just think about three aspects: keyboard, IO (disk) and video output. I have some ideas, but this is too early to express them here, I'm afraid. I hope it will clarify at some point soon and I hope I can share it here with You guys!
Well explained! I used Z80 for simplicity, nice to learn from another classic CPU. Is it known from the manual exactly how long an out instruction takes? Sometimes timing is essential and you have to count clockcycles in the loop.
Hi, thanks for watching. Yes, it is known: this particular one takes 10 cycles to execute on 8088/6. I remember counting clock cycles for each instruction in the 8-bit microcomputers (I used mostly Atari with the 6502). In these machines timing was often very important as the whole computer was using the same clock and you had to count cycles exactly to achieve some effects in graphics for example. In PC world it was less important as the CPU had its own clock, separate from other components. Additionally, all the future versions of the CPU (286, 386 and so on) while still being down-compatible, had improved their timings. So even if you counted the cycles for 8086 and the programme was ran using 80286 - timings would change completely. Not to mention that the clock itself would be much faster. Having said that, in the next video I will have to do exactly what you described ;-) as I will need a delay loop in my code driving the text LCD.
Hi! The 8088 microprocessor is exactly just that: a microprocessor. It fetches instructions from the flash memory (this is the chip on the bottom breadboard) and that is exactly what I was trying to show in this video. I used the 128kB flash: AT29C010 here. I understand that you ask about how you programme the flash. I used one of the "universal programmers" which you usually connect to your computer via USB and write using the software provided with your programmer. Search Google for "universal programmer" and you'll get the idea. Hope this helps. Thank you!
After reset, the CS (Instruction Segment register) of 8088/6 is initialised with the value of 0xffff. But in this case this fact has nothing to do with the jump instruction used in this video. The "jump" used here is the relative, short, 2-byte version encoded as "0xeb [val]". It simply adds the value of the second byte to the current IP (Instruction Pointer register). In this particular case the 2nd byte is "0xf8", which is "-8" (as it is a signed value). This make the CPU to subtract 8 from the current IP value (which points to the following byte). In this case IP=0x000b and it jumps to IP - 0x0008 = 0x0003 where the "add ah, al" sits. There is another (among others), long, 5-byte, inter-segment absolute JMP which assigns both CS and IP values from the immediate values. It is encoded as "0xea IP IP CS CS" and that's what we use in one of the next videos to jump out of the last 16 bytes of ROM.
Thank you Alessio - I'm glad you like it! That's a very good question. This proves that maybe I should make a separate video only about the x86 assembler. Forgive me that I didn't explain it in this one. The reason that the second byte of this JMP instruction is F8 not F3 ( is at offset FFFF3, not F2 by the way) is that this short 2-byte version is a relative JMP instruction. It means that it contains not the destination address, but just an offset of how many bytes the destination is away from the following instruction (not the JMP itself). The offset (F8 in this case) is a signed number. Just as a quick reminder: a signed number has its "sign bit" (the most significant bit) set when it is negative. You get negative numbers by "rolling over" from 00 back to FF, so FF is "-1", FE is "-2" and so on. Therefore, in this case, F8 (or "-8") means that the CPU needs to jump back 8 bytes from the address AFTER the JMP itself. The next address after the JMP is FFFFB (not shown in the video), so the CPU jumps back to FFFFB - 8 = FFFF3.
@@SladorSoft Thanks for explanation! 👍 Usually, when I see JMP instruction, I'm expected to see full adress with LSB first.. I'm very familiar with 8 bit CPUs.. 😂 But, my first idea was similar, for what was actually going on, with that instruction.. P.S. Great content, anyway! 👍
@Arturs Mihelsons: Thank you! In the 8-bit CPUs the same encoding is used in any conditional branch instructions in 6502 (BCS, BEQ etc) and in, for example: "JR $+3" of the Z80. In all of these cases the instruction contains a relative 8-bit signed value.
Hi @keiichicom7891! Thanks for that. Yes, my aim is to implement the BIOS to be able to boot DOS on my computer - maybe not this one on the breadboard, but the one I'm building in more recent videos.
Hi Joseph, Short answer is: some do, some don't ;-) Unlike the ARM, for example, the x86 has variable length instructions. Those which don't need any additional immediate data may be just 1-byte long (like NOP, STI or POP ), other may require 1 additional byte (like JMP ), where the JMP opcode EB is followed by a 1-byte signed value to specify how many bytes to jump (which you can see in this video at address of F0016). The longest instruction may be 6-byte long on 8086 (!), for example: "ADD [xxxx], yyyy", which is encoded as: "81 06 XX XX YY YY", which adds "yyyy" to the value in memory addressed by "xxxx"
@@SladorSoft ok, thx. I've designed a few cpus myself, work custom instruction sets. How does the x86 cpu know hope long each instruction is going to be? Also, wouldn't waiting for each fetch before executing an instruction be slower? (Just spitballing here, since all the instruction sets I made either were 16 bit word, or 8, but the entire instruction was given each fetch)
I assume that x86 knows how many bytes it needs by examining the first one. I have never thought about it in terms of CPU design, to be honest. I don't design CPUs - I programme them ;-) The x86 is a CISC processor - each instruction takes a few cycles to execute (especially in 8086 - next versions were more efficient) and the CPU has a prefetch queue which it populates (when the bus is idle) during executing the current (already fetched) instruction. That's what I was trying to show in this video around 29:50 when the CPU fetched a byte from FFFFB while executing the JMP at FFFF9.
It depends whether you used a crystal oscillator with your 8284, or a button and you clocked it manually. If you used a crystal, the clock would obviously be very fast and the LEDs would blink so quickly, that they would appear all on. If you used a button and generate the clock manually, after 7 ticks from the reset, you would see exactly the same outcome as in the video (around 8:40 mark), so the 16 LEDs would be turned on (in A19 to A4 lines) and the rest 4 (A3 to A0) would be off.
Thanks Gautham for looking at my channel. There are so called "universal programmers" available, which you connect to your computer via the USB port and which have ZIF sockets (similar to the one on my breadboard) for your flash memory. You then upload the binary file from your computer to this programmer which in turn loads it into your flash. Flash memory can be programmed "in-the-system" as well (providing you correctly connect its WE, or Write Enable signal), but it's not as straight-forward as with the RAM: flash is programmed in blocks (usually somewhere between 512B and 4kB each). I thought it was not worth describing in the videos as it is not crucial for the subject and I decided to spare the viewers yet another digression ;-)
@@SladorSoft would be great if you did a video about that, because it was a jarring jump to suddenly having a program somewhere but no idea how it got there!!! (Unless you have in later videos... )
No I haven't, but there should be no difference in the programme nor the outcome. I ran Fibonacci sequence again, step by step on 8088 and using full 16-bit registers in part 6 of this series th-cam.com/video/8G3bwkIS3do/w-d-xo.html around 13:00 mark.
That's a good point, but: it would significantly complicate the whole contraption as it would require two RAM chips and two flash memories, or a special additional logic for one flash. As a result, not much would change, apart from having 16 LEDs instead of 8 on the data bus ;-). Also, 8086 is much more popular than 8088 (even IBM didn't decide to use it at the time). Having said that, I've added this idea to my list of things to try and show in the future, so thank you for pointing that out!
I have the 16-bit data bus on my list of future videos. Just one correction: in the previous comment I meant to write that 8088 is more popular than 8086, but I swapped them around.
noticing it skipped the first "1" in the fibonacci sequence [1 1 2 3 5 8 13 ...] I think if you were to swap the lines "xchg al, ah" and "out 0x0, al" it would show that first "one" also
Hi! Yes, that's a fair point - it would then show the other "1" as well, but my point in this test was just to show the CPU doing something recognisable on the LEDs in as short code as possible. I hope the missing "1" didn't completely ruin that ;-)
4th micro-op is when a decoded instruction is executed? There are no micro-ops within that? This is a truly byzantine architecture..... and it's only on its initial revision lol. No wonder we studied MIPS in class not this nonsense, x86 we only looked at from whole opcodes.
![Memory map and interrupts - Building and programming a 16-bit Intel x86 breadboard computer [part 3]](http://i.ytimg.com/vi/CzL9ab3LkNA/mqdefault.jpg)
![Memory map and interrupts - Building and programming a 16-bit Intel x86 breadboard computer [part 3]](/img/tr.png)
![First Run - Building and programming a 16-bit Intel x86 breadboard computer [part 1]](http://i.ytimg.com/vi/VvyUAaRTsww/mqdefault.jpg)
Nice, don't stop this series
Thank you for your appreciation. I will do my best to carry on with this series! Thank you!
The moment i found this video series, i knew that i have found GOLD! Thank you for your excellent videos😃😃
Thank you! I'm really glad that you've found it useful :-)
Great start! And wonderful to see an 8088 rather than all the Z80 and 6502 projects (not that there’s anything wrong with those, in fact I’m building one myself), the weirdness of the 8088 multiplexed address-lines, 16-bit registers, and segments and so on, is really nice to see demonstrated in such a calm and professional way!
Love the disassembly overlay, as well as the binary+hex numbers!
Maybe consider adding small (paper) labels for the signal LEDs for those of us who forget which is which ;)
Again, looking really good - can hardly wait for the next part!
The labels to the LEDs is a great idea, but I'm going to get rid of them in the 4th video, so for now I'll just add an overlay description in the upcoming video. Thanks!
Variety is always good.
Subscribed! Great seeing alternative CPU's on breadboards. Can't wait to see more.
Thank you so much. I'm currently working on the next video which, from what I can see, may be a little longer than the the previous ones, still, hopefully providing some interesting info on the 8086. See you there!
wow, this video is so fun to watch, and I've got a whole lot about the actual working process of a real cpu. AMAZING JOB, Slador!
Ah, 8086/8088... It was part of my childhood. It's so lovely to see it working outside of a retro computer case... :) Also, I'm astonished on how many clock cycles are wasted without a pipelined CPU...
This video was a lot better than previous one. Keep making these videos. This is something that can help practically rather than just being something done purely for fun.
Nice Fib assembly program that uses x86's half registers with a register xchange or internal swap. It's compact, simple, efficient and elegant.
I had to keep it small to fit in 16 bytes :-) Thank you for your appreciation!
You're a hero interfacing a breadboard computer with the x86 architecture :) It is not the easiest one to toy around with, but most certainly most people have not seen a slo-motion x86 processor ever before! :)
Well, thank you very much! The major difference really is the multiplexed data/address bus, so once you add the latches it's not that different from, for example 6502 interface.
I know 6502 well enough (it was my first CPU I ever programmed), but since there is plenty of videos on 6502 I thought it could be fun doing something slightly different :)
Really great video! Very interesting and easy enough for someone like me to understand. I hope this channel grows big, it is really underrated right now. Looking forward to seeing more
Thank you. Well, honestly, at the beginning I didn't expect for this channel to grow like it has until now. It is only two videos (the third one is coming this week), so hopefully it will grow even more. I guess it all depends on people's "likes" and comments - Google's algorithms seem to recommend videos which are commented on and these getting more "likes". Sadly, before the channel gets 1000 subscribers I cannot even publish a so-called "community post" just to say, for example: "Hi everybody! The next video is coming this week" kind of thing.
Good job. I had plans to build a microprocessor system myself but designed a relay logic calculator and a few video games instead. Then I learned what I needed to convert to integrated circuits. Your 6 ic project will maybe help me to do an microprocessor project project
Great stuff, looking forward to the next one!
That's awesome, thank you. The next one should be ready in the first half of September, stay tuned!
Thanks for explaining all the registers and what their origins and intended purposes are.
So satisfying to watch breadboard builds. Nice job!
TH-cam engagment! Great series Slador! Hope to see a lot more in the future!
Amazing channel, so happy to discover it.!!!!!
Thank you! I'm really glad you like it!
Classic, fun and clear! Great job, don't quit! :)
Excellent video! Thank you!
Thank you for Good Simulation ~~😍😍😍
Great series, might even build one myself!
Thank you and by all means, please do so!
Very awesome 👏
Thank you 😁
Lovely
Bravo 👏
This is really cool.
Excellent
Thank you! Cheers!
I'm sure you don't plan to take it this far, but how much distance would there be between your breadboard computer and a PC-like 8088 computer? Would it just be a matter of selecting the right hardware to place at the right addresses, or is there a large amount of additional complexity in the PC-like design? Looking forward to the next video!
As a matter of fact, I did plan to build a proper x86 computer at some point. I planned it as a "future project for anyone to soldier themselves" kit, if they wish so. My main worry is to be able to make sure that the required chips are still easily available to purchase and that they can provide what we need. Just think about three aspects: keyboard, IO (disk) and video output. I have some ideas, but this is too early to express them here, I'm afraid. I hope it will clarify at some point soon and I hope I can share it here with You guys!
@@SladorSoft please, do it. A PC like kit would be awnsome.
I would like to see you add a clock and see how fast it will run on the bread board with those long jumpers and no bypass
I actually did it in the next video. In my tests (off camera) it was happily running with the 8MHz clock ;-)
Very interesting! Hope to watch coding it with Assembler at least.
You'll see coding it not only with assembler, but also some C and C++ as well. Thank you!
Well explained! I used Z80 for simplicity, nice to learn from another classic CPU.
Is it known from the manual exactly how long an out instruction takes? Sometimes timing is essential and you have to count clockcycles in the loop.
Hi, thanks for watching. Yes, it is known: this particular one takes 10 cycles to execute on 8088/6. I remember counting clock cycles for each instruction in the 8-bit microcomputers (I used mostly Atari with the 6502). In these machines timing was often very important as the whole computer was using the same clock and you had to count cycles exactly to achieve some effects in graphics for example. In PC world it was less important as the CPU had its own clock, separate from other components. Additionally, all the future versions of the CPU (286, 386 and so on) while still being down-compatible, had improved their timings. So even if you counted the cycles for 8086 and the programme was ran using 80286 - timings would change completely. Not to mention that the clock itself would be much faster. Having said that, in the next video I will have to do exactly what you described ;-) as I will need a delay loop in my code driving the text LCD.
How do i add the code to the microprocessor?
Hi!
The 8088 microprocessor is exactly just that: a microprocessor. It fetches instructions from the flash memory (this is the chip on the bottom breadboard) and that is exactly what I was trying to show in this video. I used the 128kB flash: AT29C010 here.
I understand that you ask about how you programme the flash. I used one of the "universal programmers" which you usually connect to your computer via USB and write using the software provided with your programmer. Search Google for "universal programmer" and you'll get the idea.
Hope this helps. Thank you!
@@SladorSoft Thank you!
27:30 - binary to hex machine code
Since the jump worked, it would seem the Instruction Segment register has an initial value of 0xFF?
After reset, the CS (Instruction Segment register) of 8088/6 is initialised with the value of 0xffff. But in this case this fact has nothing to do with the jump instruction used in this video. The "jump" used here is the relative, short, 2-byte version encoded as "0xeb [val]". It simply adds the value of the second byte to the current IP (Instruction Pointer register). In this particular case the 2nd byte is "0xf8", which is "-8" (as it is a signed value). This make the CPU to subtract 8 from the current IP value (which points to the following byte). In this case IP=0x000b and it jumps to IP - 0x0008 = 0x0003 where the "add ah, al" sits.
There is another (among others), long, 5-byte, inter-segment absolute JMP which assigns both CS and IP values from the immediate values. It is encoded as "0xea IP IP CS CS" and that's what we use in one of the next videos to jump out of the last 16 bytes of ROM.
in the meantime, congratulations for the video, then I would like to know Why in the JMP instruction the label has the address F8 rather than F2 ?
Thank you Alessio - I'm glad you like it!
That's a very good question. This proves that maybe I should make a separate video only about the x86 assembler. Forgive me that I didn't explain it in this one.
The reason that the second byte of this JMP instruction is F8 not F3 ( is at offset FFFF3, not F2 by the way) is that this short 2-byte version is a relative JMP instruction. It means that it contains not the destination address, but just an offset of how many bytes the destination is away from the following instruction (not the JMP itself). The offset (F8 in this case) is a signed number. Just as a quick reminder: a signed number has its "sign bit" (the most significant bit) set when it is negative. You get negative numbers by "rolling over" from 00 back to FF, so FF is "-1", FE is "-2" and so on. Therefore, in this case, F8 (or "-8") means that the CPU needs to jump back 8 bytes from the address AFTER the JMP itself. The next address after the JMP is FFFFB (not shown in the video), so the CPU jumps back to FFFFB - 8 = FFFF3.
@@SladorSoft thanks, really exhaustive answer
@@SladorSoft Thanks for explanation! 👍 Usually, when I see JMP instruction, I'm expected to see full adress with LSB first.. I'm very familiar with 8 bit CPUs.. 😂
But, my first idea was similar, for what was actually going on, with that instruction..
P.S. Great content, anyway! 👍
@Arturs Mihelsons: Thank you!
In the 8-bit CPUs the same encoding is used in any conditional branch instructions in 6502 (BCS, BEQ etc) and in, for example: "JR $+3" of the Z80. In all of these cases the instruction contains a relative 8-bit signed value.
Cool, since Microsoft released the older dos/windows source code in the public domain, I wonder if there is a version for this.
Hi @keiichicom7891! Thanks for that. Yes, my aim is to implement the BIOS to be able to boot DOS on my computer - maybe not this one on the breadboard, but the one I'm building in more recent videos.
Quick question: don't instructions include more than just the opcode? (In a complete noob when it comes to x86)
Hi Joseph,
Short answer is: some do, some don't ;-)
Unlike the ARM, for example, the x86 has variable length instructions.
Those which don't need any additional immediate data may be just 1-byte long (like NOP, STI or POP ), other may require 1 additional byte (like JMP ), where the JMP opcode EB is followed by a 1-byte signed value to specify how many bytes to jump (which you can see in this video at address of F0016). The longest instruction may be 6-byte long on 8086 (!), for example: "ADD [xxxx], yyyy", which is encoded as: "81 06 XX XX YY YY", which adds "yyyy" to the value in memory addressed by "xxxx"
@@SladorSoft ok, thx. I've designed a few cpus myself, work custom instruction sets. How does the x86 cpu know hope long each instruction is going to be? Also, wouldn't waiting for each fetch before executing an instruction be slower? (Just spitballing here, since all the instruction sets I made either were 16 bit word, or 8, but the entire instruction was given each fetch)
I assume that x86 knows how many bytes it needs by examining the first one. I have never thought about it in terms of CPU design, to be honest. I don't design CPUs - I programme them ;-)
The x86 is a CISC processor - each instruction takes a few cycles to execute (especially in 8086 - next versions were more efficient) and the CPU has a prefetch queue which it populates (when the bus is idle) during executing the current (already fetched) instruction. That's what I was trying to show in this video around 29:50 when the CPU fetched a byte from FFFFB while executing the JMP at FFFF9.
@@SladorSoftI'm back lmao and I'm no longer a noob (I built an 8086 clone in logisim)
Wow! :-O That's impressive. Congrats!
I followed your schematic if without ram and ROM, and I used clock from 8284 what should I get shown in address and data?
It depends whether you used a crystal oscillator with your 8284, or a button and you clocked it manually. If you used a crystal, the clock would obviously be very fast and the LEDs would blink so quickly, that they would appear all on. If you used a button and generate the clock manually, after 7 ticks from the reset, you would see exactly the same outcome as in the video (around 8:40 mark), so the 16 LEDs would be turned on (in A19 to A4 lines) and the rest 4 (A3 to A0) would be off.
Just wondering, I'm not an engineer, curious to know how was the code loaded into the flash memory
Thanks Gautham for looking at my channel. There are so called "universal programmers" available, which you connect to your computer via the USB port and which have ZIF sockets (similar to the one on my breadboard) for your flash memory. You then upload the binary file from your computer to this programmer which in turn loads it into your flash.
Flash memory can be programmed "in-the-system" as well (providing you correctly connect its WE, or Write Enable signal), but it's not as straight-forward as with the RAM: flash is programmed in blocks (usually somewhere between 512B and 4kB each).
I thought it was not worth describing in the videos as it is not crucial for the subject and I decided to spare the viewers yet another digression ;-)
@@SladorSoft Wow! That was so crystal clear, looking forward to see more amazing content.
@@SladorSoft would be great if you did a video about that, because it was a jarring jump to suddenly having a program somewhere but no idea how it got there!!! (Unless you have in later videos... )
Can you make a video on program you are writing your code on and how you upload it to the eeprom
Hi! I think I will make this video soon - you're not the first one asking.
Thanks!
Looking forward to seeing you run Linux on this!
Have you run the Sequence code on the 80188 yet?
No I haven't, but there should be no difference in the programme nor the outcome. I ran Fibonacci sequence again, step by step on 8088 and using full 16-bit registers in part 6 of this series th-cam.com/video/8G3bwkIS3do/w-d-xo.html around 13:00 mark.
When will be the next episode releaded? I want to learn more
Thank you for your interest. I expect the next episode to be ready next week. Please be patient.
Hope for New content!!!
It's coming, I promise. Just need some time to edit my new recording.
Whats inside that chips? How it works? Can u explain?
Why not use an 8086 and demonstrate 16 bit bus?
That's a good point, but: it would significantly complicate the whole contraption as it would require two RAM chips and two flash memories, or a special additional logic for one flash. As a result, not much would change, apart from having 16 LEDs instead of 8 on the data bus ;-).
Also, 8086 is much more popular than 8088 (even IBM didn't decide to use it at the time).
Having said that, I've added this idea to my list of things to try and show in the future, so thank you for pointing that out!
@@SladorSoft Reason why I ask, is I intend to breadboard a 68000 someday and it has a lot of the ssme concerns.
I have the 16-bit data bus on my list of future videos. Just one correction: in the previous comment I meant to write that 8088 is more popular than 8086, but I swapped them around.
noticing it skipped the first "1" in the fibonacci sequence [1 1 2 3 5 8 13 ...]
I think if you were to swap the lines "xchg al, ah" and "out 0x0, al" it would show that first "one" also
Hi! Yes, that's a fair point - it would then show the other "1" as well, but my point in this test was just to show the CPU doing something recognisable on the LEDs in as short code as possible. I hope the missing "1" didn't completely ruin that ;-)
27:00 The first border collie chip
School PCs be like
4th micro-op is when a decoded instruction is executed? There are no micro-ops within that? This is a truly byzantine architecture..... and it's only on its initial revision lol. No wonder we studied MIPS in class not this nonsense, x86 we only looked at from whole opcodes.
Oh no I see it's even more convoluted than that lol.