[net.micro.mac] timing loops

wayne@motatl.UUCP (R.W.McGee) (02/09/86)

The use of software timing loops on an asyncronous
microprocessor should be discouraged. On the 68k family,
these loops will get different results depending on dtack
being the same for rom or ram, and will be different from
the 68000, 68010, and 68020 based on the loop mode of the 
68010 or cache of the 68020. Public floggings would provide
a cure, but would be hard to implement.

Wayne McGee  mot!motatl!wayne

Standard Disclaimer #10

gnu@hoptoad.uucp (John Gilmore) (02/16/86)

In article <156@motatl.UUCP>, wayne@motatl.UUCP (R.W.McGee) writes:
> The use of software timing loops on an asyncronous
> microprocessor should be discouraged...Public floggings would provide
> a cure, but would be hard to implement.

People who design microprocessors, who don't want software to depend
on the timings of individual instructions in particular systems,
should provide a system-independent way to delay for a specified
amount of time.  We use whatever you give us, guys!

E.g. in meeting the recovery time of a particularly good USART chip
with a horrible bus interface, the Z8530, you need to wait 2.2us
between writes to it.  Give me a good way to wait 2.2us *without*
depending on instruction timing, and I'll consider your request.

PS:  if your answer is "add more chips", a lot of people will cheap
out and use "free" software timing loops.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

mat@amdahl.UUCP (Mike Taylor) (02/17/86)

In article <530@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
> E.g. in meeting the recovery time of a particularly good USART chip
> with a horrible bus interface, the Z8530, you need to wait 2.2us
> between writes to it.  Give me a good way to wait 2.2us *without*
> depending on instruction timing, and I'll consider your request.

Well, on a *real* computer, you just set the TOD clock comparator for
now+2.2 us. and go do something useful while you wait.  Sorry, couldn't
resist.

-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]

phil@amdcad.UUCP (Phil Ngai) (02/17/86)

In article <530@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>E.g. in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.

In a design I did with the 8530, the device selection logic made all
8530 cycles about 3 uS long with wait states. For the first 2.2 uS of
the cycle, the 8530 was actually not being accessed.  This guaranteed
the cycle recovery time needed. I had to use a PAL state machine to
assure another parameter (address set up time) and so this cycle
recovery time didn't cost anything extra, except the time it took me
to think it up.

I must admit part of my motivation for doing this was nightmares I had
of obscure bugs showing up because the programmer didn't bother to
read the specs carefully and violating the cycle recovery time.  (or
not even understanding what cycle recovery time was) In this example,
it was possible to idiot proof the hardware at no incremental cost.  I
imagine it is possible to come up with cases where it does cost more
but in my experience a sufficiently innovative design engineer can do
it at no or very low cost (extra pin on PAL).
-- 
 Real men don't have answering machines.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

davet@oakhill.UUCP (Dave Trissel) (02/17/86)

In article <530@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>
>People who design microprocessors, who don't want software to depend
>on the timings of individual instructions in particular systems,
>should provide a system-independent way to delay for a specified
>amount of time.  We use whatever you give us, guys!
>

I grew up with the early IBM 360 and it's built-in interval timer.  Later
models and the 370's had a time of day clock as well.  I have often
yearned to have the same common system-independent timing facilities
in micros as well.  But how do you accomplish that without forcing
every system designer to hook up a constant frequency clock to every
microprocessor in the family?

Of course, the problem is that the basic clock frequency driving the chip
is variable depending on the system.  If we implemented on-chip a clock
or timer register from where would it derive its frequency?  Having an
"adjust divisor" register setup by the system to factor the system clock
would just push the problem right back into the hands of the O.S. coders
where it is now since code somewhere would have to then setup the proper
divisor.

We currently have one customer running the MC68020 at 15 Meghertz, so we can't
assume that the "standard" test frequencies of 12.5 and 16.6666 will be used.
Customers are already preparing for the 20 and 25 Megahertz versions but
there is no way to know now what their exact frequencies will end up.

