Speedy Computer Vlog Entry #1
Вставка
- Опубліковано 26 вер 2024
- The voters have spoken! There appears to be interest in making a computer run as fast as possible, and to be honest, the idea had intrigued me as well.
Of course, making a computer run as fast as possible is going to require a lot of engineering. And that's if I just decide to build a typical RISC style pipeline CPU.
But you know me, I'm not a fan of RISC :)
So in this first vlog, I'll be going over the CISC style ISA I put together for this project, some of the hurtles I'll need to overcome in order to put this together, and then I finally show off the prototype I made for the fetch stage of this computer project.
It's not anywhere near finalized. I will very likely need to redesign this whole stage later on. But for now, having something somewhat functional allows me to design the rest of the computer and get a better understanding of how the two should work together.
LINKS
My Discord: / discord
My Patreon: / n00b_asaurus
I'm working to make this sort of stuff professionally, and am looking for support. If you have a spare dollar each month, consider supporting my on my patreon! Doing so gets you access to my patreon feed, which is where I post project updates and exclusive tutorials weekly.
With higher tiers, you'll also get shout-outs in my videos, participate in Q&As, and even suggest a project.
Thank you!
honey wake up! noobasarus just uploaded!!!!
You say that on every video :P
@@n00b_asaurus damn right i do
awesome!
I certainly thought so :)
the egg came first, chickens evolved from dinosaurs
if you end up releasing this project i’ll probably end up writing a c compiler that targets this instruction set! i feel like that’d be really interesting to do
That would be interesting! I'll see what I can do on my end. But if and when it's released, lmk what you end up running on it :)
I believe you had said that size is the only constraint to complex computers within minecraft. That the physical distance in which the components work operations within the game are restraints on speed. What if you were to encase the computer completely and then used a shrink mod on the computer? Could you make the encased computer an individual object via code? I mean you can already shrink things and manipulate the size of matter in the game, what if this actually applies as it does in real life that faster computers require smaller components. What if when the components when shrunk actually perform computations far faster? Yes it is a reality warping idea but there is no reason it cannot work. design the computer at normal brick size and then once finished shrink it down to the scale of one brick in game. May some sort of fractal compression algorithms could be applied, I'm not sure but it was just a thought.
Very nice!
Thanks!
NO-OP can be replaced with MOV
I doubt CISC, Pipelining, etc. can be done in Minecraft efficiently with 10 ticks of a clock
It's definitely possible. Pipelining is standard (and pretty much necessary) on high clock speed Minecraft CPUs. The CISC part is taken care of by having a front-end which translates the CISC instructions into sequences of much simpler RISC-style micro-operations. So you really build a 10 tick clock pipelined RISC CPU and add a CISC front-end to it (which, by the way, is how real-life amd64 CPUs work too).
@@GreenJalapenjo Couldn't have said it better myself... mainly because I didn't know any of the technical terms you just mentioned :P
Also, I didn't know this was how real CPU's achieved this result! Very cool!
Of course, now that you've given me a name, I can start doing some research on the subject. That should make building this thing much easier!
@@n00b_asaurus It's what all those Intel/AMD microcode updates are about :P
I'm very impressed with your level of planning and how well you've thought through everything. I always just kind of start building and hope to end up with a functioning CPU.
By the way, have you considered building this computer on ORE as part of the ongoing CPU building competition?
I had my suspicions, but being the CPU wizards that they are, I just figured they had some better system :P
Also thanks! I'm not sure if I'd call this planning, so much as just documenting my ramblings, but thanks for noticing :)
I will say this though, because I've got a lot of the intuition for this stuff already in place, I was able to skip a significant number of steps! (that's probably why it looks like everything is planned out already) But this is uncharted territories for me, so my intuition is only going to get me so far.
In those situations, I'll usually do as you do, just kinda play with things until it makes sense.
I had not considered building this on ORE, but now that you mention the CPU competition, I just might copy it over when it's done.
I like ORE for their ability to share components and computer designs... not too fond of developing anything on there though.
possible, very possible
My best is 10hz computer it was very hard with a lot of comparator priming but I got it ran at 2gt or 1rt per second
I'm not going to pretend I understand what that means, but nice job regardless XP
I'm hoping I can avoid game breaking mechanics like that, but we'll see.
by exceptions do you mean like internal traps, like invalid instruction and stack overflow?
Yeah, basically. If I can implement some kind of ISR to handle those things, great! Otherwise, I'll probably just halt the computer.
Even that can be useful in preventing run-away code.
@@n00b_asaurus you could just have a set trap service routine in the code, just like you would have an interrupt service routine. that's what I did for my CPU and it works great, you can even have multiple trap service handlers in the code for each specific type of trap
Do you pin people???
If they mention something worth pinning, yeah.
RISC for life
Looks very cool.
Does this queue system mean that if you jump to another address, you would need to flush and re-populate the queues?
And if so, do you plan to set up any branch predictors?
@@96Kicek For unconditional branches, like jumps and interrupts, I shouldn't need to predict anything or flush the queue.
For the conditional stuff, or returns which require the address to be provided by the stack, I will likely need some kind of predictor/flush system.
That's all down the line though, so nothing's concrete yet.