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


Groups > comp.lang.forth > #41606

Re: Registers..

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Registers..
Date 2015-08-29 09:29 -0400
Organization A noiseless patient Spider
Message-ID <mrsc16$7lp$1@dont-email.me> (permalink)
References (1 earlier) <37cef2ff-98f9-4f78-8682-8976c1bcdcaf@googlegroups.com> <mrkgja$3n0$1@dont-email.me> <96123d99-f036-4bd5-989a-7789a3ee6edf@googlegroups.com> <mrm2lj$hia$1@dont-email.me> <e313b40b-5ad0-4a8f-a1d7-db7b8daefc6f@googlegroups.com>

Show all headers | View raw


On 8/29/2015 5:30 AM, Mat wrote:
> Am Donnerstag, 27. August 2015 06:13:18 UTC+2 schrieb rickman:
>> On 8/26/2015 4:50 PM, Mat wrote:
>>> Am Mittwoch, 26. August 2015 15:58:45 UTC+2 schrieb rickman:
>>>> On 8/26/2015 5:07 AM, Mat wrote:
>>>>> Am Dienstag, 25. August 2015 22:35:45 UTC+2 schrieb Mux:
>>>>>> In sort of a follow up on my previous question
>>>>>> (machine-forth != forth?) how do fine people feel about
>>>>>> registers? Particularly curious about having one or more
>>>>>> address registers...
>>>>>
>>>>> Hello, In terms of code flexibility, disadvantages of stack
>>>>> versus register files surely depends on frequent code
>>>>> patterns, parameter usage and the specific subroutine-branch
>>>>> overhead. In terms of design, the implicit addressing of
>>>>> stack files can lead to very compact opcode formats in
>>>>> comparison to designs which are based on explicit register
>>>>> addressing because of the additional needed code-space for
>>>>> register assignment (an exception of this may are
>>>>> accumulator-store architectures). As one recent bottleneck
>>>>> (both in terms of implementation effort and energy efficiency
>>>>> which both can be related together) of recent processors is
>>>>> (more or less) the access-time decrease to external memory,
>>>>> where a compact code format help reducing implementation
>>>>> complexity and can lead to higher cache efficiency. This
>>>>> affect performance and energy usage directly.
>>>>>
>>>>> However, the main disadvantage of stack architectures is the
>>>>> inevitable serial nature of program code which increases
>>>>> complexity if not make it impossible to exploit parallelism
>>>>> at instruction level - at least with conventional
>>>>> established methods.
>>>>
>>>> I don't think that is true.  If I can figure out what can be
>>>> done in parallel by looking at machine code, why can't a
>>>> compiler. Stack architectures are no more inherently serial
>>>> than register designs.
>>>>
>>>> --
>>>>
>>>> Rick
>>>
>>> Probably we have different definitions of instruction level
>>> parallelism in mind. If you take a look at stack code you can
>>> recognize that most instructions depend on the finished execution
>>> of the previous one simply because there exist one possible
>>> destination for computed results, the actual top-of-stack
>>> element. Exceptions from this are only either direct memory
>>> locations or probably some additional registers available.
>>
>> Not sure what you mean by all this.  Whether or not two operations
>> can be paralleled or not has to do with whether the results of one
>> operation are needed as inputs to the other.  Where the results are
>> stored is not relevant.
>>
>> --
>>
>> Rick
>
> because the actual top-of-stack position is both source and
> destination for processed values, the (immediate) storage location
> matters. A general-purpose microprocessor has to check if the later
> instructions need outputs from earlier instructions. If each
> instruction depends on the result of the preceding instruction
> (that's the case for stack based code), then there are no instruction
> level opportunities for out-of-order execution, at least for
> conventional processor designs.

That is your mistake, assuming that stack based code has automatic 
dependencies.  If a, b, c, d are on the stack and the code is OR -rot 
AND swap, the values c and d do not have any impact on the calculation 
of AND while the result of OR has no impact on the calculation of AND. 
So there is no dependency and the two operations can be run in parallel.

You are thinking that because the operands of a calculation depend on 
their position in the stack, this creates dependencies between the 
various operations.  As shown above this is not correct.

-- 

Rick

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


Thread

Registers.. Mux <Yvo.Zoer@gmail.com> - 2015-08-25 13:35 -0700
  Registers.. Mark Wills <markwills1970@gmail.com> - 2015-08-25 15:20 -0700
    Re: Registers.. Mux <Yvo.Zoer@gmail.com> - 2015-08-25 16:19 -0700
      Re: Registers.. "Elizabeth D. Rather" <erather@forth.com> - 2015-08-25 14:54 -1000
      Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-26 00:37 -0400
      Re: Registers.. Mat <dambere@web.de> - 2015-08-26 02:35 -0700
      Re: Registers.. hughaguilar96@gmail.com - 2015-08-26 10:24 -0700
        Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-26 23:56 -0400
    Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-26 00:35 -0400
  Re: Registers.. "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-25 22:32 -0400
    Re: Registers.. Mux <Yvo.Zoer@gmail.com> - 2015-08-25 19:58 -0700
      Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-26 00:43 -0400
  Re: Registers.. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 08:06 +0000
    Re: Registers.. Mux <Yvo.Zoer@gmail.com> - 2015-08-26 07:36 -0700
  Re: Registers.. Mat <dambere@web.de> - 2015-08-26 02:07 -0700
    Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-26 09:58 -0400
      Re: Registers.. Mat <dambere@web.de> - 2015-08-26 13:50 -0700
        Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-27 00:13 -0400
          Re: Registers.. Mat <dambere@web.de> - 2015-08-29 02:30 -0700
            Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-29 09:29 -0400
              Re: Registers.. Mat <dambere@web.de> - 2015-08-29 12:50 -0700
                Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-30 11:13 -0400
                Re: Registers.. Mat <dambere@web.de> - 2015-08-30 09:19 -0700
                Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-30 15:44 -0400
                Re: Registers.. hughaguilar96@gmail.com - 2015-08-30 14:06 -0700
                Re: Registers.. Greg <abiforth@gmail.com> - 2015-08-30 21:07 -0700
                Re: Registers.. Mat <dambere@web.de> - 2015-08-31 01:51 -0700
                Re: Registers.. "Alex McDonald" <blog@rivadpm.com> - 2015-09-01 09:23 +0100
                Re: Registers.. Mat <dambere@web.de> - 2015-08-30 10:08 -0700
                Re: Registers.. rickman <gnuarm@gmail.com> - 2015-08-30 16:01 -0400

csiph-web