If you or anyone else has any suggestions on how to do this give a yell.

  --  Dave Trissel  Motorola Semiconductor, Austin, Texas
	{ihnp4,seismo}!ut-sally!oakhill!davet
[Sorry, BITNET, ARPANET etc. will not work as destinations from our mailer.]

bmw@aesat.UUCP (Bruce Walker) (02/17/86)

>.... in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.
>
>PS:  if your answer is "add more chips", a lot of people will cheap
>out and use "free" software timing loops.
>-- 
>John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

You must be clocking your 8530 at 3 MHz.  The spec for Valid Access
Recovery Time is 6TcPC+200 (nS (130 for the 'A' part)) where TcPC is
the bus clock cycle time.  At 4MHz you should wait a minimum of 1.7uS
and at 6MHz you only need to wait 1.2uS.

The kind of people that "cheap out" are the kind of people that cripple
their machines in a multitude of other subtle ways which are only
appropriate for closed-architecture "games machines".  Designers who
are creating machines with a future growth path would put in the extra
hardware (which only amounts to a small, registered PAL anyway).

Bruce Walker     {allegra,ihnp4,linus,decvax}!utzoo!aesat!bmw

"I'd feel a lot worse if I wasn't so heavily sedated." -- Spinal Tap

jack@boring.UUCP (02/17/86)

>
>E.g. in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.

Sorry, but this bad makes it a particularly *bad* USART chip, regardless
of any other features.
Imagine writing a device driver for it, finding out that the C compiler
generates such code that there's far more than 2.2us between writes, and
leaving the place. Then, two years later, the site gets a new C compiler
with a much better optimizer..........
-- 
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.

nather@utastro.UUCP (Ed Nather) (02/17/86)

In article <647@oakhill.UUCP>, davet@oakhill.UUCP (Dave Trissel) writes:
> Of course, the problem is that the basic clock frequency driving the chip
> is variable depending on the system.  If we implemented on-chip a clock
> or timer register from where would it derive its frequency?  Having an
> "adjust divisor" register setup by the system to factor the system clock
> would just push the problem right back into the hands of the O.S. coders
> where it is now since code somewhere would have to then setup the proper
> divisor.
> 
> We currently have one customer running the MC68020 at 15 Meghertz, so we can't
> assume that the "standard" test frequencies of 12.5 and 16.6666 will be used.
> Customers are already preparing for the 20 and 25 Megahertz versions but
> there is no way to know now what their exact frequencies will end up.
> 
> If you or anyone else has any suggestions on how to do this give a yell.

Some years ago I was faced with the problem of "upgrading" to a faster mini
and wanted to use the same program for the "old" and "new" ones.  They were
enough different internally to require code to identify which was which, and
adapt accordingly.

I used a counting loop (once, on program start-up) to see whether the program
was running in the fast or slow machine, by checking to see how far it got in
a known amount of time.  In that case, I used an attached teletype machine
as a timer, since it took about 0.1 sec to print a character, and I watched
its "busy" flag in the counting loop.

I'm not proposing to put a TTY on a chip alongside the CPU (I doubt you can
do that ...) but rather a simple, independent (and not very accurate) timer
whose sole job would be to find out how fast the CPU clock is running.
Simple software could then set the proper value into an adjustable count-
down divider so a built-in timer, running off the divided CPU frequency,
would be practical.  The built-in timer need only be accurate enough to
choose among a set of (quantized) clock frequencies.


-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.UTEXAS.EDU

campbell@sauron.UUCP (Mark Campbell) (02/17/86)

In article <530@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>In article <156@motatl.UUCP>, wayne@motatl.UUCP (R.W.McGee) writes:
>> The use of software timing loops on an asyncronous
>> microprocessor should be discouraged...Public floggings would provide
>> a cure, but would be hard to implement.
>
>People who design microprocessors, who don't want software to depend
>on the timings of individual instructions in particular systems,
>should provide a system-independent way to delay for a specified
>amount of time.  We use whatever you give us, guys!
>
>E.g. in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.
>
>PS:  if your answer is "add more chips", a lot of people will cheap
>out and use "free" software timing loops.
>-- 
>John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

