Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #15281

Re: GA144 Instruction Timing

From Bernd Paysan <bernd.paysan@gmx.de>
Newsgroups comp.lang.forth
Subject Re: GA144 Instruction Timing
Date 2012-08-30 23:11 +0200
Organization 1&1 Internet AG
Message-ID <3163596.DX7DvAse2T@sunwukong.fritz.box> (permalink)
References (12 earlier) <k1jggi$ogi$1@dont-email.me> <20713850.hkHBTRx1hX@sunwukong.fritz.box> <k1luua$ld4$1@dont-email.me> <2071145.76Ub0ZLEUK@sunwukong.fritz.box> <k1odlm$7cm$1@dont-email.me>

Show all headers | View raw


rickman wrote:
> We must be talking about different chips.  The GA144 typical
> instruction timings table lists six different instruction time groups
> not counting
> the prefetch time.

The GA144 timing table lists "logic and stack operations" to have all 
the same timing.  And then, it lists timing for accesses to memory or 
communication ports (which are the same instructions, but they take 
different time), it lists unext/next, and it lists prefetch time, which 
is another memory access.

> Even if there were only two instruction times, the
> point remains that the timing of the CPU is not controlled by an
> oscillator of any sort regardless of how you choose to name the
> control logic.

Well, maybe it isn't.  The way it is described, I would implement it as 
ring oscillator matching the logic, and stop this oscillator each time I 
encounter one of these memory delays - which are the "separate" delay 
paths you mention.  But as you see with prefetch: That separate delay 
path is ignored as long as there are still instructions in the currently 
executed instruction bundle.

>> This probably hurts more when you have several nodes to write to -
>> the F18s wait for the last reader to suspend for reading, before they
>> can continue.
> 
> I don't understand what?  That you can't tell an attempt at humor?

This is actually not that funny.  The way the sync communication is made 
both has an impact on performance as well on correctness (essentially, 
you can't assume that a multi-reader or multi-writer program works if 
you don't meet the very strict design rules).

>>> Oh, there are ways to read and write the port without waiting.
>>
>> Yes?  That's not how I read the documentation.
> 
> I recommend that you read it again... and again... and again.  That is
> what I did.  It has a lot of subtleties.

I've better things to do...

>> I think you can guess the limitations from reading what happens to
>> multiport reads and writes.
> 
> I'm not talking about limitations.  I'm asking about timing.

But as you have written above, the documentation has many subtleties, 
and the limitations give you hints about how it is implemented.

> The states are IDLE, WRITE (waiting for read), READ (waiting for
> write).
>   What you are describing is a handshake with two signals and four
> states which encompass the three I've identified.

Yes, but "encompass" does not mean these states are actually directly 
encoded, or that these three are all possible states.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-11 18:54 -0400
  Re: GA144 Instruction Timing Paul Rubin <no.email@nospam.invalid> - 2012-08-11 17:40 -0700
    Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-12 19:00 -0400
      Re: GA144 Instruction Timing johnmdrake@gmail.com - 2012-08-14 10:17 -0700
        Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-15 18:57 -0400
  Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 07:11 -0700
    Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 10:33 -0400
      Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 12:46 -0700
        Re: GA144 Instruction Timing Jason Damisch <jasondamisch@yahoo.com> - 2012-08-22 13:10 -0700
          Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 18:10 -0400
          Re: GA144 Instruction Timing Paul Rubin <no.email@nospam.invalid> - 2012-08-23 00:03 -0700
            Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-23 19:57 -0400
              Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-24 16:29 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-27 18:33 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 02:45 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-27 21:41 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 22:07 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-28 18:25 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-29 01:41 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-29 16:43 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:13 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-30 15:07 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 23:11 +0200
                Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-09-01 15:15 -0400
        Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 18:05 -0400
          Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 15:46 -0700
  Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-09-02 17:21 -0400

csiph-web