delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/08/21:31:39

From: Bill Currie <bcurrie AT tssc DOT co DOT nz>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Comparison: Serial Port Routines
Date: Fri, 09 Jan 1998 15:04:22 +1300
Organization: Telecommunication Systems Support Centre
Lines: 70
Message-ID: <34B585A6.475B@tssc.co.nz>
References: <Pine DOT SOL DOT 3 DOT 96L DOT 980108180450 DOT 18398A-100000 AT abc DOT ksu DOT ksu DOT edu>
NNTP-Posting-Host: node106.tssc.co.nz
Mime-Version: 1.0
CC: ayoung AT ksu DOT edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Adam Young wrote:
> 
> Hello All,
> 
> I have a question about the two serial routines written for DJGPP: BCSERIO
> and SVAsync.
> 
> BCSERIO uses assembly to do all of its handling of the FIFO and such,
> while SVASync uses mainly C to handle the serial port. What I am wanting
> to know is what is the difference between the two methods (ie advantages
> and disadvantages). I have always heard that assembly language is faster
> than C. Here is what confuses me: Isn't the C code converted to assembly
> language, therefore being just as fast as straight assembly?

There is nothing magical about assembly that makes it any faster than
C.  The difference comes from the `quality' of the assembly output by
the compiler.  Writing a program in assembly rather than C allows you to
take short cuts and make assumptions that the compiler can't.  eg, (for
interrupts), in assembly, you only have to save the registers you use
and you have direct controll over which registers are used so you can
minimize the number of registers that need saving.  A C interrupt
function (by default) has a lot of overhead.

This is why I wrote the iterrupt part of BCSERIO in assembly.  The
reason I wrote the rest in assebly (init etc) was partly for the fun of
it and it also made the entire thing self contained (it's unlikely you
will want to use only some parts of it).  This made things easier before
I figured out how to handle multiple ports, as it simplified building
DXE's that I could load (one for each port).

> This question came about from me trying to learn how interrupts are
> handled by C and assembly when dealing with the serial port. I do not know
> much about assembly language, but I do know alot more than I did a few
> days ago. I have checked out "djgppasm.doc" and Ralf Brown's interrupt
> list and other assembly sites the last few days. Which I guess leads me to
> one more (kind of related) question: Can DJGPP handle interrupts on a
> basic level like assembly can?

DJGPP is the entire package, including assembly, so your question is
sortof bogus (no offence). If you mean using C in DJGPP, yes, you can
write efficient interrupt routines in C, but they usually work better
with a little help from some assembly stubs (I've done this for my mouse
driver interface).  It really all depends on what you're trying to do. 
Use the right tool for the job.

> 
> Hopefully, someone can see where I am coming from. I am really not sure
> WHERE I am going with this, but it has me intrigued. Thanks in advance!

I'm not sure either, but I just had to answer this post :) (well, I DID
write bcserio).

BTW, there are some nasty bugs in bcserio. If you want an update, let me
know, I can post the most recent version too you.

Also, I don't think either package is realy any better than the other
(mind you, I haven't looked at SVAsync, but I've heard good things about
it), but I can vouch that my package has had some heavy use (mostly by
me) and is quite well tested.  I guess the biggest problem with bcserio
is it either needs you to keep the supplied .o file, or you have to
patch as.exe (this is due to a bug in gas that has been fixed after
binutils 2.8.1 was released). 

IMHO, the big advantage of bcserio is it supports unlimited serial
ports, even sharing interrupts (unfortunatly, the standard hardware
doesn't seem to :( ).

Bill
-- 
Leave others their otherness

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019