I was going to leave this one alone until I heard the H/W developers on the
other side of the wall giggling about it.

NCR has some damned good H/W engineers; and some of the best of these work in
my division.  These guys are so good that they actually let the software drive
the architecture of a machine (what I consider the theoretical ideal, which is
seldom obtained in the "real-world").  Of course, the term "drive" implies a
high level of cooperation; however these guys really listen and make an
effort to support those hardware features that we want.  Unfortunately, there
are often constraints that cause us to miss seeing eye to eye.  As an example...

Recently, we began work on a new machine.  The very first thing the H/W guys
did was obtain a copy of "All the Chips that Fit" (by Lyon and Skudlarek, of Sun)
and proclaim that we wouldn't make the mistakes that Sun made.  The major premise
of the paper was that there were many chips that were on unfriendly terms with
Unix; and that these chips caused a great deal of pain to a Unix implementation.

Unfortunately, management then stepped in and gave us an unit price that was
terrifyingly low.  At the next review of the H/W, we suddenly found that we
were getting many of those chips, or clones of those chips, that were specifically
mentioned in the paper.  We screamed, they screamed, etc.  After digging through
the manuals, however, we found that there was very little that could be done given
their stringent constraints.  A great example was our specification of what we
now call "the mythical 32-bit, low-powered CMOS, battery-backed binary counter".
I keep getting told that a certain BCD TOD chip is really fast.  That doesn't do
me a whole hell of a lot of good when I have to use 2 or 3 pages of conversion code
to support it.

The one thing we did insist upon, though, was glue logic to support those chips
that had timing problems.  Mr. Gilmore stated that microprocessor designers should
design system independed ways of dealing with delays.  What should really happen
is that the chip manufacturers incorporate the delay logic within those chips.
The use of the term "particularly good" when referring to a device with a major
flaw such as this is a non sequiteur.  Software delay loops not only cause poor
performance (due to race conditions, interrupt latency, etc.) during porting but
usually come back to haunt you a year or two later, when you switch to cheaper
alternative sources for the devices.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell

cmt@myrias.UUCP (Chris Thomson) (02/18/86)

In article <2795@amdahl.uucp> Mike Taylor writes:
> Well, on a *real* computer, you just set the TOD clock comparator for
> now+2.2 us. and go do something useful while you wait.  Sorry, couldn't
> resist.

C'mon Mike!  Even a 5860 takes >5 us to context switch (twice).

jimb@amdcad.UUCP (Jim Budler) (02/19/86)

In article <6780@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>...
>Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>of any other features.
>Imagine writing a device driver for it, finding out that the C compiler
>generates such code that there's far more than 2.2us between writes, and
>leaving the place. Then, two years later, the site gets a new C compiler
>with a much better optimizer..........

Sorry, but this sounds like a bad device driver to me, not a bad device.
Depending on a poor C compiler for timing is just as bad as depending
on any other non-portable 'feature' of a C compiler.  The device driver 
could be broken by a new C compiler in any of a few thousand other
ways.
-- 
 Jim Budler
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200

rshepherd@euroies.UUCP (Roger Shepherd INMOS) (02/20/86)

Have a look at the transputer. Apart from a bug in REV A devices, all
transputers (no matter what speed selection) run of a standard (5 or 25 Mhz
) clock frequency. This is used to derive the standard comms link
speed and the processor clock. The transputer's real time
clock/alarm runs at 1 tick per micro-second at high priority,
this means that the occam program below will look at (eg) a uart
once every 5 uS. The accuracy achievable is quite good as the iunterrupt
latency (time to go from low to high priority) is about 58 cycles worst 
case (2.9 uS for a T414-20 - currently available parts are -12 so are
have 4.64 uS latency). 

