Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41606
| 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> |
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
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