Which instruction set does the virtual CPU based on?
JamisHoo opened this issue · comments
Hello, rswier.
I'm interested in your project and now looking into it.
It seems that the virtual CPU is based on neither x86 nor arm instruction set. Is it an instruction set that defined by yourself? Is there any documentation about the hardware/software interface?
Thank you.
I designed my own instruction set after studying real architectures such as x86, arm, etc. I chose an accumulator/stack design because it was simple and fast and also easy to compile C code into.
I need to work on creating actual documentation. For now, the code is the best place to look. The programs root/usr/os/os*.c are examples of the hardware/software interface code that the kernel uses.
It's really an amazing piece of work! The instruction set isn't just an extension to the one you designed for c4. It's got more registers, making the implementation of VM and the compiler more complex (I think). Could you elaborate on the reason for this design decision?
Thanks, sorry I didn't respond earlier, I was having fun trying to decode your vmTetris VM!
My instruction set design and compiler went through many revisions before settling on the one here. I basically was trying to find the right balance that was simple to compile into but also ran at a good speed. It's a stack machine (so no need to do complex register allocation) but with a few extra registers (B and C) to speed up the majority of simple expressions. I was also trying to optimize for a simple VM interpreter making use of a for(;;) switch() loop. Finally I added instructions to support the minimum requirements to run a realistic OS: interrupts, kernel mode, traps, page tables, etc.
I'm currently working on a simpler version of swieros with a compiler that is much closer to c4. The instruction set would be about half as large, no B and C registers, and no floating point or networking. I also want to have it run in a browser with a GUI resembling the old BeOS or NextSTEP. ...but it may be a while before I get it all working!
Sounds like an ambitious project and I am excited about it.
My goal for vmTetris was to minimize the lengths of both the implementation of the VM and its tetris bytecode. I like high semantic density. 😄
Thanks for sharing these insights. I would not have expected that using a couple more registers would affect execution speeds significantly or that speed was a concern at all.
I am currently playing with the idea developing a simple fantasy game console specification and implementation, kind of like PICO-8 but different, with a more concrete CPU design like c4's. Searching for inspiration, I came across your projects. Mind if I copy some of your ideas?
Don't mind at all, just let me know about any cool thing you make!
Hello, just ran into your project, very impressive!
Are you still thinking about getting this project to run graphically in a browser? That would be very cool indeed, v6 OS running in a CPU emulator accessed through a terminal emulator, all being run by the JS or WASM bytecode emulator or JIT. I think we could make that work fairly easily using my Microwindows project, which implements both Win32 and Nano-X (Xlib-like) APIs, which we now have running through EMSCRIPTEN in a browser. We could hook up the Nano-X nxterm terminal emulator to access your shd which would be running through xem compiled under EMSCRIPTEN running OS v6. Let me know if you're interested and I'll help!
I develop on MacOS and think I can get your project bootstrapped onto 64 bit pointers and ints by changing u.h's uint to "typedef unsigned long uint" but haven't got into the guts of it yet with the stdint.h conflict with that change. C4 ported with a three line change.
Super work!
Robert - ignore my previous comment about 64 bit pointers in swieros... I had been looking at c4 and didn't quite realize the problem of the emulated cpu and os architecture require 4 byte ints so the compiler int-width can't be extended like c4 can, or things won't work. Lol. I've got some other ideas for bootstrapping.
Greg - I have been meaning to get back to work on swieros and your interest is good timing! I do need to make sure that it compiles and runs cleanly on modern 64 bit systems. As you mentioned, the internal simulated CPU will probably remain 32 bits, but that shouldn't be a big deal, in fact I believe that makes writing a JS emulator much simpler.
I wanted to hand-write an emulator in JS versus using Emscripten mostly to learn how to do it, but I did get kind of bogged down in figuring out the best way do the console and graphics... so, yes, I would definitely welcome your help if you wanted to work together on something. I love the idea you have of getting up and running with your browser based Nano-X implementation.
I am going to send an email to your censoft address from my gmail --Rob