PRI PAR
  SEQ 
    ... initialisation
    WHILE polling
      SEQ
        TIME ? AFTER nextinstance
        ... poll uart or whatever
        nextinstance := nextinstance + 5 -- 1 tick per uS
  ... -- rest of system at low priority
-- 
Roger Shepherd, INMOS Ltd, Whitefriars, Lewins Mead, Bristol, BS1 2NP, UK
Tel: +44 272 290861
UUCP: ...!mcvax!euroies!rshepherd

mat@amdahl.UUCP (Mike Taylor) (02/20/86)

In article <221@myrias.UUCP>, cmt@myrias.UUCP (Chris Thomson) writes:
> In article <2795@amdahl.uucp> Mike Taylor writes:
> > Well, on a *real* computer, you just set the TOD clock comparator for
> > now+2.2 us. and go do something useful while you wait.  Sorry, couldn't
> > resist.
> 
> C'mon Mike!  Even a 5860 takes >5 us to context switch (twice).

Yes, but context switching isn't useful! Actually, just trying to point
out that for timing like 2.2 us., regardless of how good your timing
facility is (S/370 architecturally has 244 picosecond resolution), you can't
ignore instruction timing.  Fielding the external interrupt when the
clock comparator "hits," even without a full context switch, will take quite
a few cycles to save registers, etc. before being able to do any useful
work.  What is even worse is the more or less unpredictable timing
delays due to cache effects, (consistency, misses) to say nothing of
EC level changes (a cycle here or there...)  It is probably true to
say that you can't usefully time anything to a resolution better
than plus or minus 20 cycles (300 ns.) even on a machine which has good
timing facilities.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]

andrew@aimmi.UUCP (Andrew Stewart) (02/21/86)

In article <2795@amdahl.UUCP> mat@amdahl.UUCP writes:

>In article <530@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes:
>> E.g. in meeting the recovery time of a particularly good USART chip
>> with a horrible bus interface, the Z8530, you need to wait 2.2us
>> between writes to it.  Give me a good way to wait 2.2us *without*
>> depending on instruction timing, and I'll consider your request.
>
>Well, on a *real* computer, you just set the TOD clock comparator for
>now+2.2 us. and go do something useful while you wait.  Sorry, couldn't
>resist.
>

On a *real* computer, you use the front panel keys. USARTS??? TOD clock???
Ha! (Remember the PDP-8, only bigger and better...)

	Andrew Stewart
-- 
-------------------------------------------
Andrew Stewart		 USENET:   ...!mcvax!ukc!aimmi!andrew

"My axioms just fell into a Klein bottle"

farren@well.UUCP (Mike Farren) (02/22/86)

In article <2817@amdahl.UUCP> mat@amdahl.UUCP (Mike Taylor) writes:
>(S/370 architecturally has 244 picosecond resolution)

   I admit to knowing little about the S/370, but a 4 GHz clock rate?
Can someone verify this, please?   I don't remember seeing any microwave
plumbing in a 370... :-)

-- 
           Mike Farren
           uucp: {your favorite backbone site}!hplabs!well!farren
           Fido: Sci-Fido, Fidonode 125/84, (415)655-0667

ka@hropus.UUCP (Kenneth Almquist) (02/22/86)

>> Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>> of any other features.
>> Imagine writing a device driver for it, finding out that the C compiler
>> generates such code that there's far more than 2.2us between writes, and
>> leaving the place. Then, two years later, the site gets a new C compiler
>> with a much better optimizer..........	[JACK JANSEN]
>
> Sorry, but this sounds like a bad device driver to me, not a bad device.
> Depending on a poor C compiler for timing is just as bad as depending
> on any other non-portable 'feature' of a C compiler.  The device driver 
> could be broken by a new C compiler in any of a few thousand other
> ways.						[JIM BUDLER]

I don't like the idea of depending upon the C compiler for timing, but
what is the alternative?  Write the specific parts of the device driver
in assembly language?  This introduces maintainance problems of its own.

You frequently have to depend upon non-portable features of C when writing
device driver code, but of course device drivers are non-portable anyway.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)

