*BSD News Article 14285


Return to BSD News archive

Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: QIC NEWS; vol. 1, no. 3
Message-ID: <jmonroyC57Hu4.841@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.1 PL6]
References: <1993Mar23.175701.21077@olymp.informatik.uni-bonn.de>
Date: Fri, 9 Apr 1993 07:51:39 GMT
Lines: 48

mail juengst@saph2.physik.uni-bonn.de
Re: Subject: Re: QIC NEWS; vol. 1, no. 3
 
>> In article <1993Mar19.114125.9051@netcom.com>, jmonroy@netcom.com (Jesus Monroy Jr) writes:
>> [...]
>>
>> >         This code clip shows the right way and wrong way.
>> >
>> >                 ;; wrong way
>> >                 outw    dx, ax  ;; write a word (16-bits) to a port
>> >
>> >                 ;; right way
>> >                 outb    dx, al  ;; write the LSB (least significant byte)
>> >                 xchg    al,ah   ;; exchange high for low
>> >                 nop             ;; wait settle time (about 2 clock cycles)
>>
>> Are you sure your "right way" will work on the next generation of 80x86 ?
>>
        This is *not* the right way for any processor. It is the
        support cards with the inadequaces.  I cannot support the
        manufactures, in this regard, to any manner.
 
>> May be there will be CPUs with 200 MHz clock frequency (not a vision, it's
>> real, but not in the PC world, yet) and parallel processing available later.
>>
        Let's get this motion straight right now.  I do not
        intend to let hardware manufactures consribe our designs
        in the future.  They will design to what we need, not
        the other way around.
 
        Another false notion. "Software is always behind Hardware"
 
        WRONG, we know what we want to do. It is the hardware $#&^%#
        that are unrealized to their duties.
 
>> The past shows that every code with fixed encoded delays fails anywhere.
>> Of course that's not your failure, it's the stupid PC hardware design.  :-(
>>
>> But it's your problem ... :-)
>>
        My problem, yes. Alone No.
 
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________