kds@intelca.UUCP (Ken Shoemaker) (02/25/86)
I say this once (I won't say where) and I thought it was really cute. The
way it works, is that you have a standard timing loop "value", and whenever
you need a timing loop, you load this value into your loop variable. On
reset, you calculate this value using some known time standard, whose
resolution need not be anything like what you need for your timing loops,
e.g., a 1 second timer interrupt, a character transmition time, or
something like that.
I realize this can have some problems, what with caching, but it does
relate somewhat the speed of the processor to real time.
--
If you don't like the answer, then ask another question! Everything is the
answer to something...
Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
---the above views are personal.mc68020@gilbbs.UUCP (Tom Keller) (02/27/86)
In article <218@intelca.UUCP>, kds@intelca.UUCP (Ken Shoemaker) writes: > I say this once (I won't say where) and I thought it was really cute. The > way it works, is that you have a standard timing loop "value", and whenever > you need a timing loop, you load this value into your loop variable. On > reset, you calculate this value using some known time standard, whose > resolution need not be anything like what you need for your timing loops, > e.g., a 1 second timer interrupt, a character transmition time, or > something like that. > > I realize this can have some problems, what with caching, but it does > relate somewhat the speed of the processor to real time. > -- > If you don't like the answer, then ask another question! Everything is the > answer to something... > > ---the above views are personal. Well, Ken, I am compelled to consider the source in this case. You are involved in the design of microprocessors at a company infamous for being ----> The Firstest with the Worstest <---- To put it bluntly, Ken, judging on the basis of products shipped, the architectural design team at INTEL have their heads firmly entrenched anally. I am not surprised to see such a flippant response to a serious problem from an INTEL uP designer. The fact is that an I/O chip that can't tell you it isn't ready is a *BOTCH*, pure and simple. {ihnp4, dual}!ptsfa!gilbbs!mc68020 (Tom Keller) ^^^^^^^ /* *WHAT*? **ME** biased?!? */ (* we may not be big, but we're small! *)
phil@amdcad.UUCP (Phil Ngai) (02/28/86)
In article <20@gilbbs.UUCP> mc68020@gilbbs.UUCP (Tom Keller) writes: > To put it bluntly, Ken, judging on the basis of products shipped, the > architectural design team at INTEL have their heads firmly entrenched anally. I think you're wrong. Tell me about the wonderful 68020's MMU, huh? > I am not surprised to see such a flippant response to a serious problem from > an INTEL uP designer. The fact is that an I/O chip that can't tell you it > isn't ready is a *BOTCH*, pure and simple. As a matter of fact, most chips don't tell you when they are ready. When was the last time a RAM chip told you it was ready for CAS after you sent RAS, or even when read data is valid? That's what you have hardware designers for. The hardware designer is supposed to arrange that you don't get data from a RAM chip before it is ready. With a peripheral chip like the 8530, if the hardware designer decides to pass the responsibility on to the firmware writer, that's his choice. But it's not unusual that the 8530 doesn't tell you it's not ready for another command. By the way, Intel did not design the 8530. -- The Hyundai is faster than speeding molasses! Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com