jack@boring.uucp (Jack Jansen) (02/22/86)

In article <9645@amdcad.UUCP> jimb@amdcad.UUCP (Jim Budler) writes:
>In article <6780@boring.UUCP> I wrote:
>>...
>>Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>>of any other features.
>>Imagine writing a device driver for it, finding out that the C compiler
>>generates such code that there's far more than 2.2us between writes, and
>>leaving the place. Then, two years later, the site gets a new C compiler
>>with a much better optimizer..........
>
>Sorry, but this sounds like a bad device driver to me, not a bad device.
>Depending on a poor C compiler for timing is just as bad as depending
>on any other non-portable 'feature' of a C compiler.  The device driver 
>could be broken by a new C compiler in any of a few thousand other
>ways.

The point here is that, even if you notice the small print in
the datasheet, you look at your driver and say "oh, there's
more than enough time in between writes", and forget about the
whole timing constraint in five minutes.

You're right that the driver could be broken in thousands of ways
by a new compiler, but this is *not* due to the driver, it is
due to the *device*.

There is no way you'll write a device driver that is guaranteed
to work with any C compiler, if you have to take care of timing
considerations (unless you're willing to pay the penalty of using
a *real* timer, of course).
-- 
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.

jimb@amdcad.UUCP (Jim Budler) (02/22/86)

In article <295@hropus.UUCP> ka@hropus.UUCP (Kenneth Almquist) writes:
>>> Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>>> of any other features.
>>> Imagine writing a device driver for it, finding out that the C compiler
>>> generates such code that there's far more than 2.2us between writes, and
>>> leaving the place. Then, two years later, the site gets a new C compiler
>>> with a much better optimizer..........	[JACK JANSEN]
>>
>> Sorry, but this sounds like a bad device driver to me, not a bad device.
>> Depending on a poor C compiler for timing is just as bad as depending
>> on any other non-portable 'feature' of a C compiler.  The device driver 
>> could be broken by a new C compiler in any of a few thousand other
>> ways.						[JIM BUDLER]
>
>I don't like the idea of depending upon the C compiler for timing, but
>what is the alternative?  Write the specific parts of the device driver
>in assembly language?  This introduces maintainance problems of its own.
>
>You frequently have to depend upon non-portable features of C when writing
>device driver code, but of course device drivers are non-portable anyway.

I guess I wasn't quite clear.  If whatever code you generated cannot
guarantee 2.2uS when run through the optimizer then you cannot say that
you have written a good device driver. I got another flame from somewhere
asking me how I thought it should be done without timing loops or
additional hardware. I didn't say not to use a timing loop, but if
you are going to do software timing DO software timing. i.e. put some real
code in there to GUARANTEE whatever time you want.

And yes, in a situation like this, trying to guarantee 2.2uS, I think
a short piece of assembly code to wait 3uS IS the answer. And how much
of a maintenance problem can 5 or 6 lines of assembly code be.  I've
seen many cases like the Vax _doprint in the Berkeley code and a few other
pieces of code with a couple of lines of in line assembly code in them.
-- 
 Jim Budler
 Advanced Micro Devices, Inc.
 (408) 749-5806
 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb
 Compuserve:	72415,1200

davet@oakhill.UUCP (Dave Trissel) (02/23/86)

In article <689@well.UUCP> farren@well.UUCP (Mike Farren) writes:

>>(S/370 architecturally has 244 picosecond resolution)
>
>   I admit to knowing little about the S/370, but a 4 GHz clock rate?
>Can someone verify this, please?   I don't remember seeing any microwave
>plumbing in a 370... :-)

Back when I was working with 370's as a systems programmer the time of day
(TOD) clock systems guaranteed that the resolution was greater than the
shortest possible instruction time.  In other words, you would always
get a unique value from the TOD clock even if you read it with back to back
store clock instructions.

