Dear DDJ,
I get a big laugh every time the fuzzy-logic example of modeling the decisions a driver makes when reaching an intersection is used. (See "Programming Paradigms," November 1994.) I bet a clever programmer could code for that situation and get it right as often as a wetware driver, but for different reasons.
Now, a real test of fuzzy logic is the hungry-children-on-the-long-drive scenario! Anyone with little kids knows exactly what I am talking about.
Perhaps more seriously, new logical operators need to be created. Perhaps but and maybe would qualify. I have also thought that an event loop would better accommodate fuzzy logic in which sensory data and stimuli adjust variables that trigger actions only if they reach thresholds that would themselves be controlled by other functions and stimuli. This would accommodate a distraction effect that invariably screws up any algorithm, analytical or fuzzy.
Barr Bauer
Foster City, California
Dear DDJ,
I really enjoyed Jonathan Wilcox's article, "Object Databases" (DDJ, November 1994). He nicely lays out some of the complex design alternatives involved with object- database-method location and invocation. One small correction: We are in Pittsburgh, not Philadelphia.
John Nestor
Persistent Data Systems
75 West Chapel Ridge Road
Pittsburgh, PA 15238
info@persist.com
Dear DDJ,
Jim Gillig's article, "Endian-Neutral Software" (DDJ, October/November 1994) is an excellent presentation of Endian issues. Still, I think the article overlooked an important facet of the PowerPC handling of Little-endian data and instructions--address munging. When it is in Little-endian mode, the PowerPC processor performs an operation called "munging a transformation of the three low-order bits of the effective address of a CPU bus transaction. The three low-order bits are XORed with a value, depending on transfer size, to produce a munged effective address. 1-byte transfers are XORed with 111b. 2-byte transfers are XORed with 110b. 4-byte transfers are XORed with 100b. 8-byte transfers are not munged.
Only in Little-endian mode do the following restrictions apply to 60x PowerPC addressing:
The memory controller in a PowerPC system can be designed to work with the CPU to correctly address Little-endian data and instructions by implementing a byte swapper and an unmunge of the effective address from the CPU. The byte swapper swaps bytes within an 8-byte double-word, as in Table 2.
As Figure 1 shows, address 000b for a 2-byte transfer is munged to 110b, and data is input to the byte swapper at 110 and 111. The data emerges from 000 and 001 on the output side of the swapper with the bytes swapped.
The memory controller unmunges the munged address to convert 110 to 000 (XOR 110 with 110 to get 000), and the data is picked up on the correct byte lanes of the output side of the swapper with the byte order reversed. This same process applies to all the possible combinations of aligned memory accesses in Little-endian mode, and the process correctly converts Little-endian memory data and instructions to Big-endian internal CPU format, and vice versa.
The combination of the address munge in the CPU and the byte swap and address unmunge in the memory controller produces a perfectly transparent conversion of aligned Little-endian data in system memory to and from the CPU.
Section 2.4.3 of the PowerPC 601 RISC Microprocessor User's Manual describes the Endian processes in the PowerPC. Sections 2.4.4, 2.4.5, and 2.4.6 continue the discussion of Endian-related issues. Section 2.4.7 describes a method that can be used to orient Little-endian I/O data so that the CPU can correctly access Little-endian media without using a memory controller that incorporates the byte swapper/unmunge logic.
The method that the PowerPC microprocessors use to deal with Little-endian data and instructions is a very elegant solution to a complex problem.
Jeffery Ferris
Austin, Texas
Dear DDJ,
In "Undocumented Corner," (DDJ, August 1994), Troy Folger discussed the undocumented OS/2 function DosQProcStatus. From my investigations, it appears that DosQueryTmr does exist--under another name. In my explorations around the 165 Mbytes of totally undocumented CD-ROM that is my copy of C-Set++ (there really was documentation--the slip of paper in the CD cover), the third readme file (out of 62) mentioned something called EXTRA (or IXTRA if you want to go by the executable name). I found it not because it was documented, but because the installation program left a Device=DDE4XTRA.SYS command in my CONFIG.SYS file. It has taken me a month to work out how to use it, but now I have and it seems that during profiling, the timer ticks occur at approximately 800 nanosecond intervals, which is considerably more frequent than those offered by the ANSI-standard clock() function, which ticks about once a millisecond.
Peter Verstappen
Kaleen, Australia
Dear DDJ,
Here's a quick tip for a poor man's security system. It works great for those times when you want people to be able to use a machine (without the hassle of a password scheme or some sort of watchdog program) yet not be able to disturb a delicately tweaked CONFIG.SYS or AUTOEXEC.BAT file.
We all know the DOS ATTRIB command. We all know that files have the attributes: archive, hidden, system, directory, volume label, read-only, and so on. The attributes of a file are stored in an attribute byte which follows the filename (you can see this if you use a utility for editing a disk directly). If you manually (again using a disk-editing utility) set either bits 6 or 7 high, the ATTRIB command will not allow you to change any of the six documented attributes of that file. Use ATTRIB to make the file read-only and then set bit 7 (or 6) high. You can't delete the file because it's read-only. You can't make it read/writable because ATTRIB won't change any of the other attributes while bit 7 is high. Incidentally, I call the 2 high bits the "Big Dog" bits, part of the "Big Dog Security System"--K-9 Protection, you know.
Philip M. Sbrogna
Kittery, Maine
Dear DDJ,
As a one-time developer and maintainer of OEM spell-checking software, I have a short comment to make on using Bloom filters for spell checking as described in "Algorithm Alley," by William Stallings (DDJ, August 1994): Don't. From research we did and also by observing a certain product on the market that did use them, we discovered that they allow too many nonwords to pass. "Too many" means that the customers were very unhappy about it. In the final analysis, that's all that matters.
Bill Wells
Mt. Laurel, New Jersey
Dear DDJ,
In the July 1994 "Letters", William Hause writes about secure encryption by XORing a plain text message with an equally long (or longer) string of random bits. His letter was very interesting, and I agree that for a single message, the encryption is unbreakable. However, I believe that this approach suffers when the same encryption key is used more than once to send messages.
As an example, assume that Alice has sent two encrypted messages to Bob and both messages use the same encryption key K. Unknown to either party, a copy of the encrypted messages P' and Q' have been intercepted by a third party, Charlie. If Charlie knows that the algorithm used is the XOR algorithm, but does not know K, he can still attack the encryption with the following approach:
Charlie can then proceed to search for likely substrings in the encrypted messages by XORing them with each byte offset in (P xor Q). For example, by XORing the string "the" with bytes 1 through 3, 2 through 4, 3 through 5, _, n--2 through n, Charlie can look for plausible substrings emerging by similar cancellation. Charlie is starting to get windows into the contents of the messages; the encryption is falling apart already.
This weakness in the simple XOR encryption algorithm renders it impractical for most real-world secret communication because it requires a distinct encryption key for each secured message. No matter how many encryption keys Alice and Bob have agreed upon in advance, eventually Alice will have to generate new random strings and securely send them to Bob, if we assume that their communications are ongoing and sizable. It is not so much to the large size of the encryption keys that is objectionable; it is that this method assumes Alice can send Bob a megabyte of encryption key over a secure data channel for every megabyte of message she ever wants to send Bob over an insecure channel. If such a secure channel were available, no encryption procedure would be necessary at all. Instead, Alice could send Bob the plaintext messages over the secure channel with no need for worry.
Don Cross
Oviedo, Florida
Dear DDJ,
Have you had anything to do with either architects or carpenters? ("C Programming," DDJ, November 1994) We're redoing our house and have (among other things) a bathroom that's 5 cm lower on the sides than in the middle. A "wet cell" for the washing machine with no outlet, no hot water tap, no drain in the floor, and water-sensitive sheet rock on the walls (the architect has U.S. and German degrees). In addition, Xeno did this time plane. The job should have been finished in July. Maybe I just believed too much of what I read about German quality.
R.G. McKenzie
Schopfheim, Germany
Original Munged Address Address (a) 000 111 001 110 010 101 011 100 100 011 101 010 110 001 111 000 (b) 000 110 010 100 100 010 110 000 (c) 000 100 100 000
Input Output Address Address 000 --> 111 001 110 010 101 011 100 100 011 101 010 110 001 111 000
Figure 1 PowerPC address munging.
P'i xor Q'i
= (Pi xor Ki) xor (Qi xor Ki) {substitution}
= Pi xor Ki xor Qi xor Ki {associativity of XOR}
= Pi xor Qi xor Ki xor Ki {commutativity of XOR}
= (Pi xor Qi) xor (Ki xor Ki) {associativity}
= (Pi xor Qi) xor 0
= Pi xor Qi
Copyright © 1995, Dr. Dobb's Journal