From owner-cvs-sys Fri Apr 11 01:02:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA03393 for cvs-sys-outgoing; Fri, 11 Apr 1997 01:02:42 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.dialix.com [192.203.228.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03382; Fri, 11 Apr 1997 01:02:18 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.5/8.8.5) with ESMTP id QAA01477; Fri, 11 Apr 1997 16:01:55 +0800 (WST) Message-Id: <199704110801.QAA01477@spinner.DIALix.COM> X-Mailer: exmh version 2.0gamma 1/27/96 To: Guido van Rooij cc: bde@zeta.org.au (Bruce Evans), peter@freefall.freebsd.org, cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 genassym.c machdep.c trap.c src/sys/i386/include pcb.h In-reply-to: Your message of "Fri, 11 Apr 1997 09:39:18 +0200." <199704110739.JAA06258@gvr.win.tue.nl> Date: Fri, 11 Apr 1997 16:01:54 +0800 From: Peter Wemm Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Guido van Rooij wrote: > Bruce Evans wrote: > > >> This change makes VM86 mode harder, but the following commits will rem ove > > >> a lot of constraints for the VM86 system, including the possibility of > > >> extending the pcb for an IO port map etc. > > > > > >Yes! Finally get rid of the old /dev/io hack ;-) > > > > It would mainly make things more complicated and cost more. Accesses > > through the port map cost 20 cycles extra. There would be up to 64K of > > ports to manage. Who knows where the DMA ports (if any) on new video > > cards are? > > The extra cost is only for ppl using the io port map. As far as I understand > it this map is optional. When non-present you don't have to fiddle > with it. So the performance penalty is only for those ppl. Also, it's per IO port access, isn't it? As I understand it, most of the IO port access is done when setting up the memory mapped "window" in high memory (on pci cards), or things like bank switching, setting the palette etc on the older cards. As for the other penalties, there is a difference in the context switching behavior when switching between a "normal" process on the shared tss and a process that's got it's own tss. I couldn't say for sure how much the speed difference would be, but having the testing to determine the state of the current tss settings won't be completely free. On the other hand, it seems as though somebody (who I will not name) has already got this working... (You know who you are.. :-) > -Guido Cheers, -Peter