From fnaumann@mail.cs.uni-magdeburg.de Wed Jan 28 23:29:45 2004 Date: Wed, 28 Jan 2004 23:20:11 +0100 From: Johan Klockars To: mint@fishpool.com Subject: Re: [MiNT] fVDI issues Message-ID: <20040128222011.GB28226@haddock.cd.chalmers.se> References: <07ba01c3e58b$26865ae0$0e0a63d9@blaszak> <20040128133429.9F91835450@komp7.euh-e.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040128133429.9F91835450@komp7.euh-e.edu.pl> User-Agent: Mutt/1.4.1i Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: rand@cd.chalmers.se Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: > > I hope we all agree that the current situation is hm... unacceptable > > in longer terms. I have no clear thoughts about VDI, but for the AES > > I think that Atari have made a mistake hooking it onto trap #2. Or > > any trap, to be strict. As a consequence we now have an AES running Absolutely. Even for the original ST, the current AES and VDI calling methods made little sense due to the lack of efficiency. I suppose they made for easier porting to the 68k, though. Now with real operating systems on our Atari's (and "compatibles"), we have another set of problem with the mechanisms. It's been a while since I last looked at the AES, but the VDI would be better off with a simple C function call like interface. Actually, fVDI converts many non-trivial operations to such a format internally already before jumping to the actual handling functions. The trivial operations have dual code, one for the standard case, and one C function call like version. The latter because that's how it would/will be used under the Fenix OS (and fVDI still stands for Fenix/Free/Fast VDI ;-). Here is one example (Called from the standard VDI dispatcher, returning to the original caller. Note that while the most of the paremeters are put on the stack, a pointer to them is sent in register a0, and the address of the virtual workstation is in register a0): dc.b 0,"vqt_name",0 * vqt_name - Standard Trap function * Todo: ? * In: a1 Parameter block * a0 VDI struct vqt_name: uses_d1 move.l intin(a1),a2 move.w (a2),d0 move.l intout(a1),a1 pea 2(a1) move.w d0,-(a7) move.l a7,a1 bsr lib_vqt_name addq.l #2,a7 move.l (a7)+,a1 move.w d0,-2(a1) used_d1 done_return In general, the library version of a VDI call such as vqt_name(handle, number, name) would be called from user code something like this: move.l name,-(a7) move.w number,-(a7) move.l handle,a0 ; Actual address rather than 16 bit index move.l a7,a1 jsr lib_vqt_name addq.l #8,a7 Or, if you wanted to have a trampoline that could take standard C VDI calls, perhaps with standard indexes (created by the v_opnvwk trampoline, for example): vqt_name_trampoline: move.w 4(a7),d0 ; Fetch the VDI handle move.l virtuals(pc,d0),a0 ; (Hmm, is that right?) lea 6(a7),a1 ; Point to the rest of the arguments jmp lib_vqt_name > VDI should be a kernel module. The main reason for this is speed. It would be even faster if only the things that really need to be in kernel mode actually are. Mainly that would be hardware accesses (on systems where you need to be in supervisor mode for that, but if you're going to be using memory protection, you had better try to enforce that, anyway), but some operations also need to modify global data. > The other way could be having both VDI and AES as kernel modules, and > AES should call VDI directly (ie. without using traps). I think this > is the fastest solution (CPU wise) and also could save some work. As I mentioned above, fVDI has most of the interface done for such direct calling. The original design document also describes how to do 'chained calls', where several VDI functions can be called with a single jump into the VDI, by creating a table of arguments. -- Chalmers University | Why are these | e-mail: rand@cd.chalmers.se of Technology | .signatures | | so hard to do | WWW: http://www.klockars.net Gothenburg, Sweden | well? | (fVDI, MGIFv5, QLem)