I am TSO

[TSO]

I have 44 operations I need this thing to perform, which is probably a lot more than any other minecraft computer, so I'll just call it CSIC. The actual opcodes aren't going to be created until after the computer is built, so that I can reverse engineer the whole system and have the codes mirror the processes that occur in the system, thus reducing the number of decoders.(I already know one typically does this the other way, buy my mind just doesn't quite work like that.) All I know is the first two bits of the opcodes, which will tell the CPU where to ship the information.

44 is ALOT, unless you have a HUGE IS that is just all your control lines bussed to one Program Memory bank, I highly recommend either finidng someones IS you like a lot on the server and then make yours based on there layout (only at first, you can change it 100%, but it will give you a great place to start) or you can throw together a quick one to make sure you have some of your CPU's functions predetermined,, it sucks adding a bunch of features to a CPU and realizing you only needed like 1/3 of them to actually do what all your IS needs.
An IS also helps define a lot of basic asspects of your CPU, making it almost a road map for how to build it with out ever touching hardware.

I can quickly build the CPU, which is why I wasn't really worried about it, if you want me to. I don't know if I can upload the schematic, though.

Memory space greater than 16 bits can easily be addresses using 16 bits and the secret sauce. Pointers are possible to write, but aren't needed, and not all the memory is registers or cache. There is an hierarchy that allows for addressing more than the bit space available to the word size. Although, I don't have a solution for fast registers yet...

how are you going to use more then 16bit addressing on a 16bit system? And be aware, you can make a CPU with as much memory as you want, but are you ever going to make a porgram that ACTUALLY uses it? Or could you program a tad bit better and have the program use your memory more wisely.

The first part is through the use of magic.
You would want that memory for situations where... say... you wanted more than one program on the computer, or needed to run two at a time.
Also, a compiler will naturally waste memory, I don't know why because I'm not a programmer, but it's been explained to me that the higher the language you compile from, the more memory you waste, and the less efficient the code is, but the programming language becomes more understandable.

instant wire will fix bussing delays.
The Von Newman architecture is why it needs so much memory, and more secret sauce makes sure the computer has the program data as it's needed.

NO! instant wire bussing is a VERY VERY bad idea, I have seen many ppl (about half of which were long time MC CPU veterans) try and use it as one of those “cure all” solutions to bussing,, the timing will be hell, and you will end up wanting to pul ur hair out.
Also I personly dont ever use pistons.. in any CPU... ever... I hate them and there half tick nonsense and BUD glitches.. a Pistonless CPU (also called SS (Solid State) is much more predictible,
But if you like pistons and you want to use them, have at it just saying I personally dont like them at all.

We differ in opinion about pistons, but instant wire bussing can be managed rather easily once you get used to it. Also, builds like my oscilloscope actually pivots around the idea that pistons take a half tick longer than repeaters. If worse comes to worst, you can do something like insta-wire for nine chunks, then repeat 1 time, then skip the next nine, so that while the bus does have delay, it still is quite a bit faster than the typical bus. This also helps fix what Megazorb mentioned about there being maximum update, if that is true. (I have no idea if it is.)

Also, if you just look at the CPU, instructions and data do not share a bus, so it is modified Harvard, not Von Newman.

The ALU uses some basic calculus

“basic” is a very HARD word here...
Cause calculus isnt something that is normally done at a MC CPU level, due to the massive amount of ticks it will add to your CPU, and if ur only using a basic ALU to do these,, there will be a lot of time that it will be clogged preforming the “basic” task of your calculus.

This is where my "sorta pipelined" comes in. For example, the CPU could request a divide (which means calculus), in one cycle, but then request an add in the next cycle before the divide is even done. As long as the two don't conflict (RAW?... You aren't asking to add the quotient), everything is just fine. So really, the calculus just holds up one ALU operation, but the rest of the ALU is still free to be used for other functions. You could even simultaneously divide, square root, multiply, add, and take the mod function (that's ten separate registers being acted on) as long as one of those operations doesn't need the output of another on the input.

The entire system could use two's compliment floating point encoding for large integers, or it will use standard binary if told to.

2's comp is mainly for negitive, and floating point is decimal points (better known as Radix bits in binary) and you will need a good barrel shifter to be able to do FP well, I have a good design im working on if you want to use it.

Sorry, I was saying it has options to run any of the four permutations available from that. So positive normal, floating positive, two's compliment, or floating two's compliment. The only difference would be the selected opcode.

And most importantly: more than one computer can use the memory without any issues. This is where the secret sauce really gets lathered on there.

2 CPUs with one memory is a bad idea,, only do it if you have a system to manage memory that is independent from the CPU's themselves, otherwise you will have addressing confilicts and data hazards, as well as architectural hazards (more then 1 data packet wanting to go down same bus line at same time, and other stuff)

They wouldn't share bus lines (because they don't need to), and the rest falls under the veil of mystery.

I'm willing to bet a few of you already figured out what the secret sauce is made of, and the only reason it is even there is so that the computer can be programmed in a language other than machine code (like c or maybe just assembly), but I discovered that this single piece would allow for all of these other magical properties to suddenly be available because it would make the CPU itself run much faster because it only really has to do one thing now: move memory between registers or cache. This is a five(ish) tick process.

They may have but I have not figured this one out, but please tell me xD im curious.. and the way to make a CPU be able to be programmed in a higher lang, is by making a compiler and to have a GOOD IS that is small, yet feature rich, so you can easily port the coding in and out of the CPU's machine code.

I intend on programs to be compiled as they are being written, not real time.

I do suppose pipelining would be an option, but it would be more applicable toward the ALU than anything else. And this is just the first iteration anyway.

just saying the ALU is like the ONLY place you do not pipeline like ever, I mean you can yes, but due to speed limitations in MC, it doesnt give you any speed advantage, and to pipeline an ALU, you have to have a good hazard detection system and possibly OOOExe,, considering the delay of an OOOexe system,,, unless you make a milestone discovery it wont be beneficial to your clock speed/throughput.

I think we might be arguing different personal definitions of pipelining. I consider it to be any time one component is running two tasks at roughly the same time. So a pipelined ALU is just able to do more than one arithmetic on independent operands at roughly the same time. (As discussed above.)

Most of the instruction set actually just passes through the CPU, being routed to it's destination without any decoding at all.

well yes, all inst. Go though the CPU, xD that is what they are instructing and no.. u have to decode your Op's unless you want something so big that the straight control line programming will end up adding more delay then a simple decoder would have, and be about 5x the space

I mean like, out of a 32 bit instruction set, only the first two bits of the opcode are evaluated by the CPU, and only the registers mentioned in the instruction set get acted on. (So a little bit of decoding for the registers)

Upon consideration, I could venture to say that if you stood back far enough from it and squinted real hard, you would see something that sort of looked like a pipelined CPU.

doesnt work like that, either you are pipelined or your not,
the best way I would suggest you to get into pipelining is to do a 2 maybe 3 stage at first, and if you would like to do that, I can let you know the best way to go about that.

See above. This is why I really think we define it differently.

Also, just in case you still don't know the chunk loading thing I mentioned, I was talking about the spawn chunks. (Also, I had to look up what a command block was because I have never heard of them.)

this could work,, but a CPU is RARELY that big that it even comes close to going outside a render distance, and nothing outside the render distance (besides spawn chucks) even register when redstone is activated,, well they do SOMETIMES,, but its buggy enough that you can not use the system for a CPU as it wil corrupt data

Mostly memory is leaving render distance, which as I said is rather inactive, so I'll just have to see if it works out or not.