[net.micro.68k] 68k dbcc

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..."

jc@cdx27.UUCP (04/28/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  /