Hi there

I'd like to write bigger programs in assembler, but sadly i cant cope with the complexity of it. So i thought, i could build a virtual cpu/computer in a higher level language, and adjust the "difficulty" of programming in a assembler language.

(In my studies we didnt learn x86 assembler, but were the first semester to learn MMIX, a virtual RISC CPU with its own assembler. it even has its own website http://mmix.cs.hm.edu/ if you want to take a look at it.
But i dont like the language of it, also documentation is scarce)

i am most proficient in c# so i choose this to start (as the application logic seems simple i propably could also write it in c++ but i rather play it safe). But after an hour of programming, i came to the realization, that i dont know enough about computers to even get started. So i read about how a computer boots. that out of the way i got back to programming and implemented the first structures that are needed for a computer. A CPU, RAM,HDDS and so on. To make may later programmer life easier i chose to map EVERY device to memory at startup (64 bit, dont worry that the space runs out) starting at 0x80000.... I also decided to let the cpu execute programs directly from the devices

But then again i hit a roadblock. i didnt pay enough attention in my classes to still remember it 4 years later: Interrupthandling,Virtual Memory and Threads. I only remember the theory, and those topics are pretty big.

So now i am here, asking you if you want to help me
Maybe some of you also have interest in building a virtual cpu. The program structure allows for interchangeable instruction sets, so everyone can implement his own assembler if he wants.

I just need someone who can talk me through the topics mentioned above.
I know most of you will just tell me "read about it, search for it blabla" and i already did that, but there are questions that are not answered by the articles that i found. they all explain the basic theory, but not what the cpu does, or other components of the computer to achieve things. i hope that you people know more about these internals

thanks in advance

To look at your specific queries:

Interrupt handling: This is a hardware and a software question. The hardware will have devices that generate an interrupt (perhaps through an interrupt controller) and the software will then figure out which device is interrupting and do the appropriate things to clear it.

Virtual Memory: This require a paging mechanism of some type in the hardware. The software takes care of the mapping and boundary settings, while the hardware detects the violations and generates an exception. The exception generation would likely be part of the generic interrupt core.

Threads: This is almost purely a software paradigm. Have some hardware timer and let the OS decide what threads/processes it wants to make. If you want to support more than one CPU then the only extra you'll need is a communication link between them.

thanks for your answer

okay interrupts: when an interrupt is triggered (either software or hardware) what does the cpu do then? what happens to the registers? are all pushed on stack? where does it store the return address? why do i have to use iret instead of ret? what does iret do different than ret? (remeber i want to keep it simple for now, so i will try to generalize things e.g. only one type of interrupt without switching context)

yeah paging rings some bells, but i forgot how the lookup tables worked =/ but those are software anyway. what prerequisites do i need for paging? special registers, places in memory?

for now just one cpu. so is a context switch completely software? i dont remember it exactly, but does the cpu need anything else besides the scheduler interrupt to support threads?

thanks for using your time to help me

IRET vs RET is an x86 implementation detail. Other CPUs don't have such things. If you are making the CPU yourself then you can do something else.

For paging hardware you'll need either an MMU or a paging unit or both. An MMU is probably the easiest to understand and is the most flexible.

For threads your OS only has to restore the registers from a different context. For process switching you would likely also have to remap the MMU tables. The hardware is usually not deeply involved in the threading or process aspects, they are higher level software concepts.

okay one last question (i hope): how do i access physical memory directly with the mmu in place? would an instruction to disable it temporarily make sense?

Usually an MMU is set to identity mapping / bypass mode on power up. Later the OS will modify the tables and then turn it on/off as needed. But dedicating a CPU instruction for MMU control is probably not the best idea. Just use the MMU control registers.

okay thanks for taking the time to explain things i hope i can provide some results soon. i will post them here

BTW: For an example of a really simply exception mechanism take a look at the early ARM CPUs. And more generally look at other RISC CPUs for implementation ideas.

The x86 is extremely complex and perhaps too confusing to use as a basis for something simple.