From fnaumann@mail.cs.uni-magdeburg.de Sat Jan 24 17:06:41 2004 Date: Sat, 24 Jan 2004 17:04:39 +0100 From: Johan Klockars To: mint@fishpool.com Subject: Re: [MiNT] fVDI issues Message-ID: <20040124160439.GA24271@haddock.cd.chalmers.se> References: <20040122144133.GC17739@haddock.cd.chalmers.se> <00d401c3e198$9a156d80$0e0a63d9@blaszak> <20040123191858.GA28238@haddock.cd.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 you'll talk to those of us who are involved in writing VDIs and > > AESes before deciding on something overly general? > > I don't have a concrete implementation in mind yet but performance is for > sure one goal :-) I'm very happy to hear that. Perhaps it would be a good idea if the VDI and AES developers talked a bit about what we want/need from this kind of functionality in MiNT? And, of course, it would be good if the MiNT kernel developers could describe what thoughts they have about this kind of interface. > > For example, something like vsl_color is about a dozen instructions > > of actual work in fVDI. Even with a minimal VDI dispatcher, there are > > already two dozen instructions of 'overhead' on top of that (saving > > only two registers on the stack). > > Entering the kernel is an expensive operation, also for routines that just > consist of one line (getpid and these things). I'm well aware of that, and have complained about it before. ;-) So, at least for the VDI, fully entering the kernel (build_context etc) is not really an option, IMHO. At least not unless deemed necessary after return from the VDI code (for example if the time slice is up). It doesn't really matter if getpid() takes a long time, since it's not called often. And the same applies to most (all?) of GEMDOS/BIOS/XBIOS, and probably the AES. VDI usage can be quite different, though, with sometimes thousands of calls per second. Many often called VDI routines can make do with only a couple of registers saved on the stack. None of them pass any parameters on the stack. None of them, AFAICR, would have any reason to ever require a process to suspend. Does MiNT currently do anything about pointers passed to system calls under memory protection, by the way? Or will for example an Fread to memory not owned by the calling process succeed? The VDI (and the AES) passes a bunch of pointers around for every single call, and then there are things like the MFDBs. Actually, it would make sense to make parts of the VDI actually execute in user mode. It's unfortunate that we're stuck with the Trap #2. -- 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)