Hey guys. Now I know the title makes this seem very non-game related, but this is actually for a game I am working on. So, basically, I want to design a simple CPU. I have done this in the past, but I have always simplified things. I haven't touched interrupts. All I have done is a basic cpu with registers, an instruction set, etc. but never any more. Now, for this game, I want to have a CPU of my own design that is 32 bit (64 maybe? probably not needed... but maybe) That is .. well.. maybe a bit more powerful than a Z80? As far as all of its features go. The main thing I need help with is interrupts. I think I pretty much get them, but I have little/no idea how they actually work and how to program them into an emulated CPU. I am going to start out by writing a detailed specification for the CPU to go by. That way, i'll know what im coding. But I would like to get the interrupts thing figured out first. If anyone is able to help me out with this, it would be greatly appreciated! Thanks!

EDIT:Maybe a more proper way to word it would be a simulated CPU not an emulated one...

Even if you managed to get everything working, I doubt it would be very powerful.Remember, you are sharing the (real) CPU with all other applications running on the system, including the system itself.

I havent started coding it.. I want to be able to understand how it will work before I try to code it... Thats why I plan to write a spec. But yes, I would have a method for each instruction. I suppose I should explain a little bit of how I envision it functioning:

Each cycle, a method called executeInsn (or something like that) would be called. This function would get the next instruction, increment the program counter and then execute the instruction.

It would of course be more than that (operands) but thats the BASIC idea of how it would work. Thats why I dont really get the labels... because if the program counter just goes up and up, something like this:

a real CPU has regiser values and just runs them one by one, a label is a refrence to one of these values.I have simplified the commands a little, but it should give some understandign how it works.Look into assemby languane for some more info.

Yeah it's minecraft, but it's all about making a CPU from the ground up, and if you know how redstone works, then it's even better. He has other tutorials as well of varying simplicity.You should also check out Wikipedia to start. You might quickly realize that making a CPU is not as simple as you thought.

ooh ive seen that series. i watch thebennybox's tutorials. as far as designing a cpu, ive done it.. but i havent included more advanced things like interrupts. thats why im trying to learn how those things work. i want the cpu im designing now to be more advanced than my previous ones.

So, basically, I want to design a simple CPU. I have done this in the past, but I have always simplified things. I haven't touched interrupts. All I have done is a basic cpu with registers, an instruction set, etc. but never any more.

Seems like you don't know how a CPU really works. Seems like the only reason you want to do an in-game CPU is to learn how a CPU fundamentally works. I suggest you read a good and informative book on the subject. I've personally read "Computer Organization and Design, 4th Ed" by D. A. Patterson and J.L. Hennessy. I recommend it highly.

However, there are other books such as: Behrooz Parhami, Computer Arithmetic: Algorithms andHardware Designs

Well I dont know that I would say "I dont know how a cpu works" ... but I dont know everything... Here is the link to the first project to do with cpu's I did:https://github.com/sci4me/S80-CPUThat repo is slightly out of date but .. its close. If you look through the S80 class (the cpu emu) .. well.. is that not a fairly realistic simulator? It is my own design so you may want to look at the spec. It is quite simple... but after looking at this, do you still feel I dont know how a cpu works? If so then I'll .. well.. learn more I guess.

Well, let's see if we can get some stuff straight here. First of all, there really isn't such thing as a "simple CPU" if you want something that actually functions. I recommend the book "Computer Systems - A Programmer's Perspective 2nd Edition" It goes through everything you need to do to simulate the x86 architecture (albeit with not quite as many instructions).

Things to consider when designing the cpu:

It's not as simple as reading a file and calling a function that represents each line.

You'll want to separate the different stages, such as getting the instructions (fetching), determining what they do (decoding), executing them, making changes to memory as needed, and then setting up the registers for the next cycle.

You'll want to look into pipe-lining (basically what I mentioned above). There are different methods of pipe-lining though, so it's good to know your options.

You'll need registers to store temporary data.

You'll need some memory for longer term storage.

You need to know what instructions you want to support and assign them all op-codes and operands. op code being the unique ID of an instruction and the operands being the information needed by the instruction to carry out whatever it does.

