Return to BSD News archive
Xref: sserve comp.os.386bsd.announce:39 comp.os.386bsd.misc:237
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!howland.reston.ans.net!agate!bounce-me
From: jmonroy@netcom.com (Jesus Monroy Jr)
Newsgroups: comp.os.386bsd.announce,comp.os.386bsd.misc
Subject: QIC NEWS Vol.1 no.5
Followup-To: comp.os.386bsd.misc
Date: 25 Apr 1993 16:20:36 -0700
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Lines: 500
Sender: cgd@agate.berkeley.edu
Approved: 386bsd-announce-request@agate.berkeley.edu
Message-ID: <jmonroyC5zE4L.2Ms@netcom.com>
NNTP-Posting-Host: agate.berkeley.edu
Keywords: QIC FDC
[ this is the last one of these i'm ever going to post to .announce... - cgd ]
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
___________________________________________________________________________