What this indicated was that the clock resolution depended on the machine
model of 370.  The bottom line 370s (370/25 if I remember correctly) were
so slow that a clock frequency of several microseconds would have sufficed.

  --  Dave Trissel  Motorola Austin
  {seismo,ihnp4}!ut-sally!im4u!oakhill!davet

cmt@myrias.UUCP (Chris Thomson) (02/24/86)

> >(S/370 architecturally has 244 picosecond resolution)
>    I admit to knowing little about the S/370, but a 4 GHz clock rate?

The 370 architecture has timers that are 64 bits wide, with the 12th bit
from the right (low order) end being 1 microsecond.  It is model-dependent
how many of the low-order 12 bits actually count, as opposed to holding zero
values.  However, the timer resolution should be similar to instruction
execution time, since the instruction store time of day is required to give
a different answer each time it is used, even on a multiple-CPU
configuration.  Current high-end 370 models have resolutions of a few
nanoseconds.

jer@peora.UUCP (J. Eric Roskos) (02/24/86)

>    I admit to knowing little about the S/370, but a 4 GHz clock rate?
> Can someone verify this, please?   I don't remember seeing any microwave
> plumbing in a 370... :-)

Actually this involves a really interesting aspect of the nature of "time"
on a computer.  Suppose you have (hopefully without loss of generality :-))
a machine all of whose instructions take the same amount of time to execute.
Suppose it can execute 32,768 instructions per second.  Now, suppose you
have a clock that counts in 1/65536ths of a second.  Then, as far as you
are concerned, it's impossible to tell the clock is running that fast...
depending on when you began execution relative to the counter in the clock,
the low-order bit will always be a zero or one every time you look at it.

Although it's possibly not as obvious, the same thing happens if you don't
have such "round" numbers... if the timer is counting faster than your
CPU's basic cycle time (and if the CPU runs with a fixed-rate clock) then
the timer's counter will appear to be being incremented by some constant
value, and there's no way to tell it's going faster than that.

So, you can replace the faster timer with a much slower one that increments
its counter by this integer, and no one will be able to tell the difference.
Of course, this assumes that the timer doesn't do anything else, e.g.,
control some external devices which rely on the faster clock rate.

Actually this generalizes to an even more interesting idea, viz., that if
a CPU doesn't have any kind of reliable external clock to measure time
against, then if you stop the CPU's clock occasionally, or make it run
irregularly, the CPU's "idea" of time will be such that events external to
it that are happening at a constant rate will appear to the CPU to be
occurring irregularly.  So you get to experiment a little with the
relativistic nature of time this way.
-- 
UUCP: Ofc:  jer@peora.UUCP  Home: jer@jerpc.CCUR.UUCP  CCUR DNS: peora, pesnta
  US Mail:  MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company)
	    2486 Sand Lake Road, Orlando, FL 32809-7642

mat@amdahl.UUCP (Mike Taylor) (02/24/86)

In article <689@well.UUCP>, farren@well.UUCP (Mike Farren) writes:
> In article <2817@amdahl.UUCP> mat@amdahl.UUCP (Mike Taylor) writes:
> >(S/370 architecturally has 244 picosecond resolution)
> 
>    I admit to knowing little about the S/370, but a 4 GHz clock rate?
> Can someone verify this, please?   I don't remember seeing any microwave
> plumbing in a 370... :-)
> 

Architecture, not necessarily implemented. See S/370 XA Principles of
Operation, IBM pub# SA-22-7085 pp.4-20,4-21
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]

sher@rochester.UUCP (David Sher) (02/24/86)

Just to introduce a theoretical note:
Wouldn't an entirely self timed architecture avoid the issue of
software timing loops?  I would think that this would put the problem
where it belongs, in the hardware.  Of course you pay a certain factor
for self timing (I think it depends on the size of the chunks of hardware
that are self timed).  

Probably this has no relevance to current real machines but I'm an academic
anyway.
-- 
-David Sher
sher@rochester
seismo!rochester!sher

dick@ucsfcca.UUCP (Dick Karpinski) (02/26/86)

