How would you design a CPU, from a software point of view?
How would you design a CPU, from a software point of view?
How would you design a CPU, from a software (i.e. operating system) point of view? how many registers would you put in it? what security mechanism would your CPU have?
Since writing an O/S is largely an exercise in fighting against each CPU's oddities, I would like to know what you guys think about CPUs and how they should be designed in order to allow the writing of modern and effective operating systems.
It's especially interesting to see what everyone things on modularization/componetization and O/S software engineering.
Since writing an O/S is largely an exercise in fighting against each CPU's oddities, I would like to know what you guys think about CPUs and how they should be designed in order to allow the writing of modern and effective operating systems.
It's especially interesting to see what everyone things on modularization/componetization and O/S software engineering.
I am think about code a cpu, in software, as a way to run the same asm coded program's on differant processors (just port the VM ).
Like a modern chip8 http://en.wikipedia.org/wiki/CHIP-8
The layout is still to be worked out.
Like a modern chip8 http://en.wikipedia.org/wiki/CHIP-8
The layout is still to be worked out.
Anyway, I've made my own CPU spec (attached).
It's nothing revolutionary. The most interesting point is the advanced protection mechanism. In a nutshell, it goes like this:
There are two tables for protection: a) the segment table, b) the access table.
The segment table defines how the 32-bit address space is segmented.
The access table defines the relationship between two segments for read, write and execute access.
This mechanism allows for a very fine-grained protection mechanism: each segment can can different access rights on any other segment (or itself).
Segments are used implicitly, much like the page table (i.e. there are no far pointers).
Additionally, I have made jumps targeted, i.e. if a jump does not transfer control to a known jump target, then a security violation exception is raised. This can limit invocation of wild pointers.
Finally, I have separated the stack into a data stack and a return-address stack, in order to get rid of buffer overflows exploits.
I think the mechanism is realistic and can be implemented in CPUs as an associative cache.
It's nothing revolutionary. The most interesting point is the advanced protection mechanism. In a nutshell, it goes like this:
There are two tables for protection: a) the segment table, b) the access table.
The segment table defines how the 32-bit address space is segmented.
The access table defines the relationship between two segments for read, write and execute access.
This mechanism allows for a very fine-grained protection mechanism: each segment can can different access rights on any other segment (or itself).
Segments are used implicitly, much like the page table (i.e. there are no far pointers).
Additionally, I have made jumps targeted, i.e. if a jump does not transfer control to a known jump target, then a security violation exception is raised. This can limit invocation of wild pointers.
Finally, I have separated the stack into a data stack and a return-address stack, in order to get rid of buffer overflows exploits.
I think the mechanism is realistic and can be implemented in CPUs as an associative cache.
- Attachments
-
- cpu.zip
- (4.65 KiB) Downloaded 73 times
So, good or bad? good, I presume .JamesM wrote:1. Many (general purpose) registers.
2. Intra-page protection. Essentially segmentation, but much easier segmentation. I.e. I just want to give/remove access of this range of virtual memory addresses to a process. It would mean that common heaps and common buffers wouldn't have to be page-aligned.
Other oppinions? of course, but i dont thing i have got enought knowledge on the subject to provide any usefull ideas.
I like to call my self "minimalistic perfectionist" which basicly means that if i dont need it i dont want it.
One of the nig issues i guess is the memory handling/protection. My oppinion on this is... well lets just say that i hate segments and paging and all that, if i want to use these features i can provide that posibility myself i should think. On a regular x86 system where i have to mess around with gdts, idts, ldts, and all that just to be enable "32/64bit mode" is just annoying. I believe there must be a better way.
I've allready said too much on a subject i dont really understand, but this is my oppinion non the less...
I like to call my self "minimalistic perfectionist" which basicly means that if i dont need it i dont want it.
One of the nig issues i guess is the memory handling/protection. My oppinion on this is... well lets just say that i hate segments and paging and all that, if i want to use these features i can provide that posibility myself i should think. On a regular x86 system where i have to mess around with gdts, idts, ldts, and all that just to be enable "32/64bit mode" is just annoying. I believe there must be a better way.
I've allready said too much on a subject i dont really understand, but this is my oppinion non the less...
This was supposed to be a cool signature...
I've worked on the Dynatos Virtual Machine Specification over the years. I am referencing it due to the register layout found in the VM.
The goal is simplicity of design. Simple instructions can be profiled and optimized better. I am still tweaking the program control (offseting instructions) to be more complete. This VM is the driving force behind my os development endeavors.
Any instructions with "???" next to it is something I came up with but later found questionably complex and possibly out of scope.
Let me know what you think
The goal is simplicity of design. Simple instructions can be profiled and optimized better. I am still tweaking the program control (offseting instructions) to be more complete. This VM is the driving force behind my os development endeavors.
Any instructions with "???" next to it is something I came up with but later found questionably complex and possibly out of scope.
Let me know what you think
I think you would like the ARM processor's.Zacariaz wrote:Other oppinions? of course, but i dont thing i have got enought knowledge on the subject to provide any usefull ideas.
I like to call my self "minimalistic perfectionist" which basicly means that if i dont need it i dont want it.
One of the nig issues i guess is the memory handling/protection. My oppinion on this is... well lets just say that i hate segments and paging and all that, if i want to use these features i can provide that posibility myself i should think. On a regular x86 system where i have to mess around with gdts, idts, ldts, and all that just to be enable "32/64bit mode" is just annoying. I believe there must be a better way.
I've allready said too much on a subject i dont really understand, but this is my oppinion non the less...
Thanks, I will look it up when I have time.SpooK wrote:I've worked on the Dynatos Virtual Machine Specification over the years. I am referencing it due to the register layout found in the VM.
The goal is simplicity of design. Simple instructions can be profiled and optimized better. I am still tweaking the program control (offseting instructions) to be more complete. This VM is the driving force behind my os development endeavors.
Any instructions with "???" next to it is something I came up with but later found questionably complex and possibly out of scope.
Let me know what you think