X-Received: by 10.66.157.35 with SMTP id wj3mr6090246pab.11.1392475092863; Sat, 15 Feb 2014 06:38:12 -0800 (PST) MIME-Version: 1.0 Path: csiph.com!usenet.pasdenom.info!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.ripco.com!news.glorb.com!uq10no22001658igb.0!news-out.google.com!s3ni20361qas.0!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 15 Feb 2014 08:38:12 -0600 X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp@delorie.com Date: Sat, 15 Feb 2014 16:37:46 +0200 From: Eli Zaretskii Subject: Re: __dpmi_int() or int86() ? In-reply-to: X-012-Sender: halo1@inter.net.il To: djgpp@delorie.com Message-id: <83d2iobfwl.fsf@gnu.org> References: Reply-To: djgpp@delorie.com Errors-To: nobody@delorie.com X-Mailing-List: djgpp@delorie.com X-Unsubscribes-To: listserv@delorie.com Precedence: bulk Newsgroups: comp.os.msdos.djgpp Organization: None provided DJ-Gateway: from mailing list djgpp@delorie.com Lines: 13 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-FQPNQw1QM4/4AvlA1XxPlie/BBXkuDqIZZ4rz/H4JHkOwQ6pVt+690rhuQnyVfe2qgIR6lGERRxEBKp!7YEk+vd+uP1nMWm7D7g+WzJ/4lu3WvghU1lWhL8XuyY= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 1942 Xref: csiph.com comp.os.msdos.djgpp:1729 > From: "Rod Pemberton" > Date: Sat, 15 Feb 2014 05:03:46 -0500 > > But, which is _actually_ faster with CWSDPMI for calling > RM interrupts? PMODEDJ? Is it faster to use __dpmi_int() > or to use int86()? Has anyone actually timed this, in the > past perhaps? I.e., how does the combined overhead of each > DJGPP call and DPMI portion compare for both? I didn't time this, but I don't think the differences matter much. Any way you do it, there's a need for two mode switches. A mode switch eats up thousands of CPU cycles, which is orders of magnitude more than any overhead incurred by an extra function call.