*BSD News Article 15030


Return to BSD News archive

Xref: sserve comp.os.os2.programmer:11109 comp.os.coherent:9051 comp.os.linux:35727 comp.os.mach:2769 comp.os.minix:21926 comp.periphs:3529 comp.unix.bsd:11890 comp.unix.pc-clone.32bit:2470 comp.os.386bsd.development:540
Newsgroups: comp.os.os2.programmer,comp.os.coherent,comp.os.linux,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: QIC NEWS  Vol.1   no.5
Message-ID: <jmonroyC5zDwt.2HM@netcom.com>
Keywords: QIC FDC  
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Sat, 24 Apr 1993 09:19:41 GMT
Lines: 496

Released
        +----------------------------------------+
          QQQQQQ   II   CCCCCC
          QQ  QQ   II   CC        N  E  W  S
          QQ  QQ   II   CC        for 386bsd-Linux-Mach-OS/2
          QQ  QQ   II   CC        (and sometimes minix & coherent)
          QQQQQQ   II   CCCCCC    Vol.1   no.5
             QQ               (r)
        +----------------------------------------+
                News about QIC-40/80
 
   From the desk of the quasi-editor-in-chief:
        "Just because I am numbering these things don't get the idea
         that I am going to do any more of these".
 
        "QIC" is a registered trademark of the
        Quarter-Inch Cartridge Drive Standards, Inc. (QIC).
 
        UNIX is a trademark of USL, a division of Novell (last I heard).
 
        This publication is not affiliated with "QIC" or "QIC DATA NEWS".
 
        All comments, issues, and errors are only attributable
        to the quasi-editor-in-chief.
 
   Thanks:
        Will Crawford, Wolfhound Computer Service for the editorial critique
        and his comments on software design.
 
 
        Jennifer Gordon for making this publication what I can only
        attempt in a rogue manner.
 
 
        *=======================================*
        |       Tabloid Contents                |
        *=======================================*
        |  <1>__ Things to Come.                |
        |  <2>__ What is Really Coming          |
        |  <3>__ Advance Proposal               |
        |  <4>__ More Advanced Ideas.           |
        |  <5>__ *(variabl[]->obfuscated())     |
        |  <M>__ Meaningless Dribble.           |
        |  <F>__ FLAMES to the editor           |
        |  <N>__ NEXT ISSUE                     |
        *=======================================*
        hint: search for "<?>__"
 
 
  <1>__ Things to Come.
 
                With all the crying, whining and rambeling I have
        been doing on the comp.os.386bsd.* groups, you would think
        I might continue on a different trek.  I almost did, and
        I may.
 
                Yet another idea needs to unfold, but I can't
        decide on a name.
 
                        Here are some ideas:
 
                 ("PRELIMINARY COMPOSITE DESIGNS".)
                     (DESIGN, DESIGN, DESIGN.)
                 (DO WE REALLY NEED ALL THIS TALK?)
                    (IS THIS THE TWO-WAY STREET?)
                     (SOCKS OR PANTS FIRST???)
 
        I see much too much unsavory code. It comes from all parts of
        the world, including institutions such as; MIT, Berkeley,
        USC, Carnagie-Mellon, Brown, Maryland, etc...
 
                It is mind-staggering that a few simple no-nonsense
        ideas cannot be initiated. Comments, no-hard coding, and
        documentation should be simple and no-nonsense.   I just
        reviewed what was said to be good code, BUT from whose
        viewpoint?   None of the modules I looked at even dared to
        describe their function in life.  The so-called comments
        were present only at the beginnings of functions, MAYBE.
        The documentation was scrawl that ran from the left to
        right margin with only an occasional blank line to indicate
        a paragraph.
 
                We can be glad, at least, that the example
        mentioned had some documentation. Many times, with what is
        considered dossier, I would be fortunate to fill a screen.
 
                OK, OK, OK, I will stop reventing now, but this topic
        certainly needs more attention.
 
                AND NOW... the real stuff!!!!!!!
 
 
 
  <2>__ What is Really Coming.
 
                        THE BRAVE NEW EXPERIMENT.
                        -------------------------
                In the past, we have seen many experiments of this
        sort, all with mixed results.  Today, we will DO what is only
        possible by text book example.  We will DO and go beyond.
        This  massive, frustrating, despicable, unbearable, infuriating
        annoyance, known as the QIC-40/80 project, will, by hope,
        show that cooperation is possible, and transportability should
        NOT be an issue.
 
                One common ground holds us together; that is the
        now-retired IBM-PC, that 8088-design meant to sell as an
        electronic toy for the common man.   We are bound by its
        diversion, well established by the capitalistic,
        commercialistic part that makes America.
 
                There are still problems that have to be resolved.
        This leaves our publication as the sworn medium for the
        project. Of course, the nay sayers want us out and away
        from them, but we have the duty to respond.
 
 
  <3>__ Advance Proposal.
 
                Coordination between all groups on shared libraries
        is the first of the proposals suggested.  This extends not
        only to 386bsd, Linux & MACH386, but also Coherent, Minix
        & OS/2.
 
                The corporate entities involved are attempting to
        hold hostage the QIC-40/80 standard.  They want it to be
        proprietary.  In some regard, I do not blame them; I guess
        if the company were mine, I might do the same.
 
                Next, the headers (.h) could be common for all to use as
        a reference.   You may then write to the appropriate group leader
        and have that person forward ideas or flames on this. The comments
        will be published in QIC NEWS, so that an agreement can be made as
        to the issues at hand.
 
                I expect code writing and development to proceed expediently,
        so I will be posting QIC NEWS with "hits and misses" on a weekly
        basis ("hits and misses" = your trials and tributes).
 
                Another good possible point to share is a fdc_base_code
        set.   As you may or may not be aware, the QIC uses the FDC
        (Floppy Disk Controller), so it would be advantageous as a set.
        Of course, we know about objects and know that they are
        nice.  Plans should be made for objects as well as in-line
        assembly, and any other appropriate software devices that qualify.
 
                In regards to the FDC code, my FDC driver is in beta(s)
        now, but it will be released publicly when Julian Elischer - my beta
        coordinator for the FDC - decides that it is ready.  BTW, the old 386bsd
        driver, seems to be incorrectly modeled, as does the MACH version.
 
                A high point would be an API (Applications Programmers
        Interface) as well as a Windows (OS/2 & X-windows) hook.
        An API could facilitate high level writers, data bases, other languages,
        & WAN-type applications (like DCE).  The Windows hook could work
        so that the Icon can look and behave like the device is acting,
        in real time! (Owwh, Do you mean like Macplaymate?!?)
 
 
        HERE are some possible specifications to work with:
 
        platform:    AT/ISA/EISA  (MCA for OS/2 that need it)
        OS:          386bsd, Linux, Mach386, OS/2 (for the immediate)
        Language(s): C, C++, ASM (gas,masm)
 
        Files Break Up:
 
                fdc.h           - only pertains to the FDC's
                fd_386bsd.h     - global items
                fd_Linux.h      -  "       "
                fd_mach.h       -  "       "
                fd_OS2.h        -  "       "
                fd_common.h     - global items common to all OSes
                fd_api.h        - header for the API
                fd_rwin.h       - header for REAL windowing API
 
                qic.h           - only pertains to the FDC's
                qic_386bsd.h    - global items
                qic_Linux.h     -  "       "
                qic_mach.h      -  "       "
                qic_OS2.h       -  "       "
                qic_common.h    - global items common to all OSes
                qic_api.h       - header for the API
                qic_rwin        - header for REAL windowing API
 
 
 
                I will tender other suggestions for your approval
        (Or if you know of anything firm and tender--let me know.).
        In cases of extreme discourse, each side to a neutral corner,
        please, then come out swinging.  Those of you interested in
        joining in the recreation, contact the people local to you.
        The list is below.
 
 
        386BSD-QIC40-codewriters
        -----------------------
        galbrait@rintintin.Colorado.EDU         GALBRAITH JOHN
        fty@bizarre.rtpnc.epa.gov               Frank Terhaar-Yonkers
        cjb@cs.uq.oz.au                         Christopher J Biggs
 
        QIC-40-other_OS
        -----------------
        dbrown@ucsd.edu                         Dave Brown - Mach386
        (dbrown may be busy)
        khk@raster.Kodak.COM                    Karl Heinz - LINUX
        (Khk is on vacation, till 5-3)
        hoppie@kub.nl                           Jeroen Hoppenbrouwers - OS/2
 
 
  <4>__ More Advanced Ideas.
 
        Zero or Minimum Flags and/or Switches.
        --------------------------------------
                This idea was passed along to me from a friend,
        Will Crawford, long after I had forgotten it. 
 
                Addition has shown to be the faster ally, at least by our
        methods.  Its use results in code that is concise and efficient.
        Through this perception, we can discern that an i++ if far better
        than possibly a "if (i)".  That is to say, an incremental function
        serves us better than a branch or a jump.  It reduces the memory
        space taken that is needed in setting up and implementing the
        jump and it increases speed by removing the likelihood of
        taking the jump.  If a jump had to happen, because of the "if",
        then the prefetch mechanism would have had to be cleared and would
        have caused a load on cpu decode logic.  You might say, "Well, I don't
        write that many `ifs'".  Yes, but 1000 "if" logic run with
        the 1000 "i++" logic just seems cleaner.
 
                After all that, you may consider logical booleans,
        like XOR (exclusive or), or perhaps a logical AND.  They are
        equivalent in the mathematical sense to "i++", but in a
        programming context, it may involve a branch/jump after
        investigating some flags.
 
                But is time really the issue?
 
                I think not. What we intend is to write programs
        that work well and produce a minimal amount of side effects.
        After all, the space/speed wars are over!!!  You might think
        that writing a program should not have side effects, but in the
        "art world of computing", errors are considered the norm, something
        to be expected.   (For more on error theory, ask me for my articles
        on this.)
 
                OK, if you considered my statements valid, let's
        continue:
 
 
                1.  In programming, flags and switches work in
                    coordination many times, and in substitutions
                    with extreme care!
 
                2.  So, what is a flag?
 
                    An object placed so as to give notice or warning.
 
 
                3.  What is a switch?
 
                    A change or exchange of positions, methods or policies.
 
 
                4.  These can also be referred to as symbols.
                    Which is something that we won't go into.
 
 
                Let's give a pointed example:
 
                IE.,
 
                if (Tom() == boy)
                        goto Sue();   /* Avoid goto's */
                                        /* BTW, a "goto" is also an
                                           "unconditional jump to" */
 
 
                This statement considers none of the other extreme
        possibilities.   Is Tom old enough?  Is Sue old enough?
        Is Tom homosexual?  Are they attracted to each other?  Is Sue a girl?
        Is his name Sue? Will he sue if she doesn't?
        Complexities can continue, let's not.
 
                But without flags and/or switches, how do we program?
        We don't program; we flow the logic to its considerations,
        and let these considerations derive the necessary boundaries.
 
                "Garbage in, Garbage out", is terse, plain and simple.
 
 
                Yet another example is the IRS (Internal Revenue Service).
        How do they process their data, sequentially or randomly?
 
                The answer is sequentially. The 1040 form you filled
        out last week is read by a digital scanner.  The data is
        then translated from the boxes they were in, to sequential arrays
        that are stored for later processing.  At a future date, the
        arrays are collated. They are then compared to your returns
        for the last 7 years.  If the expert system and the (so-called)
        random-izer do not object, you get a refund, provided you have
        one coming.  Fortunately for us, they don't pay programmers enough
        to gather the competence to be cost-effective.
 
                Maybe two or more processes could limit you now from
        possibly receiving a return. (That last sentence almost sounds
        like something a programmer might say.)  We are now aware of
        two processes by our statement: the expert system, and the random-izer.
 
                An expert system seems to imply a series of
        if-else rules; not so.  An expert may apply if-else rules to
        the process, but in the end the decision will be "gut" - almost
        a fuzzy approach, by nature.   SO, DO WE contend with the if-else
        rules or don't we?  I did say "fuzzy", didn't I?  This is not
        "fuzzy-logic" though, "fuzzy-logic" is determined by a statistical
        method, almost in he same sense as neural networks, but not so.
 
                Confused? Reread and stop on the first "fuzzy".
                          (Do a loop and increment by 1, beep.)
 
                In trying to get a "gut" reaction, we eliminate all
        logic and let human nature take its course. More often than
        not, it will help determine the best highway.
 
                This is getting purely philosophical, I see.
 
                I will illustrate more constructs in the future by
        writing a separate article.
 
                The remaining process in contention is the random-izer.
        It cannot produce any flags and/or switches.  By definition, a
        random-izer has no second state; it can only produce one number,
        which is random.  But can a number be truly random?  That,
        however, is another discussion, and is not meant for this example.
 
 
        ******]]]]]> end discussion <[[[[[[****
 
  <5>__ *(variabl[]->obfuscated())
 
        (If I got this wrong, will some kind soul please flog me in public.)
 
                It is an indexed array with a pointer to a function
        that returns a pointer.  Beep.
 
        *(*variabl->obfuscated())
 
                This can be consider the same thing, but with a pointer
        array instead of an indexed array.
 
 
 
  <M>__ Meaningless dribble.
 
        "Against every great and noble endeavor stand a million mediocre
         minds."
 
                                -Albert Einstein
                                -while young and morose
 
 
        From the section on "Parasite Drag of Some Common Bodies":
 
        "Parasite drag is composed of form drag, arising from an
         integration of pressure-force components, and skin friction
         arising from an integration of viscous shearing-force
         components."
 
                                -Principles of Aerodynamics; 1st ed.,
                                 chapter 11, pg. 242,
                                -James H. Dwinnell
 
 
        "In addition, the significand of a pseudo-denormal is normalized;
         that is, the MSB (Most Significant Bit) is a 1.  Therefore, all
         pseudo-denormals can be represented as normals."
 
                                -Programming the 80386; pg.27
                                -John H. Crawford & Patrick P. Gelsinger
 
 
 
        "Parallelism is the norm, purely sequential problem
         solving is the anomalous restriction."
 
                                -Nicholas Carriero & David Gelernter
                                -How to write parallel programs; p.1
 
 
        "High heels are illegal to wear in Mobile, Alabama"
 
                                -SF Chronicle; grab bag
 
 
 
  <F>__ FLAMES to the editor
        ====================================================
        mail cbq@cfm.brown.edu
        re: Subject: HANG THE ENGINEER -- tort of consequence
 
        >> So you're not answering your email...well hope
        >> springs eternal.
        >>
        >> I have just one question:  is your unique writing
        >> style merely the result of a bizarre personality,
        >> or the result of excessive drug taking as a youth?
        >> Inquiring minds want to know!
 
        ====================================================
        VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
 
 
        The question to your answer has a question.
 
                                Thanks for your comments
                                        jmonroy@netcom.com
        ====================================================
        mail ima@wam.umd.edu
        Re: Subject: Re: HANG THE ENGINEER -- tort of consequence
 
        >> i also am an engineer, an ee from the university
        >> of maryland.  your post regarding "hang the engineer"
        >> is fine as far as it goes. the bridge that falls should
        >> take the designer, and those that apporved the design
        >> with it.
        >>
        >> this does not excuse being unable to express oneself
        >> in a written language.
        >>
        >> i have read each of your postings.  most of the time,
        >> i can not understand what you say, or discern what you
        >> mean to communicate to the rest of the 386bsd community.
        >>
        >> spelling misteaks are commonplace with all of us, no
        >> reason to gripe about them, unless the spelling completely
        >> obscures the words.
        >>
        >> your posts should have enough structure that i can follow
        >> your train of thought.
        >>
        >> please read your postings before sending them.  a few
        >> edits may enable the rest of us ( me alone? ) to
        >> understand you that a meaningful dialog may take place.
        >>
        ====================================================
        VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
 
        QIC NEWS will now be posted only once every two or
        three for writing review of it's understandablity.
 
                                Thanks for your comments
                                        jmonroy@netcom.com
        ====================================================
        mail cproto@cs.curtin.edu.au (Computer Protocol)
        Re: Subject: Re: HANG THE ENGINEER -- tort of consequence
 
        In comp.os.386bsd.development you write:
 
        >DID this not get posted... the first time....?
        >=========================================================
 
        >        Today is St. Patrick's day. Happy Anniversary 386bsd.
        >
        >                        HANG THE ENGINEER
        >                        -----------------
        >       :: [deleted ::
        >
 
        Piss off !!
 
 
        ====================================================
        VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
 
 
        Wow, a response from "Computer Protocol".
        I am always amazed at the extent of the responses to
        my articles.
 
                                Thanks for your comments
                                        jmonroy@netcom.com
 
        ====================================================
 
  <N>__ NEXT ISSUE
 
        o....   Will we ever see some code from
                the editor for the tape drive?
        o....   What everyone is doing!
        o....   Standards, Standards, Defacto.
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________