[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [f-cpu] More Dark and Dusty Corners



On Tue, 4 Sep 2001 whygee@club-internet.fr wrote:

> hello,
> 
> it seems that i have let this discussion pass...
> here are some hints.
> 
> BTW, how can a user-land SW emulate a virtual OS
> if the instructions have to trap when emulation
> must be done ?
> 
> I have no idea of how it works on mainframes (heck)
> but here is some idea :
>  1) there is a "capability bit" which allows the running
> code to modify its own Interrupt Routine Table pointer.
> This way, the IRQ table can be stored in the user land
> and be modified at will. Software interrupts/traps
> occuring from THIS user program (of course) are redirected
> to this table. HW interrupt and failures in the setup
> of the new table are redirected to the kernel.
> Note : When the bit is set, the "local IRQ table pointer"
> is stored in the CMB. This isolates every task for each others.

Hey, there is a small problem here. There may be a lot of
userland programs, all in need of such an own table for
emulation of unimplemented instructions. The extreme would
be to lead all instructions (nothing implemented) to the
table -> deadlock. Therefore a basic instruction set that
will always work must be defined.

>  2) setup the table so every "supervisor" instruction is
> trapped and handled by our code. Other instructions are simply
> "forwarded" (ie : FDIV emulation...) to the kernel by re-running
> the code inside the trap handler or something like that.
> 
> you're done.

layering could be a solution here.

inner Layer: working cpu hardware opcodes
middle Layer: emulated cpu opcodes (maybe onchip)
shell around this: virtual 'complete' cpu

I am talking about a chip still, no software delivery.

JG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/