Issue # 12 DTACK GROUNDED Newsletter - August 1982
Last month we introduced you to a threaded 'programmable calculator-like' language. This language exists and it runs. Two of our older demonstrator programs use it. You may not believe this, but the heart of that language was written one Sunday afternoon in 20 minutes. We have a witness. It ran perfectly the very first time, with no bugs (it is VERY simple). Those of you who took the time to examine the source code on page 15 will recognize that there is VERY little 'interpretive' overhead. You will also recognize, then, that user definable extensions to that language can be easily added by assembly language programmers (providing the source is available on disk). As you can see by the program listing on page 16 of last issue, the program can be easily read and does NOT require one to do everything backwards.
Now, let us look at that again: we have a language (as yet quite primitive) which has vanishingly small overhead, is simple and bug-free, is user-extensible and supports documentation. One does not need a backwards 'set of mind'.
You know what? We think we have got hold of a good thing.
WHAT ARE THE PROBLEMS?
For starters, it is fairly obvious that the code must be entered using an assembler at this time. This cannot be considered a fully high level language for that reason. In fact, we really prefer INTERACTIVE languages such as BASIC. So we need to see whether this thing can be turned into an interactive language system WITHOUT losing the 'vanishingly small overhead' attribute. The proof of the pudding is in the tasting, and we have not tasted pudding yet. But we think we have figured a way to accomplish that, using a technique in which tables of variable names and labels are maintained which are used ONLY during the interactive or editing made. These tables are ignored while executing the program.
Page 1, Column 2
We assume you noticed that what in BASIC would be a keyword, such as ADD, is instead the 'action address' of the routine which performs the ADD function. So we replace the BASIC one byte keyword with a two byte action address. And we maintain tables which are NOT used at run time so that we appear to the user to have an interactive language. This means that our programs will certainly be larger than conventional BASIC programs. However, variable storage space requirements will NOT be changed versus equivalent BASIC programs.
Well, RAM is getting ever bigger and cheaper. That seems to be a good tradeoff to us; a little extra RAM for a lot more efficient run-time package. If you disagree, go get Dr. Dobbs, Vol. 1, and start writing a 68000 Tiny Basic. Maybe you can get the interpreter to fit in 2K, you clever devil. But don't bother telling us about it, we aren't interested in running slowly.
And talking about 'this thing' is awkward. We need a NAME for our proposed high-level language. Now, this is not as simple as one might think. Initials, for instance, can get one in trouble. IBM once announced a New Programming Language as "NPL". They immediately received a communication from Great Britain's National Physics Laboratory, familiarly known is "NPL". They threatened to write a programing language of their own, known as "IBM" or Incomprehensible Botched-up Mess. The elders of Armonk hastily renamed their new creation "PL/1".
We now have PL/65, XPL0 and whole batch of OTHER 'PL' based names. This mine has been exhausted, we think. What we need is a name which clearly indicates that we have here a programming language, and we also need that name to indicate that we have at hand a HIGH PERFORMANCE language. And we need to avoid provincialism and select a name with built-in world-wide recognition. Lets see, ALGOL is well known world-wide as a computing language. And Hal, the computer in the movie 2001, is well known worldwide as a high performance computer.
INTRODUCING HALGOL!
OK, we've got a recognizable name. Where is the language specification document? THAT, chum, is what we have to work out. Let us for the time being set aside 'specification' and instead consider 'attribute'. We have already decided that the language will include the desirable attributes of exceptionally low run-time overhead and that we will achieve that using threaded code. We will retain the benefits of an interactive environment, and pay the extra memory overhead for that benefit. It will be an extraordinarily simple task to 'compile' the programs written in HALGOL since all we need to do is discard the variable name tables, the label (GOTO, GOSUB) name tables and the edit and list modules of the run-time package. If this latter 'compilation' process requires more than one second, your faithful newsletter editor will personally eat the HALGOL source code without seasoning!
Page 2, Column 1
We need to decide upon 1) how to store the program and data in a memory space which is normally greater than 64K and 2) decide how to implement the interactive aspects of the programming environment. It might appear to the casual reader that decisions relating to the commands functions and syntax of the language are most important. Not so. This language will have user-extensible (and also user-deletable) commands and functions. You will be able to strip the stuff you will never need and add the stuff you do need. 'Shuffle a deck of 52 cards' becomes a single command, 'SHUFFLE'. This DOES assume that you are an assembly language programmer, but 68000 assembly language programming is a whole bunch easier than the 6502 or Z80 (or 8088) equivalent.
All right, the problem has been defined: let us attack the first part of the problem, how to store the program and the data. This has constraints of time and space (and what, we ask, does not?). By space, we mean that if we assign three bytes to every address, we effectively assign 4 bytes since the 68000 likes even byte boundaries. However, if the address of some items can be usefully defined by a two byte address (and hence limited to 64K) then we not only save two bytes of program storage but we also reduce the interpretive overhead. You will recall that the 68000 is data bus bandwidth limited; it takes longer to fetch four bytes than two.
When the 68020 arrives we will have 256K dynamic RAMs and 64K static RAMs as common, garden variety, inexpensively available devices. At that time, using a four byte address descriptor will become common and ordinary.
Right now, we are all close enough to the BAD OLD 64K era that we are uncomfortable with the idea of 'wasting' those two extra bytes. We propose a compromise:
A) All of the entrance points to the HALGOL commands and functions will reside in the 64K zero page. The two byte action address will therefore ALWAYS point at executable 68000 code.
B) Since some extensions will eventually require more than 64K RAM, the executable code in zero page (for these extensions only) will be limited to a JMP (long address) to the retaining executable code which can be anywhere in the 68000 address space. Each command or function will therefore require a minimum of 6 bytes of the available zero page. In the limit, we can have more than 10,000 commands or functions without running out of zero page space. This preposterously large number (most BASICS have fewer than 128 commands and functions) proves that we are not limiting ourselves by this two-byte address convention for the execution address of the command or function.
Page 2, Column 2
C) We will begin with the simple numeric variables stored in the zero page directly. At 8 bytes per numeric variable, we could have 2000 possible simple numeric variables assuming the HALGOL interpreter occupied 75% or less of zero page. However, if this becomes a problem in the future, we will go to plan (D) as outlined in the next paragraph:
D) Simple numeric variables can instead be identified with a two byte OFFSET from a BASE ADDRESS. The base address will be a three byte value which will (sensibly, the way the 68000 works) be stored as a four byte or long word value, ONCE, in zero page. The two byte offset therefore can address 64K of simple numeric variables. Now we are 'limited' to 8,192 simple numeric variables!
As a practical matter, we believe that it will be a couple of years before we will need more than 2000 simple numeric variables, and by THAT time memory will be so inexpensive that we will bypass (D) and go directly to four byte address pointers.
E) Simple string variables will be addressed in the same manner as in (D), but with a different base address pointer.
F) It is immediately obvious that arrays, both numeric and string type, will occupy memory space in an amount greater than 64K. We have a choice of simply and directly using a four byte address to point directly to the array or to use the more complex technique of using a two byte pointer to a four byte pointer. The four byte pointer points directly at the array (and the array parameter information). The former method is VERY slightly faster at run-time. The latter method has an advantage in saving program space and seems worthwhile. Each array has its own four byte pointer and each pointer occupies 4 bytes of our 64K zero page. However, it is the rare program which contains more than 100 arrays, so the zero page usage is negligible. We will adopt this latter method.
G) Like arrays, we need to plan immediately for programs which will occupy more than 64K bytes. This means the address pointer following 'GOSUB' or 'GOTO' will be a four byte parameter. Since these are statistically infrequent, this will not have such impact on program size.
As the language HALGOL becomes 'fleshed out' it is possible that some of those memory usage techniques will be modified. We consider ourselves pragmatic rather than dogmatic (as several readers have cleverly noted, we are even planning to manufacture some 68XXX boards on which Dtack will NOT be grounded!). Later in this issue we will illustrate the very real run-time advantages of HALGOL.
Page 3, Column 1
WE GET LETTERS:
"The biggest problem with readability of Forth programs, in my opinion, is the resistance to using variables. Heavy use of the stack results in anonymous values, referenced to an ever-changing top of stack, and is very hard to follow... In any case, my point is that any language which uses a stack heavily will have the same characteristics." B.W.W., San Pedro CA.
Bruce, HALGOL will NOT use a stack heavily.
"Oregon Software is working on a (Pascal-2) package for the 68000. Do read their advertisement in a recent copy of Byte and send for their literature. Perhaps your Dtack board could fly with Pascal-80." Dr JSK, Lewiston ID.
John, we called Oregon Software. They have a successful package which they sell for $3,500 per CPU on PDP11/70s and VAXs. They understandably have no interest in selling this package at a price appropriate to the Apple market. And frankly, neither are any of the OTHER vendors of 68000 software packages. You see, the word is out that the 68000 is ONLY usable in minicomputers, so everyone writing 68000 software is pricing it at minicomputer levels.
A LETTER DATED THE SAME DAY that we mailed the last issue asserts that MICRO magazine is indeed very seriously searching for articles on the 68000 and suggests that Dtack board owners might be natural sources of such articles. You can call MICRO at (617) 256-5515 and ask for a free copy of their writer's guide.
"...if those 4 engineers and 4 software guys don't get busy, my warrantee will expire and I will blame them... Who is able to use Smalltalk on an Apple? ...you have obviously perceived by now that I am highly qualified to be the newsletter editor advertised for in issue #10." R.D., Minneapolis MN.
Ron, you said FOUR high level languages, TWO months. We expect results, not excuses (putting the blame is NOT an Olympic event, by the way). We know absolutely nothing about running Smalltalk on an Apple. We have not written anything about running Smalltalk on in Apple in this issue. THAT IS OFFICIAL. YOU WILL BELIEVE IT!
We do not think that you meet the high standards required of a newsletter editor for this publication. Nearly all of your words are spelled correctly. As Mark Twain observed, "That man has a poor imagination who can think of only one way to spell a word." Judging by the sample you sent us your son Reid DOES qualify for the job. Unfortunately the state of California has these pesky child labor laws...
Page 3, Column 2
Mark Twain is, of course, the pseudonym of Samuel Longhorne Clemens. In "Life on the Mississippi" Sam wrote, "War talk by men who have been in a war is always interesting; whereas moon talk by a poet who has not been in (sic) the moon is likely to be dull." Sam, we don't know which watering hole you favor these days, but we have interesting poets who talk of the moon now.
And in case any of our readers wonder why we explained who Mark Twain is, we have readers in Yugoslavia, Germany, England, Venezuela, Japan, Norway and Texas.
"...the Aristocard people. There would appear to be something very odd about the operation as the people at the other end of the telephone quoted (in the Apple Orchard product announcement) denied all knowledge of Simon or his works. Similarly, the zip code is an impossible one." J.A., Reading, England.
"...I think in newsletter #9 you wrote something about a British company offering 68000 boards for Apple. The company is Simon Computer, the board is called "Aristocard", it costs about $900 (= 475 pounds) and they don't answer any letters... P.S.: My girlfriend who loves your letters would be glad if you sent her a foto of yourself..." O.B., Hamburg, W. Germany.
Gentlemen, we remember writing something about the Aristocard but we are doggoned if we can find the reference IN OUR OWN NEWSLETTER! Oliver, your girlfriend is to be congratulated on her good taste. We have our secretary out looking for a Robert Redford photograph, which we will autograph and forward.
"For seven years, I worked for a manufacturer of some of the world's largest number crunchers. The systems were fantastic at crunching numbers. But, they were lousy at everything else... Control Data's NOS (Network Operating System) has a response time that is pitiful compared to a 68000 running UNIX. And there's a factor of between 500 and 1000 difference in the price.
"A certain company who shall be nameless, advertises a system called the (name deleted) which (they claim) can support 32 users. Nowhere in any of this advertising is there a definition of what 'support' really means... Look: if you have a one MIP machine, and you divide it between 32 people, you have about 30,000 instructions per user per second... The well established performance models tell you that you'd better utilize only about 50%, so now you're only giving the user 15,000 instructions per second... On UNIX, it probably takes that such time to process an interrupt from a terminal." H.M., Mt. View, CA.
Henry, are you trying to tell us that loading up one CPU with 32 users isn't a super neat idea? After all we have asserted in these pages supporting such sharing?
Page 4, Column 1
"...I hear that Mickey Mouse wears an Apple watch." (name deleted), England.
(Name deleted), since Apple does not seem to be spending much time selling product lately, they may have more time to file lawsuits. A word to the wise...
"We received your journal via the copying machines. Thank you, nevertheless... we should tell you that certain machines of the mentioned kind (Japanese brands) don't mind the red color at all." Dr. E.B., Wuppertal, W. Germany.
Ernestus, only a cad would photocopy the sacred red pages! As to the use of Japanese copiers, surely you remember that we fought a war against them 40 years ago?
THE RUMOR MILL:
We recently heard a VERY interesting rumor. It seems that this well known company has been working an a 68000 based computer for a long time now. As the rumor has it, they had invested over 100 man-years of programming effort in the project. Well, none of that software ever worked satisfactorily so they junked it and went hat in hand to Microsoft. "Would you folks write us some software so that we can run (code name of computer)? Please?", they were rumored to have asked.
As the rumor goes, Microsoft delivered a software package to this well known company in June and (code name of computer) now runs. Unfortunately (the rumor continues), the big brass at the well known company are displeased because (code name of computer) runs very slowly. Now, this rumor is not specific as to the REASON (code name of computer) runs slowly.
Unfortunately, this rumor will be of less interest to you since we have completely forgotten which well known company is involved and we have also forgotten the code name of the computer.
ANOTHER RUMOR:
Counting our Dtack board, there are now no less than three 'attached processors' available for the Apple II. One of the others uses a Z80B and the other uses an 8088. It seems some other people have figured out that being forced into lockstep with that slow Apple memory bus seriously degrades performance. What follows is an open message to these other vendors:
Fellows, congratulations on a good piece of engineering. True, we have been pointing out the advantages of an attached processor in this newsletter for a year now, but you obviously arrived at your decision independently or you would be using the 68000, not the Z80B and 8088. Now for the bad news: there are a great many Apple owners who know more about hardware design and performance than YOU do. And these many owners are, judging by our experience, going to give you a great deal of flak over not using the 'obviously superior' DMA approach to exchanging data with the Apple.
Page 4, Column 2
REMEMBER THE S.C.C.S.?
Way back before there was an Apple or Pet and when Noah was still laying his keel there was this outfit called the Southern California Computer Society. It met once a month at TRW near Los Angeles International Airport. You would see 700 to 1000 people show up to hear 14 year olds lecture poorly about BASIC.
We attended two or three of those meetings before some members' money started disappearing and the mood of the club soured. However, the club held on for a year or two and in fact founded the magazine S.C.C.S. Interface which later became Interface Age. We want to tell you about a particular meeting when a MITS representative showed up with the 6800 (NOT 68000) version of the Altair. The 6800 version was a lot smaller (and cheaper), being a one board system. Without, we add, a whole lot of memory on board.
The MITS representative incautiously took the cover off this computer in the lobby while the 14 year old lectured in the main meeting hall. The MITS rep set the unit on the floor so that the twelve or so persons gathered around could all see and ask questions. Your faithful newsletter editor was one of the twelve.
When one of the onlookers asked about the limited memory, the MITS rep stated that his company was about to come out with a memory expansion board. Oh? Just where would this expansion memory plug in? we asked. "The expansion board goes here." explained the rep, swirling his hand in the space above the single board. But there is no CONNECTOR on the main board for the expansion memory to plug INTO! we exclaimed. This embarrassed the rep, since most of the other onlookers caught on to the problem. After a short exchange whose detail we have forgotten, the rep stated cuttingly, "You'll never buy a computer anyway!" Then he put the cover on his computer and left. We remember the conversation well because we were one of the few people at that S.C.C.S. meeting who DID have a computer at home!
And now our reason for dredging up that old story: We have just received from a correspondent in England a nicely done six page brochure printed by Simon Computer. About four of those pages feature the Aristocard, a 68000 card which plugs into the Apple bus and uses Apple memory to run. This means that each 16 bit fetch or store is done as two consecutive 8 bit memory cycles. Since the 68000 is almost totally bus bandwidth limited (more on this subject elsewhere in this issue) that means the effective speed of the card is about equal to a 2.4MHz 68000. The official clock rate is 4MHz whenever the bus is not being utilized.
Page 5, Column 1
Now, so far this card is configured almost exactly the way OUR 68008 card will be toward the end of the year (or whenever the 68008 becomes real). And the performance is just about exactly what we anticipate for our card. But since they have to add some logic to fool the 68000 into doing two memory cycles on the Apple for one on the 68000, the card is a tad expensive at 475 pounds. That's over $800 U.S.
But the kicker is that there will shortly be a 128K expansion board for the Aristocard which will permit the clock rate to go to 8MHz just like the basic speed of OUR 8MHz board (that's what the brochure clearly states!). This means that someplace an that card there must be a connector carrying, as a minimum, 16 data lines, A16 thru A1 (16 more lines) plus AS, LDS, UDS and R/W. That is 36 signal lines minimum not including +5 or ground. And at 8MHz you usually need lots of ground lines. And you usually need a bunch of buffers for all those lines.
If you will take out our newsletter #3, you will see on the far right side of the board two 50-pin connectors and five 20-pin LSTTL signal buffers for OUR expansion board. Actually, we use half of the 20 pin chip just above the 68000 as a buffer as well, but we bring out ALL the address lines. Since there is a very large and very clear photograph of the Aristocard on the brochure, we looked for the corresponding connectors) and buffers (the board is small; there isn't such room to hide).
There ain't none.
Which means you will be able to expand the Aristocard by 128K and switch to an 8MHz clock shortly AFTER you plug the memory expansion board into your 6800 Altair.
The person who mostly doesn't write the FWAUG newsletter visited us in person recently and became the FIRST (but not last) person to suggest that we put a memory expansion connector on our yet undesigned 68008 Apple compatible board. He pointed out that it would require only a few traces on the P.C. board and should not increase the cost at all! He apparently had not counted the required signal lines and apparently was thinking of operating without buffers. There is an ABSOLUTE MINIMUM of 36 signal lines, not including ground lines. And we think we would need buffers!
(According to MICRO, the FWAUG newsletter is published 9 times a year. Seven of those issues must be printed using invisible ink!)
Page 5, Column 2
IT IS A CURIOUS FACT that although we frequently receive suggestions that we add hardware features (such as the ever-popular 300 baud RS232 port) to our 68000 boards, most of the suggestions either ignore the associated costs or else specifically assert that the hardware can be added with no increase in price. We have been in the electronics hardware manufacturing business for 20 years now and we have NEVER been able to add hardware features without an associated increase in cost. A company which increases its costs without a corresponding increase in price is not long for this world, guys.
Our planned 68008 board is intended to have the lowest possible price. We said $200 to $250 and we mean it. While we cannot absolutely promise to pull that off, we DO absolutely promise to TRY. The way to achieve the lowest possible price is to eliminate any unnecessary cost. So, dear reader, we ask you to please refrain from writing or calling with suggestions of features which can be added to our proposed 60008 board, features which naturally will not require a price increase!
(One thing which might affect the price is the question of whether to put on-board memory for the 68008 separate from the Apple memory space. Using an 8MHz 68008, that would double the effective "bus bandwidth", permitting TWO bytes to be fetched each microsecond instead of just one using the Apple memory. But the extra memory increases the price. Maybe we need a choice of both kinds of boards?)
POSTSCRIPT: Since the above was written we have received TWO suggestions that we add 64K RAM to our proposed 68008 board. Neither suggestion was accompanied by a proposed compensatory price increase. Sigh.
HOT 68008 FLASH!
To Motorola's enormous surprise, the very first 68008 mask set worked, with no known bugs. Maybe we will have a sample by the time we mail this newsletter?
We will not see whether this is as important to the 68000 user community as we think, because WE are going to be the first to ship real 68008 boards that fit completely inside the Apple II, just like all those OTHER alternate CPU boards. Which means the dynamic RAM board is going to be set aside temporarily, and the 68008 project given top priority.
One of the nice things about a low-priced board fitting entirely within the Apple II case is that less software is needed to justify a less costly purchase. And since we now have a young programmer working for us doing nothing but generating software which we will give away, we may sell a board or two or three.
Page 6, Column 1
MORE PROCESSOR COMPARISONS:
At the very last minute before taking the last issue to the printer, we received in the mail a copy of the article briefly mentioned an page 12 (of issue 11). We only had time to present a VERY brief summary of that article. There is MUCH MORE in that article that will be of interest to most of our readers.
First, the article was written by a group of graduate students of the Computer Science Division of the University of CA, Berkeley. The abstract reads: "We describe an experiment to test the 432 as a high-level language uniprocessor by comparing it with the 8086, 68000, and VAX-11/780 for four integer and character programs written in Ada, C, and Pascal."
Our own interest in the 432 is now zilch. However, we can toss out the 432 and we still have a nice comparison of the 8086, 68000 and VAX 11/780.
Finding unbiased comparisons is not difficult if you know how, by the way. Here is our method: Articles and ads are constantly published using bar graphs to compare various processors. MANY such comparisons have been published by the various manufacturers. It should not be surprising that each ad proves conclusively the superiority of the advertiser's product, no?
The thoughtful reader say wonder about the collective factual content of those articles and ads. Here is how we winnow the wheat from the chaff: when Zilog compares its product against the 8086 and 68000 we simply throw out the Zilog data and assume that we have a relatively unbiased comparison of the 8086 and 68000. When T.I. publishes a bar graph comparing the 99000 to the 8086, Z8000 and 68000 we throw out the 99000 data.
If we do this enough times and take a weighted average we will have a pretty good idea of the performance of the various contenders. One additional precaution is necessary: we have to be careful to note what clock speeds are cited in the comparisons. It will be necessary to factor the advertised clock speeds versus those generally available (for ALL of the contenders) to arrive at a final realistic comparison.
An example: Suppose National were to advertise that the 16032 is faster than the 68000. Since their promotional literature asserts that the 16032 is a 10MHz device, they would doubtless compare that 10MHz part (?) to an 8MHz 68000. They would naturally select those things which the 16032 does particularly well, which is business as usual in this game. For instance, the 16032 apparently does outperform the 68000 at 32 bit multiplication. But ALL of the speed comparisons, including the multiply, would be seriously biased in Nationals' favor (surely you are not surprised, chum?).
Page 6, Column 2
The bias would involve the comparison of a 10MHz 16032, which does not exist, against a mere 8MHz 68000. The VERY limited number of working 16032 samples available right now run at 6MHz. Even a crummy little outfit like us is shipping commercial 68000 product which runs at 12.5MHz. The ratio by which the National advertisements would overstate the relative performance of their product can be calculated thusly:
RATIO = (10/6) times (12.5/8), or OVER 2.6!
If National were to assert that it actually had a few working 8MHz parts, we would reply, So what? Motorola has had a few working 16MHz 68000s for many months now (the article was dated May 17 '82. The tests using the 16MHz 68000 were surely performed MUCH earlier).
National intends to have 10MHz parts someday? Wonderful! Our money says that a shrunk mask version of the 68000 runs at 20MHz before they reach 10MHz. Any takers?
So, we have an unbiased comparison of the 8086, 68000 and VAX 11/780. EVEN BETTER, we have performance data on a 60000 with NO wait states (Dtack effectively grounded) and another 68000 with FOUR wait states. Where did they find a 68000 with four wait states? Would you believe that $28,900 turkey called the EXORMACS has FOUR wait states on every memory fetch (if this article is correct)?
Please note from the figure on the next page that a 68000 with four wait states runs at about 55% the speed of a zero wait state machine with the same clock speed. Now, these are integer and character benchmarks. With an AVERAGE mix of multiplies and divides, the degradation in throughput will not be quite as bad. We will assign the equivalent throughput for the example given at 60%, and support that conclusion as follows:
The 68008 requires TWO memory cycles to fetch one word of an instruction. Each memory cycle requires four clock cycles, so a 68008 (with no wait states) is equivalent to a 68000 with four wait states. And Motorola spokesman have been quoted as stating that the 68008 will have 60% of the performance of the 68000 given equivalent clock rates. Q.E.D.
DID YOU NOTICE THAT WE HAVE NOT spent a lot of time pointing out how the 68000 ran away from the VAX? Not even how our own 12.5 MHz boards compare? As a PRACTICAL matter we really do not think anyone is going to study that chart, puzzling over whether to buy a VAX or a Dtack board! OTHER considerations, such as software support on the one hand and a FAR lower price on the other will force that decision!
Page 7
432 8086 68000 VAX-11/780
| **
| **
1.5 -+- **
| **-12.5MHz
| ** ##
| ** ##
| ** ##
1.0 -+- ** **
| ## ** **
| ## ** **
| ## ** **
| ## ## ** **
0.5 -+- ## ** ## ** **
| ** ## ** ## ** **
| ## ** ## ** ## ** **
| ## ** ## ** ## ** **
0.1 -+- ## ** ## ** ## ** **
| ** ** ## ** ## ** ## ** **
+---------------------------------------------------------
4MHz 4MHz 10MHz 5MHz 8MHz 8MHz 8MHz 16MHz
R2 R2* R3 0WS 0WS 4WS 0WS 0WS
12WS 12WS 4WS
************ #############
Figure 2: * measured * and # predicted # performance
************ #############The figure above is taken from the article " A Performance Evaluation of the Intel iAPX 432" which appeared in Computer Architecture News Volume 10, No. 4, June 1982 on page 26. We have added to the figure the performance level of a 12.5 MHz 68000 with no wait states. Note that this performance far exceeds the existing VAX 11/780 and is approximately equal to hypothetical improved VAX systems which may be developed in the future.
Page 8, Column 1
A CANDID CONFESSION:
For nine years now, Digital Acoustics has made its living making environmental noise monitors. In July '81, we decided to make high performance attached processors as a 'fun' hobby. Well, as of July '82 we are a company which makes high performance attached processors for a living and also makes environmental noise monitors as a profitable annoyance. The growth in Dtack sales in the past four months has been phenomenal.
Our sales policy, 10% down and COD or full payment in advance, will become a necessity instead of an arbitrary decision very soon if our sales continue to grow. Dtack is an obvious economic success. It is also a 'quality control' success since no failures have yet been reported (all Dtack boards are still in warranty). And when we read the accounting report we get this nice warm feeling deep down inside.
However, we have NOT achieved our original objective. Which was to bring an extraordinarily high performance processor to the individual dedicated personal computer hacker. The cash register jingles merrily but we have bad art. Since a major objective of our Dtack endeavor was to have fun, we worry over this lack of artistic success. Digital Acoustics is NOT run by an accountant!
WHERE THE SALES HAVE GONE: Most of our recent board sales have been either fully loaded 92K varieties, frequently with a 128K expansion board. The 12.5MHz option is becoming increasingly popular (yes, the expansion board runs nicely at 12.5MHz). But we are selling these boards to businesses, not hackers. And we DO mean boards, plural because many of these businesses are buying more than one board. On several occasions the initial TRIAL (!) purchase has been two boards, and on one occasion THREE!
Why are these people buying our boards? Usually it is for a single, highly specific purpose. They have such-and-such a job to do, they (usually) already own Apple computers, sometimes lots of them. So they buy our board to solve this single specific problem. Do you realize what we are describing? The Dtack boards are being purchased as MINICOMPUTERS!
Look, a minicomputer is a device which is invariably purchased as the solution to a particular problem. Absent the problem, no sale. Yes, we know, we said this before. But we are becoming financially successful selling a product which we did not intend to manufacture! The fact is, we simply have not been thinking of our product in terms of its application as a minicomputer.
Obviously, others have.
Page 8, Column 2
YOUR TYPICAL MINICOMPUTER MANUFACTURER has these characteristics: 1) Pricing is unrelated to manufacturing costs. 2) EVERYTHING is a secret! 3) The company is run by the accountants, who have no heart and no art. If it is necessary to step on a few people to achieve a good 'bottom line', so what? 4) There is this thing called a list price...
Its like this, guys: A LIST PRICE is published. If you knock three times, ask for Harry and promise to buy a few dozen minicomputers as soon as your prototype system is debugged, you magically become an OEM. Like generals, there are various grade OEMS. One grade only gets a 20% discount (didn't knock hard enough). The next grade gets a 30% discount (should have asked for Don). But the very highest grade OEMs get a 40% discount off that list price. But YOU are not an OEM, so YOU have to pay FULL LIST'
AS YOU CAN SEE, we do not hold your typical minicomputer manufacturer in high regard. And we are now, de facto, a minicomputer manufacturer. The bottom line states that we are a SUCCESSFUL minicomputer manufacturer. So we will now change our style, right? First off, we have to have a little secrecy around here! Which means that we either stop publishing this newsletter or we turn it into a conveyor of promotional puffery, devoid of truth (small t variety) or useful information. BULLSHIT!
(In the past we have used the phrase 'not in accordance with the facts' as a substitute for that last word. The substitute seems inappropriate here.)
We LIKE our present policies. We are comfortable with them. We like to be able to truthfully state what our future plans are in this publication. And, when an event such as the earlier-than-expected arrival of the 68008 comes along, we modify our plans accordingly and report that fact here. We like to be able to publish source code in REDLANDS (where nobody can copy it). We get no ulcers worrying about security leaks. And best of all, we are making a nice profit so that we can not only continue these policies but also justify them to our stockholders (Digital Acoustics is a corporation).
What we do NOT like is the fact that we have not been able to sell very many Dtack boards to individual hackers. We honestly believe that our boards are one heck of a good deal for anyone who can write assembly language. There are also significant advantages for persons who write programs in BASIC, significant meaning a five time (and up) increase in speed when used with a compiler. According to the report by Alan Wood published in our last newsletter, there are even some advantages for PASCAL programmers. Why have we been mostly unsuccessful in this area?
Page 9, Column 1
A FICTIONAL HISTORY OF THE PERSONAL COMPUTER INDUSTRY:
As we all know, the personal computer industry was founded by Jack Tramiel, who was tired of repairing typewriters; Jobs and Wozniak, who were tired of being ciphers in huge organizations; and Tandy, which was tired of selling doorbells which played "The Yellow Rose of Texas."
Severally and separately there grew three companies which manufactured small computers at a price low enough to be personally affordable. However, each of these companies made the same terrible mistake. In their innocence, they did not realize the importance of security.
There they went, openly telling everyone exactly what they were doing, publishing software which rightfully should be sold. The mistaken antics of these new companies (OK, new division in Tandy's case) caused snickers at DEC and guffaws at Data General. It was obvious to those professionals that the upstarts were destined to fail.
Knowledgeable observers mark the publication of "Sweet Sixteen" in Nov '77 BYTE magazine as the start of the inexorable decline of these new companies, particularly that of the Apple Computer Co. You see, Wozniak actually PUBLISHED the (super-secret) heart of the Apple INTEGER BASIC interpreter!
Since there were no suitable (read $25 or less) 16 bit microprocessors available, Wozniak had simply written a SOFTWARE EMULATION (called "Sweet Sixteen") of a 16 bit processor, and proceeded to write his system software using that emulation! Any rational person could see that such important software tools must be kept secret lest they aid and comfort the competition!
As a result of this ludicrously inadequate security, Jack Trameil is back repairing typewriters, Jobs and Wozniak are ciphers again and Tandy sure hopes you are in the market for a doorbell which plays "The Yellow Rose of Texas."
The personal computer market is of course now dominated by Data General, followed closely by DEC, General Automation and other long-time small computer manufacturers. Unconfirmed rumors report that Data Generals' personal computer shipments have now reached the unheard-of level of 700 units per month!
If one were to judge by the actions of many companies NOW making personal computers, one would be led to believe that the short history outlined above is REAL.
Page 9, Column 2
While those 100 companies which have announced 68000 based minicomputers are focussing on preventing each other from knowing what is going on, they have failed to perceive that they are collectively in competition with the 8088 culture headed by IBM. Surely any company which has the resources to produce a stand-alone 68000 system has more persons knowledgeable about the 68000 than us. If each of those companies would contribute, say, one page of technical information to the general (68000) cause each month we would have in embarrassment of data. An embarrassment means, of course, that it would be impossible to read all of it.
Instead, those 100 companies are permitting the general public to retain the idea that the 8088 is a real, honest new generation 16 bit processor, JUST LIKE THE 68000! How do they expect the public to pay premium prices for their minicomputers if they do not explain the premium performance afforded by the 68000? The fact that Micro Magazine is scrambling hard to get articles about the 68000 is proof that the attitude of those 100 companies is deliberate, not accidental. The situation should rightfully be reversed; Micro should be buried in manuscripts submitted by those companies.
Let's toss out the Tandy 16; Tandy operates strictly in a world of its own. We have been waiting for one of the other 99 68000 based computers to become generally available. It is easy to announce a new product, not so easy to place production models on a retailer's shelf. We found it quite interesting to read an advertisement in the sports section of a recent Los Angeles Times. A Computerland advertisement contained a nice picture of a Fortune mini, er, personal computer. There was also a suggestion that the reader might like to drop in and purchase same. This is absolutely the FIRST advertisement by a retailer for a 68000 based product that we have seen.
But where in the personal computer press does one read promotional literature extolling the virtues of the Fortune product? Nowhere!
In newsletter #10, we asked our readers generally for comments on random number generators and received more than a dozen replies before we went to press with issue #11. In issue #11 we asked our readers generally to report publication of information on the 68000 in other periodicals and we have received not one peep. Which means that for a period of over a year, the crummy rag you are now reading has been the ONLY periodical with any information an the 68000. Gentlepersons, that situation is RIDICULOUS.
Your faithful newsletter editor is NOT, by any reasonable standards, an expert on the 68000. We know for a fact that several readers know more about the 68000 than we do. And yet, for most of you, the only information you can get regarding the performance of the 60000 and its relative merit with respect to other processors is what you read here.
Page 10, Column 1
How did we, all of us, get in this mess?
We got in this mess because virtually all of the companies making small computers are dominated at the management (decision making) level by persons with minicomputer backgrounds. And ALL minicomputer types have absolutely nothing but contempt for personal computers. You don't believe it? Call on your local DEC or Data General (or Nixdorf or Facom) sales office. Ask one of those minicomputer types, face to face, his opinion of the Apple or Pet. The chances are he will fall down laughing!
(We specifically except Commodore, Sinclair and Osborne from that charge in the last paragraph. We believe it is no accident that the sales volume of these three companies continues to increase phenomenally. On the other hand, Apple Computer has had sales of 133, 132 and 142 million in its last three quarters. That is hardly a phenomenal increase.)
The fact that Motorola perceived the 68000 as being useful only in incredibly complex, expensive systems also contributed to the mess we are in. To this day Motorola has not one single application note on the 68000 describing a small, simple system.
WHERE DO WE GO FROM HERE?
We see two conflicting events coming up fast. First is the adoption of the 68000 by Micro Magazine, for which we all should think Bob Tripp. This will certainly help the general awareness of the potential of the 68000, especially if Bob can bring himself to permit the publication of the enormous performance differential of the 68000 vs. the 6809.
Running counter to this trend is the rapidly approaching public sale of 68008 boards, mostly for the Apple II. The 68008 is NOT a high-performance part and, when tied to the one-byte-per-microsecond Apple bus, will be even lower in performance. Our promotional material on our 68008 board will candidly admit that the board is NOT a high-performance product. But we are almost certain that other vendors of essentially the same product are going to hype their product as being representative, performance-wise, of the 68000 family (sales are more important than the facts, right?).
If the public is permitted to perceive that the performance of the 68008 when locked to the slow Apple bus is typical 68XXX performance, those 100 companies making 68000 minicomputers are in GREAT BIG TROUBLE. Which they DESERVE for their own lack of promotion!
Page 10, Column 2
On the front page of newsletter #2 we declined to discuss the relative performance of the 68000, concluding "People might think we were prejudiced, or something!" By now, everyone KNOWS we are prejudiced, so here goes:
We will assign an arbitrary performance rating of one to a 1 MHz 6502, since most of our readers are familiar with a computer using such. We are going to compare the 6809, 8086/8 and 68000/8 to that 6502 for GENERAL PURPOSE computing. This is a difficult task at best, and at worst an obvious opportunity for outrageous exaggeration. All we can do is assure the reader that we have spent considerable time (the past several years) arriving at these figures. First the figures:
MICRO CLK WS MEM CY BY/CY PERF
6502 1 0 1 1 1.0 (ref)
6502 3.6 0 1 1 3.6
6809 1 0 1 1 1.3
6809 2 0 1 1 2.6
8086 10 0 4 2 10
8086 8 0 4 2 8
8086 5 0 4 2 5
8088 5 0 4 1 3.5
60000 12.5 0 4 2 20
68000 8 0 4 2 13
68000 8 4 8 2 7.8
60008 8 0 4 1 7.8
68008 8 4 8 1 3.9CLK is the clock speed in MHz. WS is the number of wait states. MEM CY is the number of clock cycles required by a memory read operation. BY/CY is the number of bytes transferred on each (program) read operation. PERF is the performance relative to the 1MHz 6502.
Comparing the performance of different processors is done by the method reported earlier. By "general computations" we mean the particular mix of instructions used when running, for instance, an interpretive BASIC program. If more specialized benchmarks are used, it is easy to "cook" the results. For instance, the 6809 obviously multiplies much more swiftly than the 6502. But branches take one or two clocks longer, zero page references one clock longer. A 32 bit add is done in 34 clocks by the "16 bit" 6809 and in 38 clocks using the 8 bit 6502. Incidentally, the three page article on 32 bit addition in April MICRO magazine was badly botched. The writers were obviously completely unfamiliar with the 6502 and its addressing modes.
Page 11, Column 1
Let us examine the 3.5 rating we gave the 5MHz 8088. The slick ad which has been running in BYTE forever asserts a performance rating of 4, but adds the qualifier "running most applications." We believe that is about equivalent to our unqualified 3.5 rating. However, if one is to judge by the well-known fact that the IBM PC is only a little faster than Applesoft (even with the advantage of a six digit F.P. format), one would assume the 8088 should be rated far lower. We believe the discrepancy is due to the fact that most 8088 (and 8086) systems are actually running translated 8080 programs. Our rating assumes code written specifically for the processor in question.
Motorola has published an article which asserts that the 68000 at 8MHz is five times faster than the 2MHz 6809. We agree. Intel has reported that the 8088 has 70% the throughput of the 8086. We agree. Motorola has been predicting a throughput for the 68008 of 60% that of the 68000 for equivalent clock speeds. The benchmark results published in the C.A.M. article discussed earlier in this issue support that conclusion; a 68000 with 4 wait states is functionally equivalent to a 68008 with no wait states. 60% it is.
The 68008 with 4 wait states is what we are going to see when the 68008 is forced into lockstep with the one-byte-per-microsecond Apple II bus. The predicted performance is only slightly better than that of the 8088 when used in this manner. IF THE PERFORMANCE OF THE 68008 ON THE APPLE BUS IS ACCEPTED BY THE PUBLIC AS TYPICAL OF THE 68XXX FAMILY, US 68000 VENDORS ARE IN GREAT BIG TROUBLE!!
As CPU speeds approach infinity, the performance of a particular processor becomes directly proportional to the bus bandwidth. The 8 bit version of an infinitely fast CPU would have exactly 50% the performance of its 16 bit equivalent. The 68008 with a 60% throughput is therefore closer to this ideal than the 8088 with 70% the throughput of its 16 bit equivalent.
Although the 8MHz 68000 and the 8MHz 8086 have exactly the same bus bandwidth (four megabytes per second) with no wait states, the 68000 is considerably faster because of the greater speed of the CPU and also because of its vastly greater internal resources. Having sixteen each 32 bit registers pays off, as we said on page one of issue #2.
The 6809 was designed as a CHEAP processor which is EASIER TO PROGRAM than earlier 8 bit processors. These two design objectives were met admirably; the designers are to be congratulated. The 6809 was never intended to be a fast part so pipelining (which the 6502, 8088 and 68000 have) was left out and instruction prefetching (which the 8088 and 68008 have) was left out. As a result, the 6809 is not very much faster than the 6502 despite its superior instruction set and greater internal resources.
Page 11, Column 2
MORE MAIL:
"...how come your operational, in hand, working board is only about 20% faster than the ALF 8088 'advertised' Applesoft speedup board? ...We have another 'benchmark' of our own- a problem programmed in Fortran, using integer addition and comparisons and little else. A 4341 MOD II did it in about 6.3 seconds run time while your 12.5MHz programmed in 68000 assembler (no we do not run Fortran on it yet) ran the problem in 4.5 seconds. This benchmark is meaningful to us since the development time was about the same (neglecting the 6502 interface etc.). Why don't you toot about that? (A 4341 II is about 25% faster than a 370/158 although a mite slower than the 3033.) ...Our phone call (ref #10 DG) was not frantic...' B.P., St. Louis, MO.
It sure sounded frantic at this end, Bob. You realize, of course, that absolutely no one is going to believe our 12.5 job blew away one of eye beyem's mainframes, don't you? Or a VAX 11/780? (Incidentally, Bob, the GGF contribution went AWOL somewhere between St. Louis and Santa Ana. And would you please give that typewriter ribbon a decent burial?) Now, about that ALF (or FTL) benchmark:
We direct the interested reader to one of those full page ads by ALF Products, such as the one on page 373 of July '82 BYTE. The 8088 card considerably sped up an Applesoft benchmark. We are reporting their results here along with ours. The times are in seconds.
Applesoft 51.7
TASC 41.5
Applesoft w/ALF 23.6
TASC w/ALF 13.3
Applesoft w/8MHz DG 20.1
Applesoft w/12.5 DG 19.7
TASC w/8MHz DG 9.4
TASC w/12.5 DG 8.9
HALGOL w/8MHz DG 1.62
HALGOL w/12.5 DG 1.04(HALGOL timings by oscilloscope.) A simple examination of the two Applesoft/DG timings shows the 6502 is taking 19 seconds to soft the Apple while the 8MHz DG board requires 1.1 seconds and the 12.5 job 0.7 seconds to support the 6502. It therefore follows that the ALF board, which hooks into Applesoft the same way ours does, requires 4.6 seconds to get the job done. That's 6 1/2 times slower than our 12.5MHz board.
What is obvious is that nothing is going to get done in a hurry as long as that feeble-minded 6502 is in the way. HALGOL almost completely eliminates the 6502; we DO let it place the ASCII numeric characters on the CRT. (Actually, Applesoft does not use strict ASCII; bit D7 is a one instead of a zero.)
Page 12, Column 1
The alert reader will note that a better than 5 times improvement was achieved using the combination of TASC and our DG board, even though that particular benchmark features very simple math. With heavy duty number crunching the speedup would be 8 to 12 times. But HALGOL gives us a 32 to 50 times improvement! Those readers who have wondered why we have not emphasized the use of our board with a compiler lately please note.
Our board DOES work well with a compiler. But it works one heck of a lot better if we bypass that idiot 6502. Now do you see why your faithful newsletter editor sometimes gets a bit er, ANNOYED when asked why we did not design our system for concurrent operation with the 6502?
REDLANDS WILL FEATURE THIS MONTH the HALGOL listing of the benchmark published by ALF, plus a few of the interpretive routines used by HALGOL. You will not notice that the first page of REDLANDS is printed on white paper.
We are reprinting (with permission) the following information taken from the Aug. '82 issue of MICROCOMPUTER PRINTOUT Magazine, an English publication which once specialized in the Pet but has recently broadened their coverage. This issue has a superb section on CP/M, by the way.
MAKE U/W I.B. SALES/MONTH
Commodore 6,700 95,000 2,600,000
Sinclair 20,000 300,000 1,600,000
Sirius 500 1,500 1,220,000
Acorn 3,500 18,000 1,150,000
Apple 1,100 30,000 1,000,000
Tandy 950 24,000 760,000
Osborne 450 1,000 420,000
Sharp 1,400 13,500 304,000
Atari 475 5,000 130,000
T.I. 200 3,000 35,000Sirius is Chuck Peddle's 8088 machine, marketed in the U.S. under the Victor label (see Aug. '82 BYTE, p.281). Sinclair and Acorn are English makes; Sharp is the only Japanese machine listed. The Japanese are taking over the personal computer market VERY SLOWLY! (We even remember when it was TI that was going to take over.)
U/M is units shipped in England per month, I.B. is the installed base. SALES/MONTH is in pounds. The pound is worth less than two dollars these days; we will not list the exact ratio to avoid upsetting our English friends.
Well, you DID want to know what's happening on the other side of the big creek, didn't you?
Page 12, Column 2
COMPETITION REPORT:
Most of you have heard of CURSOR, which was a cassette magazine for the Pet computer. CURSOR was produced by The Code Works under the leadership of Ron Jeffries. Well, Ron has started a newsletter (The Jeffries Report) about general doings on the personal computer scene. The price is $15 US & Canada, $20 elsewhere for six monthly issues. If you are interested, make your check out to The Code Works, Box 550, Goleta CA 93116. Here is an excerpt from issue #2, quoted with permission:
"I have information from several sources that a group in Orange County, California has copied the Apple-II motherboard and may have copied the DTACK GROUNDED 68000 attached processor board for the Apple. The same group is reported to also distribute stolen software.
"...Those (DTACK's) prices sees fair to me. I don't understand why the Orange County group would want to steal the design.
"The disturbing thing about this specific case is that it may be an indicator of a much deeper problem. I haven't heard of similar hardware design thefts, but it seems like a large fraction of personal computer users either steal software or look the other way when stolen software is distributed.
"The most important point is not how many dollars VisiCorp, Microsoft, or Micropro have lost because of software theft. What worries me is that theft is being condoned on such a grand scale. Our social fabric depends on trust and integrity, and anything that erodes those values is dangerous. I welcome your comments on this topic."
Ron, you are clearly not attuned to our wonderful modern American society. It just happens that in the past two months we have had occasion to report two instances of what seemed to be theft. In each case we were asked, "Why are you sticking your nose into this matter? It is no skin off YOUR nose; you are not the one being ripped off. Why not leave it alone?"
We believe that our society is (or should be) one large community. When the resident of a proper community sees his neighbor's house being burglarized he calls the police THEN rather than waiting for his or her OWN house to be hit. If we do not help others, who will help us? As Ron has by bringing this matter to our attention.
We ask those readers who share our attitude to keep a sharp lookout for counterfeit DTACK boards, especially in the Orange County area.
Well, we SAID this was a competition report, didn't we?
Page 13, Column 1
THIS YOU WILL NOT BELIEVE: We recently received an 11 page handwritten letter inviting us to help save the world from tyranny and for democracy. After two readings, we think the writer was (is) serious. For one thing, an 11 page handwritten letter is too much work for a gag. However, we must respectfully decline.
It happens that WE are opposed to tyranny and friendly inclined toward democracy ourselves. But there is just so such one person can do! OUR little crusade is a full time job and then some. Besides, we do not think the technical objective proposed by the writer is within the current state of the art. We do wish him well.
EDITOR'S REPORT II: These past six issues have been, more or less, our SECOND attempt at publishing a newsletter. After all, we had reserved the option of 'turning it off' after the first six issues. Well, we have decided to continue for yet ANOTHER six issues. We have a couple of optimists among our readers who are paid up through issue #24. If we decide to discontinue this newsletter after #18, they will be reimbursed in cash.
The next six issues will hopefully include contributed material since we are beginning to develop a respectable customer base. Also, we need to avoid duplicating the sort of material that is going to be published in Micro. We have no desire to compete with regular magazines. We will continue to report on developments of high-performance products usable in personal computers. And we will continue to report on the development of HALGOL, which some of you may have noticed has some resemblance to a compiled BASIC.
It now requires forty hours of personal effort to produce one issue of this newsletter. Since we are also beginning to write copy for full page ads, it seems likely that we will publish less frequently. Say, six weeks per issue.
The reader say be interested to know that each page of this newsletter occupies 30 to 32 sectors on disk. For an issue such as #10, which had no REDLANDS, that is 480 sectors!
FIRST MISTAKE DEPT: Becoming a newsletter editor.
SECOND MISTAKE DEPT: The article "Rethinking the 256-kb RAM" referenced on page 10 of our last newsletter appeared in the IEEE Spectrum (not Computer) magazine.
THIRD MISTAKE DEPT: Our statement that the 16MHz 68000 could be purchased is apparently incorrect. We have tried to buy one, with no success. Although the device does exist, its status is 'limited sampling'. Meaning Control Data can get one and General Dynamics can get one but Dtack Grounded can't.
Page 13, Column 2
FOURTH MISTAKE DEPT: REDLANDS is supposed to be printed on red paper except for issue #4 which was supposed to be printed on yellow paper. We DID use yellow for the first printing. But the second printing accidentally was done on white paper. The third printing, recently done, came out on red paper. Now, one of these days we are going to get it right again!
68000 vs. VAX: The reader is reminded that the benchmarks cited earlier are not general purpose benchmarks; they are tests of the ability of the computers to handle characters (text) and to execute procedure calls. No claim is made that the 68000 can bang floating point numbers at VAX rates. In fact, those readers with long memories will recall that we flatly stated in newsletter #2 that the 68000 really needs a companion math processor to offload (double precision) floating point computations to make the most effective use of its considerable capabilities.
SIDEBAR: An Apple User Group newsletter, which shall go unnamed, recently published a rationale for a company charging more for a product than the basic parts cost. It seems that the writer would permit the company to add the cost of labor and rent plus a percentage to be set aside for expansion of the (manufacturing) plant. There was no mention of any profit to reward the investors who put up their money to start the manufacturing operation.
Has our society departed so far from the precepts of free enterprise that 'profit' has become a dirty word, not to be used in polite company?
THE FOLLOWING TRADEMARKS ARE ACKNOWLEDGED: Apple; singular, II, III and soft: Apple Computer Co. Pet and CBM: Commodore Business Machines. VAX: Digital Equipment Co. TASC: Microsoft. DTACK GROUNDED and HALGOL: Digital Acoustics, Inc.
SUBSCRIPTIONS: You can subscribe by sending $15/6 issues U.S. and CANADA or $25/6 issues elsewhere. Tell us which issue number to begin with. Make the check out to DTACK GROUNDED. The address is:
DTACK GROUNDED
1415 E. McFadden, Ste. F
SANTA ANA CA 92705
FAREWELL, MAYBE, AGAIN: For most of you, this is the last issue of your current subscription. You may regard this notice as a very broad hint that you should consider sending us another check.
IN THIS MONTH'S (uncopyable) REDLANDS we have the complete listing of the FTL benchmark as written in HALGOL. Included is assembly language listings of some of the HALGOL functions.
Code Listing 1
1 OPT P=68000,BRS,FRS
0022D0 2 ORG $0022D0
3
4 * THIS IS THE START OF THE THREADED CODE
5
0022D0 226E 6 START DC.W INIT CLEAR 1K
0022D2 22C2 7 DC.W TIMING START TIMING
8
0022D4 203C 9 DC.W MOVE MOVE #5 TO B
0022D6 2338 10 DC.W FIVE
0022D8 2344 11 DC.W B
12
0022DA 203C 13 LOOP1 DC.W MOVE MOVE #3 TO C
0022DC 2332 14 DC.W THREE
0022DE 234A 15 DC.W C
0022E0 200C 16 DC.W LOAD CALC SQR (B)
0022E2 2344 17 DC.W B
0022E4 2376 18 DC.W SQR
0022E6 201C 19 DC.W STORE STORE FOR LATER
0022E8 2350 20 DC.W SQRB
21
0022EA 200C 22 LOOP2 DC.W LOAD CALC B/C
0022EC 234A 23 DC.W C
0022EE 20A0 24 DC.W DIV
0022F0 2344 25 DC.W B
0022F2 2380 26 DC.W FRAC
0022F4 20FA 27 DC.W JIFZER BRANCH IF ZERO
0022F6 2314 28 DC.W NXB
29
0022F8 200C 30 DC.W LOAD CALC=C+2
0022FA 234A 31 DC.W C
0022FC 2088 32 DC.W ADD
0022FE 232C 33 DC.W TWO
002300 201C 34 DC.W STORE
002302 234A 35 DC.W C
002304 2090 36 DC.W SUB CALC SQR(B)-C
002306 2350 37 DC.W SQRB
002308 20DE 38 DC.W JIFPOS BRANCH IF >= 0
00230A 22EA 39 DC.W LOOP2
40
41 * INTEGER PRINT B
42
00230C 200C 43 DC.W LOAD FETCH B
00230E 2344 44 DC.W B
002310 2356 45 DC.W INT TAKE INTEGER
002312 21FE 46 DC.W IPRINT PRINT IT
47
002314 200C 48 NXB DC.W LOAD CALC B=B+2
002316 2344 49 DC.W B
002318 2088 50 DC.W ADD
00231A 232C 51 DC.W TWO
00231C 201C 52 DC.W STORE
00231E 2344 53 DC.W B
002320 2090 54 DC.W SUB CALC 1000-B
002322 233E 55 DC.W THOU
002324 20DE 56 DC.W JIFPOS BRANCH IF >= 0
002326 22DA 57 DC.W LOOP1
58
002328 22C2 59 DC.W TIMING END TIMING SIGNAL
00232A 2236 60 DC.W END
61
62
# 0000200C 63 LOAD EQU $00200C
# 0000201C 64 STORE EQU $00201C
# 0000203C 65 MOVE EQU $00203C
# 00002088 66 ADD EQU $002088
# 00002090 67 SUB EQU $002090
# 000020A0 68 DIV EQU $0020A0
# 000020DE 69 JIFPOS EQU $0020DE
# 000020FA 70 JIFZER EQU $0020FA
# 000021FE 71 IPRINT EQU $0021FE
# 00002236 72 END EQU $002236
# 0000226E 73 INIT EQU $00226E
# 000022C2 74 TIMING EQU $0022C2
# 0000232C 75 TWO EQU $00232C
# 00002332 76 THREE EQU $002332
# 00002338 77 FIVE EQU $002338
# 0000233E 78 THOU EQU $00233E
# 00002344 79 B EQU $002344
# 0000234A 80 C EQU $00234A
# 00002350 81 SQRB EQU $002350
# 00002356 82 INT EQU $002356
# 00002376 83 SQR EQU $002376
# 00002380 84 FRAC EQU $002380Code Listing 2
1 OPT P=68000,BRS,FRS
2
3 * COPYRIGHT 1982 DIGITAL ACOUSTICS, INC.
4
002000 5 ORG $002000
6
7 * THIS IS THE BEGINNING OF A THREADED PROGRAMMABLE
8 * CALCULATOR-LIKE INTERPRETER. THE FLOATING POINT
9 * PACKAGE FOR THIS VERSION IS THE NINE DECIMAL
10 * DIGIT APPLESOFT COMPATIBLE PACKAGE.
11
12 * HERE IS THE ADDRESS REGISTER USAGE:
13
14 * A7 IS THE MACHINE STACK POINTER
15 * A6 IS THE PROGRAM POINTER
16 * A5 IS A SCRATCH REGISTER
17 * A4 IS DEDICATED TO POINT TO F__TH
18 * A3 IS THE PROGRAM SUBROUTINE STACK POINTER
19 * A2 IS THE DATA STACK POINTER
20 * A1 IS UNDEFINED AS YET
21 * A0 IS A SCRATCH REGISTER PRIMARILY USED
22 * TO POINT AT FLOATING POINT VARIABLES.
23
24 * ALL OF THE DATA REGISTERS ARE SCRATCH REGISTERS.
25
002000 3C7C 22D0 26 BEGIN MOVE.W #START,A6 START ADDR
002004 387C 2008 27 MOVE.W #HALGOL,A4
28
002008 3A5E 29 HALGOL MOVE.W (A6)+,A5 FETCH ACTION ADDR
00200A 4ED5 30 JMP (A5) JUMP TO ACTION ADR
31
00200C 3A5E 32 LOAD MOVE.W (A6)+,A5
00200E 31DD 1902 33 MOVE.W (A5)+,S1
002012 21D5 1904 34 MOVE.L (A5),M1
002016 4278 1908 35 CLR.W G1 CLEAR GUARD BYTE
00201A 4ED4 36 JMP (A4) RETURN TO HALGOL
37
00201C 3A5E 38 STORE MOVE.W (A6)+,A5 ADDR TO PTR A5
00201E 4EB8 1536 39 JSR ROUND ROUND GUARD
002022 3AC0 40 MOVE.W D0,(A5)+
002024 2A81 41 MOVE.L D1,(A5)
002026 4ED4 42 JMP (A4) RETURN TO HALGOL
43
002028 3A5E 44 TOTAL MOVE.W (A6)+,A5
00202A 31D5 1902 45 MOVE.W (A5),S1
00202E 425D 46 CLR.W (A5)+
002030 21D5 1904 47 MOVE.L (A5),M1
002034 4295 48 CLR.L (A5)
002036 4278 1908 49 CLR.W G1 CLEAR GUARD
00203A 4ED4 50 JMP (A4) RETURN TO HALGOL
51
00203C 3A5E 52 MOVE MOVE.W (A6)+,A5 SET SRC ADDR
00203E 305E 53 MOVE.W (A6)+,A0 SET DEST ADDR
002040 30DD 54 MOVE.W (A5)+,(A0)+ MOVE S,X
002042 2095 55 MOVE.L (A5),(A0) MOVE MANT
002044 4ED4 56 JMP (A4) RETURN TO HALGOL
57
58
# 00001536 59 ROUND EQU $001536
# 00001902 60 S1 EQU $001902
# 00001904 61 M1 EQU $001904
# 00001908 62 G1 EQU $001908
# 000022D0 63 START EQU $0022D0Code Listing 3
1 OPT P=68000,BRS,FRS
0020DE 2 ORG $0020DE
3
4 * JUMP TO LABEL IF FPACC1 > OR = ZERO
5
0020DE 3A5E 6 JIFPOS MOVE.W (A6)+,A5 LABEL ADR TO A5
0020E0 1038 1903 7 MOVE.B X1,D0 TEST ZERO
0020E4 67 10 8 BEQ JPOS2 JUMP IF ZERO
0020E6 66 08 9 BNE JPOS1 TEST SIGN
10
11 * JUMP TO LABEL IF FPACC1 IS GREATER THAN ZERO
12
0020E8 3A5E 13 JIFGTZ MOVE.W (A6)+,A5 LABEL ADR TO A5
0020EA 1038 1903 14 MOVE.B X1,D0 TEST ZERO
0020EE 67 08 15 BEQ JGTZX EXIT IF ZERO
0020F0 1038 1902 16 JPOS1 MOVE.B S1,D0 TEST SIGN
0020F4 6B 02 17 BMI JGTZX EXIT IF NEGATIVE
0020F6 3C4D 18 JPOS2 MOVE.W A5,A6 STORE JUMP ADDR
0020F8 4ED4 19 JGTZX JMP (A4) RETURN TO HALGOL
20
21 * JUMP TO LABEL IF FPACC1 IS ZERO
22
0020FA 3A5E 23 JIFZER MOVE.W (A6)+,A5 LABEL ADR TO A5
0020FC 1038 1903 24 MOVE.B X1,D0 TEST ZERO
002100 66 02 25 BNE JZERX EXIT IF NOT ZERO
002102 3C4D 26 MOVE.W A5,A6 STORE JUMP ADDR
002104 4ED4 27 JZERX JMP (A4) RETURN TO HALGOL
28
29
# 00001902 30 S1 EQU $001902
# 00001903 31 X1 EQU $001903Code Listing 4
1 OPT P=68000,BRS,FRS
0021FE 2 ORG $0021FE
3
4 * INTEGER PRINT A 32 BIT BINARY WORD TO THE HOST
5
0021FE 7E A0 6 IPRINT MOVEQ #$A0,D7
002200 61 EE 7 BSR OUTCHR OUTPUT A SPACE
002202 2238 1904 8 MOVE.L M1,D1 MANT1 TO D1
002206 66 0A 9 BNE IPR1 SKIP IF NOT ZERO
10
002208 7E B0 11 MOVEQ #$B0,D7
00220A 61 EA 12 BSR OUTCH OUTPUT A ZERO
00220C 7E A0 13 IPRX MOVEQ #$A0,D7
00220E 61 E6 14 BSR OUTCH OUTPUT A SPACE
002210 4ED4 15 JMP (A4) RETURN TO HALGOL
16
002212 70 09 17 IPR1 MOVEQ #9,D0 SET FOR 9 LOOPS
002214 307C 219E 18 MOVE.W #BATBL,A0 PTR TO TABLE
19
002218 5300 20 IPR2 SUBQ.B #1,D0 DECR LOOP COUNT
00221A 2A18 21 MOVE.L (A0)+,D5 FETCH CONSTANT K
00221C B245 22 CMP.W D5,D1 COMPARE K, MANT1
00221E 65 F8 23 BCS IPR2 LOOP TIL NOT ZER
002220 60 02 24 BRA IPR4 UNCOND JUMP
25
002222 2A18 26 IPR3 MOVE.L (A0)+,D5 GET NEXT K
002224 7E AF 27 IPR4 MOVEQ #$AF,D7 ASCII 0 -1 TO D7
28
002226 5207 29 IPR5 ADDQ.B #1,D7 INCR ASCII
002228 9285 30 SUB.L D5,D1 D5=K, D1=MANT1
00222A 64 FA 31 BCC IPR5 LOOP UNTIL OVFL
32
00222C D285 33 ADD.L D5,D1 CORR UNDFLW
00222E 61 C6 34 BSR OUTCH XMIT ASCII
002230 51C8 FFF0 35 DBF D0,IPR3 LOOP UP TO 9 TIMES
36
002234 60 D6 37 BRA IPRX XMIT SPACE & EXIT
38
39
# 00001904 40 M1 EQU $001904
# 000021F0 41 OUTCHR EQU $0021F0
# 000021F6 42 OUTCH EQU $0021F6
# 0000219E 43 BATBL EQU $00219E
