What I want to do is write a VM in which RSP is the IP (instruction pointer). I set RSP to the start of some threaded code, and do a RET to execute the first one. Each word in the threaded code ends with RET to execute the next one. This is called "stack-threading" (I learned about this over on clax).
My concern is that interrupts would use the RSP stack to hold the registers and flags and other temporary data, which would overwrite my threaded code. The precludes stack-threading for micro-controllers. Does it preclude stack-threading for Menuet though? I have heard that most if not all modern OSs for the x86 (and the 64-bit ARM, etc.) don't use the RSP stack for interrupts, but switch to a different memory space and register set when an interrupt occurs. True?
why do such a scheme? Fair enough if it's just for the heck of playing around... but it's going to be slow & bulky compared to other solutions.
Well, it seemed pretty cool when I first heard about it (I've been programming in Forth for a long time, but I had never heard of stack-threading before, which I thought was remarkable). I have my doubts about it now though, which is why I went with a more traditional approach (using RSI as the IP) instead.
The advantage is that NEXT is just a single RET instruction, which is very fast. That is faster than subroutine-threading, in which NEXT is essentially a CALL and a RET.
These are the disadvantages:
1.) Like all DTC (direct-threaded-code) system, the docolon code is scattered all over the place, so it will almost never be in the code cache when it gets jumped to. By comparison, with ITC (indirect-threaded-code), which I switched to instead, there is only one docolon function --- the whole VM can fit inside of the 32KB code cache.
2.) The threaded code is bulky because all of the pointers are 64-bit (in 64-bit mode, this is required by RET). With any other approach (other than subroutine-threading), the pointers can be 32-bit even in 64-bit mode, which halves the program size. We want the colon words to fit in a single 64 byte page if possible, to reduce cache thrashing.
3.) The pointers are all absolute addresses, so we can't have binary overlays.
#3 is really why I dropped the idea of stack-threading for my current project, as I want to have overlays --- primarily so the users can distribute libraries of code without also distributing the source-code.
What do you suggest for a threading scheme?
Also, if I did experiment with stack-threading, can I be sure that the OS won't clobber memory under RSP? I don't want to start with stack-threading at all, unless I can be sure of this, so I don't get the rug pulled out from under me.
The whole point of this project is for it to be a cross-compiler. This is for micro-controllers such as the PIC24. After I get the cross-compiler to work though, I might try targeting the x86 itself --- I could experiment with different threading schemes fairly easily at that time, as the whole cross-compiler framework would already be there.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You can attach files in this forum You can download files in this forum