Our Inbox (formerly 'Letters') has always been an interesting compilation of queries, comments, compliments, and complaints.
March 82
was no different:
Letters
Apple's Decision Questioned
We use Apple computers for commercial machine-language program development and buy Apple IIs at frequent intervals, either as a service to our customers or in order to expand our office.
I have recently spoken to a mail-ord
er distributor of Apples who told me that as of December 4, 1981, Apple was no longer wholesaling to mail-order houses. I could not believe this, so I called CALL-A.P.P.L.E. It's true, I was told.
I am outraged. How can Apple, with new, large, clever, powerful competitors just beginning to breathe down its neck, remove the only way for small, intelligent users to buy Apples inexpensively?
Apple is, in effect, forcing us to buy from retail stores, which are usually overpriced. Their personnel are insulting in their inexperience and knowledgeable only about the latest space games. We can not afford their arbitrary $700 markup on the Apple II. Our software systems, while cost-effective with mail-order firms' prices, are not with the retail stores' prices.
Apple will have to decide just who its friends are -- the retailer who sits on his duff selling other people's ideas or the software innovator who takes a piece of hardware and makes it usable by the masses. While Apple may be trying to help o
ut its dealers, it seems to have decided to do this at the expense of its serious customers -- the people on whose success its own utlimate success depends.
Apple has succeeded so far because it provides a product which we (and others) can program without too much trouble and which our customers can afford. This new attitude of demanding that we submit to retailers' ridiculous prices will compel many to reconsider which personal computer we will use to develop our systems. I hope Apple discovers its error before its competitors profit too much from it.
Dennis Gerald Pratt
666 North Dearborn, Apt 3F
Chicago, IL 60610
Yes, it is true. Apple Computer Inc. has given its dealers an ultimatum: either cease all mail and phone order sales, or your authorized dealership will be terminated effective December 4, 1981. This was delivered in a "Notice of Dealer Agreement Modification" dated November 2, 1981, and dealers had until November 20, 1981, to sign and re
turn the "modification." Otherwise, Apple threatened to pull the plug, so to speak.
Apple is attempting to justify this move by stating: "We believe that our ability to maintain a leadership position in competition with the corporate giants now entering the personal computer field depends in large measure on the willingness of our dealers to satisfy the end user with their familiarity with Apple products and their commitment to passing on this knowledge and support." Accordingly, Apple has added subparagraph 3(g)(iv) to its Authorized Dealer Sales Agreement:
"Dealer and Apple recognize that because of the special, technical nature of Apple Products, customers purchasing them can be properly served only if they have the benefit of pre- and post-sale education, orientation and support, specifically including in-person contact with the selling dealer, in order that each customer's needs may be properly served and the features, benefits, operation and applications of the Apple Products
being purchased may be demonstrated and fully explained by knowledgeable sales personnel." It then goes on to specifically prohibit mail and telephone order sales of Apple products under penalty of losing the dealership.
Apple concluded its modification notice with the following paragraph:
"Apple personal computer products demand innovative and creative marketing. We are willing to work with all who are willing to meet that challenge. Those who are unwilling to expend the effort have no place in our future plans." ... MH
Is Microfiche the Answer?
This letter is in response to the letter of Lew Merrick (October 1981 BYTE, page 10) regarding the storage bulk of advertising material in BYTE back issues.
The separation of advertising material into a separate removable section is undesirable because it would reduce the exposure of the advertising, reduce the value of the advertising, and ultimately degrade the quality of BYTE by reducing reve
nues.
An alternative is to convert to microfiche files at some loss of convenience but great savings in space. BYTE is now available from University Microfilms, Ann Arbor, Michigan, but you must be very patient with them because (1) back issues are available only in one-year blocks, (2) back issues are not produced until well into the following year, and (3) orders are not filled promptly.
My suggestion is that BYTE offer a microfiche subscription option, just as is now done with the IEEE journals. The microfiche might actually be cheaper to produce and ship than the paper edition.
A microfiche viewer can be used for many purposes and occupies about as much space as three years of BYTE. The space needed to store the fiche is negligible.
Back issues of BYTE are well worth preserving, as they enable me, after a session on my modest micro, to ponder what little was available only five years ago and to speculate what the future holds. The advertisements in a five-year-old BYTE issue contai
n some very interesting material.
Richard Schwartz
Electrical Engineer
Star Fleet Engineering
1328 North Santa Anita Ave
Arcadia, CA 91006
More on the WAI
Regarding Dr. S. S. Reddi's "Where Am I?" instruction (Technical Forum, November 1981 BYTE, page 413), I would like to point out that Motorola's 6809 has such an instruction. The simplest form is:
TFR PC,X
The instruction transfers the value in PC (program counter) to register X. (The value transferred is the location of the next instruction.) The 6809 also allows:
LEAX n,PC
which adds "n" (8 or 16 bits) to PC and puts the result in register X. (LEA = Load Effective Address) This instruction, which may also be written:
LEAX label,PCR
can compute the address of any label (location) within the program without using an absolute address (PCR means use PC-relative addressing). In these examples, the des
tination register could be Y, U, or S, instead of X, if desired. The destination for the TFR instruction could also be register D, which is accumulators A and B treated as one 16-bit register.
I question the usefulness of a WAI (Where Am I) instruction by itself, however. Apparently, Dr. Reddi would like to get the value of the 6502's program counter and then use this value to set up a table of addresses in page zero of memory, to be used with page zero indirect addressing (or, I shudder, to modify addresses within his program, such as jump and subroutine addresses). Adding a WAI instruction to the 6502 would help, slightly, with this rather clumsy method of making programs relocatable.
Much more is needed to make programs easily relocatable. The ideal situation would be to have code that runs at any address with no changes required. This is called position-independent code. The 6809 has the necessary instructions for such code. In addition to the LEAX (and LEAY, etc.) mentioned above, its instruc
tion set includes branches (jumps), both conditional and unconditional, and subroutine calls with relative addressing. The relative address can be either 8 or 16 bits long, the latter allowing relative addressing anywhere within the 6809's address space. (Subroutine calls and unconditional jumps are also available with absolute addressing.) The presence of these instructions allows writing programs that can be run at any address with no changes (and with no need to set up a table of addresses or to modify the code at run time).
The WAI instruction by itself solves only a small part of the problem of being able to have position-independent code, code that will run unchanged at any address. Perhaps this is one reason it is not present in most computers. Most (or all) computers that have a WAI instruction, such as the 6809, PDP-11, 68000, and IBM 370, are also capable of position-independent code. I suspect that the 8086, Z-8000, and VAX 11/780 are also in this category.
Another reason for the absenc
e of WAI in most microcomputers is that most 8-bit microprocessors were intended for use in dedicated controllers where there is no need for position independence or a WAI instruction.
One may note that the 6800 has a WAI instruction, namely:
BSR NEXT
NEXT EQU $
This use of BSR (branch to subroutine), which uses relative addressing, pushes the address of the next instruction onto the stack, where it can be easily retrieved. (This is not to be confused with the 6800 instruction whose mnemonic is WAI. This WAI means "wait for interrupt.")
Jim Howell
5472 Playa Del Rey
San Jose, CA 95123
The "Where Am I?" instruction is indeed useful. That is probably why it was included in the design of the Motorola 6809 as the Load Effective Address, or LEA, instruction, and its use is not restricted to finding the current PC contents.
The LEA instruction loads the effective address of its operand into the specified 16-bit register
, which may be either stack, either index, or the double accumulator. The operand must use the indexed addressing mode, which includes PC-relative. "Where am I?" could be coded:
HERE LEAX HERE,PCR
Assuming that you want HERE to be in the X register.
Other uses for the LEA instruction are addressing position-independent tables and adding constants to the indexable registers.
I recently read an article comparing the 6502 and the 6809 in which the author complained that he wasn't able to find much use for the LEA instruction. This caused some amusement among my friends. A close examination of some of my own code reveals that the LEA instruction is one of the most heavily used. I would venture the opinion that position-independent code would be much more difficult to write without it.
Howard Lee Harkness
Word's Worth
POB 28954
Dallas, TX 75228
Architecture Controversy
It was nice to see your a
rticle on higher-level machine-language constructs, "Should the DO Loop Become an Assembly-Language Construct?" by Glenn L. Williams (October 1981 BYTE, page 413). I would like to add a couple of comments to Mr. Williams's remarks.
Since Mr. Williams was including minicomputers in his article (he references the PDP-11 and VAX 11/780) he might also have included a reference to the HP3OOO instructions MTBA, MTBX, TBA, and TBX. These four instructions each perform a variation of Mr. Williams's NXT function. All the instructions use a loop variable, a limit value, and a step value. TBA and MTBA use a variable address on the stack while TBX and MTBX use the index register for the loop variable. In all cases, the limit and step values are on the stack. MTBA and MTBX modify the variable by the step value, which may be any integer, positive or negative, and compare the result to the limit value. Positive step values cause a check to see if the limit has been exceeded, and negative step values cause the check to
see if the result is less than the limit. TBA and TBX do not modify the variable but check only for the limit being exceeded. These allow compilers to implement more complex counting-loop structures than can be accomplished by adding or subtracting a step size. Also, functions similar to Mr. Williams's SRCH function are performed by SCU (SCan Until memory byte matches test byte or terminal byte) and SCW (SCan While memory byte matches test byte or until terminal byte is found) on character strings.
With the growing acceptance of modular, structured programming it has long been my feeling that high-level constructs should be imposed at the machine-instruction level. The only real need for assembly language these days is to utilize the machine architecture not available at the high-level-language level to produce quick, short code. Implementing high-level functions in machine language and providing optimizing compilers should just about eliminate any need for assembly language. Code produced would be ver
y short and quick, because a single complex machine instruction should run faster than the many simpler instructions put together needed to accomplish the same function. I would like to see both micro- and minicomputer processors developed with instructions to implement WHILE, IF...THEN...ELSE, CASE, DO...UNTIL, and other high-level constructs at the machine-instruction level.
Let's all keep pushing for advances in architecture to keep up with advances in software. And thanks, BYTE, for being among the leaders in this respect.
David B. Mears
757 Cornell Dr.
Santa Clara, CA 95051
Glenn Williams is undoubtedly correct when he says that the instruction sets of microprocessors can be improved. For various reasons, however, I do not agree with his specific proposals.
It will always be necessary to write programs in assembly language, but if the "software crisis" can be solved at all it will only be by the efficient implementation of high-level language
s. Processor designers have clearly realized this, but unfortunately their attempts at providing "features" that are supposed to help the compiler writer are often misguided. Consider, for example, two of the features mentioned by Mr. Williams: stack and condition registers.
x There are two principal reasons for using stacks in the implementation of a high-level language. One is to save and restore environments when procedures are called, and the other is to provide fast temporary storage during expression evaluation. Typical PUSH and POP instructions do not help in either case: to save and restore an environment we need an appropriate addressing mechanism, and expressions can be evaluated faster using registers than stacks in memory.
If we were interested only in simple test-and-jump coding, condition registers would be fine, but in high-level language programming this is not always the case. The Pascal statements
finished : = eof OR (lines > maximum)
and
total: = total + width * length
have the same structure. On a processor with condition registers, however, the first is coded by means of an elaborate sequence of jumps, while the second is a simple sequence of arithmetic operations. There is no reason why tests should not leave their results in ordinary registers, like other instructions.
The DO statement that Mr. Williams proposes would not be used by any but the most sophisticated optimizing compiler. First, it is inappropriate for loops in which a termination test is made on entry to, rather than on exit from, the loop body. This is not required for FORTRAN, but it is for Pascal. Second, the DO stack must be adjusted if an exit occurs before the loop is completed, and that is often, whatever the structured-programming zealots say. Third, a special addressing mode is required so that the code within the loop can access the DO index, because the DO index lives in the DO stack.
The real requirements have been accurately summarized by
Professor William Wulf ("Compilers and Computer Architecture,"
Computer
, July 1981): the compiler writer wants well-designed primitive instructions, not solutions to problems. A small set of efficient, useful instructions is better than a vast number of "clever" instructions that do the right thing in special circumstances but require elaborate analysis in the general case.
Peter Grogono
Metonomy Productions
4125 Beaconsfield Ave.
Montreal, Quebec
H4A 2H4 Canada
SRS1A vs. HP-41C Calculations Continued
I thank Mr. Kitchen (Letters, October 1981 BYTE, page 20) for another opportunity to discuss accuracy in HewlettPackard calculators. I fear he missed the point; please note my earlier statement regarding predicability (Letters, April 1981 BYTE, page 16). Then try this with an SR51A or a similar calculator:
1.Take the square root of 2. On both your SR51A calculator and my HP-41C, the display shows 1.414213562. Squa
re this result. You get 2; I get 1.999999999. Subtract 2. Neither machine yields zero, but yours looks like it will, unless you "chisel out" the hidden digits first.
2.Enter 1.414213562 through the keyboard, then square it. If your display reads 2, feel free to be outraged: your machine does funny arithmetic. Indeed, the SR51A does not yield 2 as a result, but, considering what happened in (1), it looks like it will. How much work are you willing to do to discover how your calculator is going to behave? If it is really a 13-digit machine, why must you trick it to reap the benefits?
I could go on. At great length. And not just about SR5ls and square roots.
In some cases, the SR51A yields better results than an HP-41C.
But which cases?
In chain calculations, digits 11, 12, and 13 can become numerical noise that creeps into the visible mantissa, causing mysterious results whose origins are very hard to isolate.
Hewlett-Packard calculators exhibit more deterministric behavior. Acc
urate internal software that discards guard digits is one reason. When unavoidable numerical errors occur, they are predictable, repeatable, and immediately apparent.
Serious numerical analysis demands this
; braggadocio does not.
Once again: a calculator is a tool, an extension of the mind. It must be
understandable
and
understood
by the user. Consider what can happen if this is not the case for a variety of tools you may use (e.g., power saws, guns, automobiles). Then consider who uses calculators seriously: scientists, engineers, bankers, and doctors.
The designers at Hewlett-Packard keep such things firmly in mind.
Steve Abell
Research & Development Engineer
Hewlett-Packard Company
Corvallis Division
1000 NE Circle Blvd.
Corvallis, OR 97330
The Big Spelling Sweepstakes
The spelling-correction software review by Phil Lemmons ("Five Spelling-Correction Programs for CP/M-Based Sys
tems," November 1981 BYTE, page 434) gives me new faith in the free-enterprise economic system of business. He has correctly pointed to the best value in a computer dictionary program: The Word from Oasis Systems.
When this program was released I compared it to the "high-priced spreads" and came to the conclusion that a big-budget ad campaign would always get results for the less-valued product. The way that various magazine editors and writers were talking up certain overpriced spellers I thought that the big dollars would win over the underfinanced little organizations. I concluded I was wrong after reading your comprehensive review.
I'm sure there's a lot of egg on many a face this day -- and rightly so. There are always some individuals willing to lend their names to products they don't fully understand. Furthermore, they let their names to used without understanding the competitive positions they are taking. That seems to be a characteristic of our culture -- if action is required, act even i
f you don't have the facts.
The time is rapidly approaching when the fast-buck artist can no longer get away with his "get-rich-quick" schemes, thanks in no small part to magazines like yours.
Frank Joseph
10925 Stonebrook Dr.
Los Altos Hills, CA 94022
We wish to inform BYTE and its readers that there is a sixth spelling-correction program on the market that, according to Mr. Lemmons's benchmarks, outperforms the others. This program is called the Disc-tionary.
We ran the Disc-tionary on Mr. Lemmons's 400-word benchmark text and it found all seven misspellings, yet failed to recognize only eight additional correctly spelled words. The total time to proofread and mark the file was only 47 seconds on a typical computer when the word review feature was skipped (1:12 with word review). A 3100-word file can be proofread in 1:12 without review. While it is impossible to make direct timing comparisons due to the use of two different computers, the Disc-t
ionary obviously combines a high level of accuracy with a large vocabulary. This gives the user a higher level of safety and convenience than the other programs.
We believe that the Disc-tionary presently provides the best combination of speed and accuracy. It is also very easy to use because of its menu-driven operation.
The Disc-tionary requires a Z80 and is available on an 8-inch CP/M disk for $79. This price includes a 54-page user's manual (available separately for $15) and two free "bug fix" updates.
David G. Hicks, Vice-President
Stellarsoft Corporation
841 Blanchette Dr.
East Lansing, MI 48823
Editor's Note: This program has not been tested by Mr. Lemmons. The times above have been provided by the manufacturer, and we cannot vouch for their accuracy.
An Avalanche of Answers
I have received some pretty strange and fascinating responses to a question I put to Steve Ciarcia that was printed in "Ask B
YTE" (July 1981 BYTE, page 218).
Apparently, Steve didn't provide what the readers thought was the best answer and they quickly let us both know. The day I got my magazine I also got a longdistance call asking if I was Dave Bower and if I owned a TRS-80 and if I had written to BYTE magazine. The caller then answered my question. The next day I got a letter answering the question. There's nothing strange about getting a letter, except that you didn't print my address, and neither did the person sending the letter! And it continued like that for the next couple of months -- letters and phone calls from all over the United States. And just when I thought it was over I got a package from Steve Ciarcia containing the letters he had received!
So, needless to say, I got my question answered. And I got a lot more too. I think every person that contacted me also shared more hints and/or information or whatever. So even though they all called or wrote me about the same thing, not one exchange was a waste of
time.
I just wanted to let you know what kind of readers you have and that I think Steve has a pretty good column, and a well-read one too.
Dave Bower
741 Lake Edward Dr., Apt. 104
Virginia Beach, VA 23462
Closing the Net
Harry Saal's article on local networks ("Local-Area Networks, Possibilities for Personal Computers," October 1981 BYTE, page 92) did injustice to your readers with its narrow scope and omissions. Specifically:
1. Datapoint's local coaxial networkbased ARC system was introduced and installed in 1977.
2. About 2000 ARCs are installed and in commerical service worldwide -- more than all other networks, prototype or otherwise, combined. (I have heard no argument to estimates that Datapoint has a 95 percent market share of installed local networks.)
3. Tandy uses the local network portion of ARC, ARCNET, for its TRS-80 Model II personal computer network, announced in September -- a step of major si
gnificance.
4. Three companies now use ARCNET -- Datapoint, Inforex, and Tandy.
5. The only deliverable chip-based local network interface is manufactured by Datapoint.
Considering these omissions, I'm skeptical that the article was well researched.
Gerard Cullen
Vice-President Marketing
International Operations
Datapoint Corporation
9725 Datapoint Dr.
San Antonio, TX 78284
Harry J. Saal replies:
My article was not intended as a complete survey of local-area network products. Datapoint's offerings in the high-speed, serial, coax network were indeed quite early; it is unfortunate that Datapoint has not provided any in-depth technical information in the published literature by which its system can be evaluated for comparative study. In September 1981, several months after my article was completed, Datapoint announced its relationship with Tandy, a very exciting recent development.
Let me assure Mr. Cullen that there are substantially more than 100 installed, non-ARC local networks worldwide; hence the 95 percent market share claim is false.
photo_link (110 Kbytes)
15 Years Ago in BYTE
