kevin@sun.uucp (Kevin Sheehan) (04/10/86)
> There are even further restrictions; you can do a block copy > L: movl a0@+,a1@+ > dbra d7,L > but you can't poll an I/O device's busy bit > M: btst #3,a0@ > dbeq d7,M > and still remain within the cache. > > Does anybody know why Motorola doesn't allow just any instruction > that will fit? > -- > Ken Turkowski @ CIMLINC, Menlo Park, CA the loop mode works by using the instruction prefetch register to hold the instruction. This means only instructions that are 16 bits TOTAL can use loop mode - fortunately, that includes most of the useful ones. the only answers I ever got to "why dont the other 16 bit instructions do it too" was something about not being able to do RMW write cycles, and "internal path/ALU limitations", although the latter still seems like a glib answer. Anybody at MOT have an answer? l & h, kev
davet@oakhill.UUCP (Dave Trissel) (04/13/86)
In article <3479@sun.uucp> kevin@sun.uucp (Kevin Sheehan) writes: > > the loop mode works by using the instruction prefetch register to >hold the instruction. This means only instructions that are 16 bits TOTAL >can use loop mode - fortunately, that includes most of the useful ones. > > the only answers I ever got to "why dont the other 16 bit instructions >do it too" was something about not being able to do RMW write cycles, and >"internal path/ALU limitations", although the latter still seems like a glib >answer. Anybody at MOT have an answer? > Sorry I don't have access to the microcoder at this moment, but from what I remember there are indeed certain classes of instructions which require some kind of special setup in the control unit such that they could not be looped. On the other hand, there is a bit in the microcode for the rest which indicate whether loop mode is allowed. I once coded a benchmark and found to my suprize a two instruction sequence which didn't run in loop mode. It turns out that the microcoder 'thought' nobody would ever code such a loop :-(. This brings to mind another interesting story. I wrote a MC6809 debugger (ASSIST09) as my first 6809 code - and the very first instruction I coded was STX ,X++ which was supposed to store the address of a table at the first slot in the table itself. To my suprize what got stored was the address of table+2. I hit one of the designers up (Terry Ritter) and to my shock he said that they thought there was no reason for anybody to ever code such an instruction! And that was the first 6809 instruction I coded! The lesson here is don't ever say "Nobody will ever try X" with an instruction set. -- Dave Trissel {seismo,ihnp4}!ut-sally!im4u!oakhill!davet
bruce@stride.UUCP (Bruce Robertson) (04/14/86)
> but you can't poll an I/O device's busy bit > M: btst #3,a0@ > dbeq d7,M > and still remain within the cache. The btst instruction above is a 32-bit instruction, since the immediate value takes a whole 16 bit word. What you really want to do is: moveq #3,d0 M: btst d0,a0@ dbeq d7,M -- Bruce Robertson UUCP: cbosgd!utah-cs!utah-gr!stride!bruce ARPA: stride!bruce@utah-gr.arpa
jer@peora.UUCP (J. Eric Roskos) (04/15/86)
> The lesson here is don't ever say "Nobody will ever try X" with an instruction > set. This is very true, and applies to OS & language design as well as instruction set design. Actually I think it has to do with a more general aspect of design philosophy, though. (Ironically, one of the reasons I've always thought highly of Motorola's CPUs is that they usually avoid such problems!) There are two ways you can approach a design: either come up with some set of simple and complete primitives out of which to build the system, then build it consistently using those (this is a sort of axiomatic approach); or just design piecemeal by saying "I think we need this... well, we also need this so let's add it... and don't forget this...". The latter you often see happening in "design by committee", e.g. some of the old and infamous programming languages. I suspect the "minimize the number of architects" principle that Brooks mentions in "The Mythical Man Month" is actually a symptom of this approach. When you have one architect (or a small number of them), they are somewhat forced to design axiomatically, simply in order to reduce the complexity of the design. But designs by larger groups can be done this way, just as designs by an individual can be done the piecemeal way. -- E. Roskos "But all my words come back to me in shades of mediocrity..."
Unknown@hplabs.UUCP (04/28/86)
This message is empty.
jc%cdx27@cdx27.UUCP (04/29/86)
[This is a test to see if the f- command works on our newly-installed usenet site.] > > The lesson here is don't ever say "Nobody will ever try X" with an instruction > > set. > > I suspect the "minimize the number of architects" principle that Brooks > mentions in "The Mythical Man Month" is actually a symptom of this > approach. When you have one architect (or a small number of them), > they are somewhat forced to design axiomatically, simply in order to > reduce the complexity of the design. True, but even single-architect designs often show the same problems. There's nothing that ensures that a single designer won't fall for the "Nobody will every try X" fallacy. And even if the designer understands, there's nothing to prevent implementations to fall short, especially when porting to a new machine by people who barely understand the innards of what they're porting. A nice example that bit me recently was a program on SYS/V that went crazy, eating up cycles but never doing anything. It looked like the traditional infinite loop, but I could show "logically" that it wasn't possible, since there was output generated by even the innermost loops. The problems turned out to be a call of sleep(n), where n turned out to be zero in a few cases. It doesn't work right. You have to say if (n > 0) sleep(n); and note the "> 0"; it'd better be there! Just try getting a bug like this fixed, and you'll appreciate what can be done to you by low-level coders. "That's silly, nobody with any sense would do a sleep(0)." Well, maybe I don't have much sense, but I understand why it's better for the system to do sleep(0) correctly than to clutter up thousands of programs with "if (n > 0)" that is there just to get around a bug in a system call. Next they're going to make an add instruction that fails when either operand is zero, because "It's silly to waste time adding zero to a number." [If you can read this, our readnews' "f-" command works. If there is nothing after this line, the .signature feature has failed.] -- John Chambers /cthulhu\ / fps1 \ / fps2 \ /root ...!{ inmet }!cdx39!{ jc \ mot / \uucp \ ucadmus / \larry /
kenny@uiucdcsb.CS.UIUC.EDU (05/06/86)
/* Written 9:35 am Apr 28, 1986 by jc@cdx27.UUCP in uiucdcsb:net.arch */ [...] >Next they're going to make an add instruction that fails when either >operand is zero, because "It's silly to waste time adding zero to a >number." [...] >-- > John Chambers [...] /* End of text from uiucdcsb:net.arch */ I don't know about adds, but early versions of the Honeywell Level 66 mainframe had a character string move instruction that caused a mysterious machine fault (``illegal instruction,'' if memory serves) if the programmer attempted to move a zero-length string. Caused a lot of code looking like if (length isn't zero) move in to out. all over the system. Also caused some mysterious failures of tested code (tested, that is, on newer machines) when it was installed on processors that didn't have the fix for the bug. Once again, the rationale was that ``nobody in his right mind would ever try to ...'' Kevin Kenny University of Illinois at Urbana-Champaign UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny CSNET: kenny@UIUC.CSNET ARPA: kenny@B.CS.UIUC.EDU (kenny@UIUC.ARPA) "Yes, understanding today's complex world is a bit like having bees live in your head, but there they are."