Labels are accomplished with a symbol table. You need map for each label and the address it corresponds to. This means you need to read through your assembly code twice. Once to build the symbol table and a second time to execute the instructions. (After being loaded into your memory) Symbols are used with jump instructions. So, when you call a jump, it's as simple as getting the address from the symbol table and setting the program counter to that.

Interrupts are exactly what they sound like. Though, what you don't understand is that is something that can be implemented on the code level. In your assembly code, you just create a subfunction that acts as the interrupt code to run, then whenever it needs to be called, you jump to it, and at the end of the subfunction, you return back to where you were. Case in point, that's not something you need to implement in your simulator.

This is really an extensive topic. I spent an entire semester learning nothing but how the CPU works and building my own simulator. It's not something you are going to be able to tackle in a few days time.

Start with a virtual machine, which is much easier than trying to emulate a real CPU. You don't need to deal with interrupts, pipelines, or any of that nonsense. Don't bother writing an assembler first, just write programs in raw opcodes. A stack-based VM is really easy to write and good to start with, though register-based is ultimately where it's at as interesting VMs go (the JVM is stack-based but it's more of an exception than the rule). Writing register allocation algorithms will teach you some really interesting computer science principles too.

Well, let's see if we can get some stuff straight here. First of all, there really isn't such thing as a "simple CPU" if you want something that actually functions. I recommend the book "Computer Systems - A Programmer's Perspective 2nd Edition" It goes through everything you need to do to simulate the x86 architecture (albeit with not quite as many instructions).

Things to consider when designing the cpu:

It's not as simple as reading a file and calling a function that represents each line.

You'll want to separate the different stages, such as getting the instructions (fetching), determining what they do (decoding), executing them, making changes to memory as needed, and then setting up the registers for the next cycle.

You'll want to look into pipe-lining (basically what I mentioned above). There are different methods of pipe-lining though, so it's good to know your options.

You'll need registers to store temporary data.

You'll need some memory for longer term storage.

You need to know what instructions you want to support and assign them all op-codes and operands. op code being the unique ID of an instruction and the operands being the information needed by the instruction to carry out whatever it does.

Labels are accomplished with a symbol table. You need map for each label and the address it corresponds to. This means you need to read through your assembly code twice. Once to build the symbol table and a second time to execute the instructions. (After being loaded into your memory) Symbols are used with jump instructions. So, when you call a jump, it's as simple as getting the address from the symbol table and setting the program counter to that.

Interrupts are exactly what they sound like. Though, what you don't understand is that is something that can be implemented on the code level. In your assembly code, you just create a subfunction that acts as the interrupt code to run, then whenever it needs to be called, you jump to it, and at the end of the subfunction, you return back to where you were. Case in point, that's not something you need to implement in your simulator.

This is really an extensive topic. I spent an entire semester learning nothing but how the CPU works and building my own simulator. It's not something you are going to be able to tackle in a few days time.

Did you look at that github? The S80 class? If that doesnt qualify as a simulation of a custom designed cpu then I dont know what does. But yes, you're still right. I don't know all of what I need to know. I've only started to scratch the surface as far as learning how cpu's actually function... but still...

Labels are accomplished with a symbol table. You need map for each label and the address it corresponds to. This means you need to read through your assembly code twice. Once to build the symbol table and a second time to execute the instructions. (After being loaded into your memory) Symbols are used with jump instructions. So, when you call a jump, it's as simple as getting the address from the symbol table and setting the program counter to that.

I think you confused compiler functionality and the execution phase. The compiler creates the symbol table, and uses it to calculate the absolute or relative jumps, storing the results directly as operands.

So an unconditional jump wouldn't be:

1

program_counter = symbol_table[decoded_label_index]

as that level of indirection is already resolved by the compiler, so we'd simply do:

1

program_counter = decoded_target_address

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

1: for this I would say dont go complicated do something like the redpower2 computers, they are very effective and do pretty much what you are asking for.2: probably dont need to worry about bits.3: To make your life a heck of a lot easier write an interpreter for the incoming code.4: if you want make an xml that holds your commands.5: yes as some people have said do something similar to a fouth language, people know it it's a lot easier to code and its commands are simple.

Anyway hope this goes well. Just dont try to simulate full computer functions that will not only destroy your tick and frame rate but also turn into inception and when you dont have a crazy guy who jumps into dreams then gets everyone killed with his dead wife and a train well, its not gonna work.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org