In article <6790@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>
>There is no way you'll write a device driver that is guaranteed
>to work with any C compiler, if you have to take care of timing
>considerations (unless you're willing to pay the penalty of using
>a *real* timer, of course).

I thought someone suggested a solution:  Build a timing loop, but
set its constant (how many cycles) using some other, possibly low
precision, timer to see how fast the loop is _today_ with this
compiler/clock/cpu-chip/whatever.  I _think_ that one can usually
count on those things remaining constant _during_ this run of the
program, i.e. between reboots of the OS.  I have heard of systems
which change their cpu clock on the fly, but you probably know
that when you write the device driver.  Is that enough?

Dick
-- 

Dick Karpinski    Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick   (415) 476-4529 (12-7)
BITNET: dick@ucsfcca   Compuserve: 70215,1277  Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143

ron@brl-smoke.ARPA (Ron Natalie <ron>) (02/27/86)

> In article <2817@amdahl.UUCP> mat@amdahl.UUCP (Mike Taylor) writes:
> >(S/370 architecturally has 244 picosecond resolution)
> 
>    I admit to knowing little about the S/370, but a 4 GHz clock rate?
> Can someone verify this, please?   I don't remember seeing any microwave
> plumbing in a 370... :-)
> 

Who said anything about a 4Ghz clock rate?  All he said was the architecture
supported that resolution.  If the 370 time register were incremented by
one, it would be updated every 244 picoseconds.  However each machine
in the line increments it by a somewhat larger number corresponding to the
speed of the clock on that processor.  Hence, the higher order bits have
been consistant accross 10 years of processors and will continue to be
so for quite a few years to come I would expectr.

-Ron

franka@mmintl.UUCP (Frank Adams) (03/04/86)

In article <6780@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>>E.g. in meeting the recovery time of a particularly good USART chip
>>with a horrible bus interface, the Z8530, you need to wait 2.2us
>>between writes to it.
>
>Sorry, but this bad makes it a particularly *bad* USART chip, regardless
>of any other features.

It seems to me that from theoretical considerations, there will always be
*some* time dependencies in any device.  If you run it with a fast enough
processor, it will stop working.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108

rb@ccivax.UUCP (rex ballard) (03/06/86)

In article <443@ucsfcca.UUCP> dick@ucsfcca.UUCP (Dick Karpinski) writes:
>In article <6790@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>>
>I thought someone suggested a solution:  Build a timing loop, but
>set its constant (how many cycles) using some other, possibly low
>precision, timer to see how fast the loop is _today_ with this
>compiler/clock/cpu-chip/whatever.  I _think_ that one can usually
>count on those things remaining constant _during_ this run of the
>program, i.e. between reboots of the OS.  I have heard of systems
>which change their cpu clock on the fly, but you probably know
>that when you write the device driver.  Is that enough?
>
>Dick
>-- 
This works ok UNLESS you have a high speed cache (like the 68020)
AND are servicing non-maskable interrupts.  The timing in a tight
loop can wander all over the place, depending on how often the
interrupts scramble your cache.  Problems can ALSO occur when
co-processors or multiple DMA devices are sharing the bus and your
processor has low priority.

greg@utcsri.UUCP (Gregory Smith) (03/10/86)

In article <1162@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>It seems to me that from theoretical considerations, there will always be
>*some* time dependencies in any device.  If you run it with a fast enough
>processor, it will stop working.

False. A processor-to-device interface can be designed in such a way that
an access to a slow device will cause the processor to be 'stopped' until
the device is ready. This can be done in a port-dependent way, i.e. if
there is only one slow device on the bus, the processor will only be
slowed when that device is accessed. The 'stopped' state of the processor
is sometimes called a 'wait' state.
On many systems, this technique is the rule rather than the exception -
I think UNIBUS is an example.

-- 
"So this is it. We're going to die."	- Arthur Dent
----------------------------------------------------------------------
Greg Smith     University of Toronto       ..!decvax!utzoo!utcsri!greg