Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51568 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2016-10-03 08:22 -0400 |
| Last post | 2016-10-17 22:05 +0000 |
| Articles | 19 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 08:22 -0400
Re: Stack Sizes foxaudioresearch@gmail.com - 2016-10-03 07:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:14 -0400
Re: Stack Sizes Bernd Linsel <bl1@gmx.com> - 2016-10-03 18:20 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 11:30 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:27 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:12 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 17:52 -0500
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:06 -0700
Re: Stack Sizes Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-10-04 08:31 +0100
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-04 08:46 +0000
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:38 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:59 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-05 09:59 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 10:16 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-06 08:21 +0000
Re: Stack Sizes minforth@arcor.de - 2016-10-04 05:00 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 08:49 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-03 16:28 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 10:36 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes Brad Eckert <hwfwguy@gmail.com> - 2016-11-09 09:56 -0800
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-11-12 09:15 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-03 10:35 -0500
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-11 01:01 +0000
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 10:21 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 11:06 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-03 15:22 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 18:04 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-04 20:46 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:40 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 12:26 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:44 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 16:32 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 20:01 -0400
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:39 +0000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:36 -0500
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 21:28 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-05 22:07 +0100
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-06 00:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-06 02:17 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-04 19:27 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-05 18:58 +0200
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 13:17 -0400
Re: Stack Sizes Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-22 12:35 +0200
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 12:18 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 16:07 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 15:50 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-05 17:36 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 17:14 -0500
Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-05 14:48 -1000
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-05 20:49 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-03 16:32 +0000
Re: Stack Sizes Chris Curl <ccurl609@gmail.com> - 2016-10-03 13:53 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-03 17:54 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-03 23:40 -0400
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:30 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-03 21:47 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 11:22 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-04 11:44 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-04 15:53 -0400
Re: Stack Sizes Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-10-04 16:15 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-05 14:31 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 08:48 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 13:08 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:11 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 12:08 -0700
Re: Stack Sizes alex <alex@rivadpm.com> - 2016-10-06 21:47 +0100
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-06 19:05 -0400
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-06 21:57 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-06 19:21 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 00:10 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:14 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-07 02:26 -0400
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-06 23:57 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-07 08:18 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-07 10:52 -0400
Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-09 16:22 -0700
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 01:49 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:21 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-10 22:39 -0400
Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-10 12:36 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-13 13:45 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-14 01:16 -0700
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-15 20:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 02:00 -0400
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 18:38 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-16 22:27 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 21:14 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 00:35 -0400
Re: Straight Forth Re: Stack Sizes Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-10-16 23:31 -0700
Re: Straight Forth Re: Stack Sizes "Elizabeth D. Rather" <erather@forth.com> - 2016-10-16 20:36 -1000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:11 -0700
Re: Straight Forth Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-17 19:14 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 21:53 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-17 16:54 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-21 22:13 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-21 17:46 -0700
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-23 22:26 +0000
Re: Straight Forth Re: Stack Sizes JUERGEN <epldfpga@aol.com> - 2016-10-24 09:13 -0700
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-24 16:28 -0700
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-24 17:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-24 22:23 -0400
Re: Straight Forth Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-11-04 20:39 +0000
Re: Straight Forth Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-16 22:42 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-17 11:12 +0200
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 09:20 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 19:11 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 16:40 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:19 -0400
Re: Straight Forth Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-17 17:25 -0700
Re: Straight Forth Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-17 20:50 -0400
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:04 +0200
Re: Straight Forth Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-18 06:13 +0000
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-16 15:21 -0700
Re: Straight Forth Re: Stack Sizes Doug Hoffman <glidedog@gmail.com> - 2016-10-17 04:09 -0400
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-17 13:48 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 02:12 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 00:35 -0700
Re: Straight Forth Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-18 12:53 +0200
Re: Straight Forth Re: Stack Sizes hughaguilar96@gmail.com - 2016-10-18 12:12 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 16:53 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-09 08:34 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-09 16:03 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-10 03:25 -0500
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-10 10:29 -0500
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:19 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-10 14:41 +0000
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-10 20:23 +0200
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-11 05:16 -0500
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 12:54 +0000
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-12 18:27 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-12 17:06 +0000
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-12 13:01 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-12 17:07 -0400
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-13 03:18 +0200
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:26 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-12 20:30 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-13 15:52 +0000
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-13 15:05 -0700
Re: Stack Sizes Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-14 03:08 -0500
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-14 14:41 -0400
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 12:33 -0500
Re: Stack Sizes rickman <gnuarm@gmail.com> - 2016-10-08 01:12 -0400
Re: Stack Sizes Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 21:56 -0700
Re: Stack Sizes Walter Banks <walter@bytecraft.com> - 2016-10-08 07:23 -0400
Re: Stack Sizes lawrencedo99@gmail.com - 2016-10-11 22:39 -0700
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 08:21 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 09:22 +0200
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 09:35 +0200
Re: Stack Sizes jim.brakefield@ieee.org - 2016-10-07 10:51 -0700
Re: Stack Sizes Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 13:21 -0500
Re: Stack Sizes Lars Brinkhoff <lars.spam@nocrew.org> - 2016-10-07 20:40 +0200
Re: Stack Sizes albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-07 20:53 +0200
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 07:35 +0000
Re: Stack Sizes Paul Rubin <no.email@nospam.invalid> - 2016-10-07 01:09 -0700
Re: Stack Sizes anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-07 15:59 +0000
Re: Stack Sizes Bernd Paysan <bernd@net2o.de> - 2016-10-17 22:05 +0000
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-14 03:08 -0500 |
| Message-ID | <FNSdnedhSfgQD53FnZ2dnUU7-eudnZ2d@supernews.com> |
| In reply to | #51834 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > lawrencedo99@gmail.com writes: >>On Thursday, October 13, 2016 at 4:28:44 AM UTC+13, Anton Ertl wrote: >>> So how do architects decide >>> whether it is worth including a feature: They use standard benchmarks ... >> >>No, they do code profiling on common workloads. > > How do they decide what are common workloads? In my [very recent] experience, a large customer works with a silicon manufacturer and their software people to optimize their production application. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-14 14:41 -0400 |
| Message-ID | <ntr8rs$1uab$1@gioia.aioe.org> |
| In reply to | #51834 |
On 2016-10-13 11:52 AM, Anton Ertl wrote: > lawrencedo99@gmail.com writes: >> On Thursday, October 13, 2016 at 4:28:44 AM UTC+13, Anton Ertl wrote: >>> So how do architects decide >>> whether it is worth including a feature: They use standard benchmarks ... >> >> No, they do code profiling on common workloads. > > How do they decide what are common workloads? Let's see, is there a > standard for "common workloads" for general-purpose architectures on > which to evaluate performance? Yes, there is, it's the SPEC CPU > benchmarks, a set of applications that are supposed to be > representative of other workstation applications. > > And the problem in the present context is not these benchmarks > themselves, but the way they are compiled, which is not representative > of the way most applications are compiled (in particular, statically > linked). > >> Designing an architecture just to do well in benchmarks would be stupid. > > Would it? Consider this: Team A builds architecture A that is 10% > better than than architecture B on SPEC CPU benchmarks; Team B builds > architecture B which does 10% better on Team B's set of "common > workloads". As a potential customer, will you suspect that Team B > just tries to cover up their failure to perform well at SPEC by > cherry-picking some benchmarks on which B performs better? Given that > you are interested in running, say, Gforth, which is included neither > in SPEC nor in the "common workloads", which of the two architectures > would you choose? We use benchmarks largely as a test to refocus us outside the expected application area. They often (Actually very often) exercise corner cases. The metrics that we look at with great interest is the reference designs that are often created as we develop tools (and ISA's). The concept that we are creating general purpose computers for anything has largely passed. The Laptop my wife uses is very much designed to do the things she does that requires good fast video processing and most need a good video co-processor. I do a lot of simulation and a little bit of image displays. The gamers mentioned elsewhere have different computing needs. There are some application specific benchmarks for each of these area's and they help selecting a suitable personal computer. Running the benchmarks that my wife would use is unlikely to help me much in making my choice. w..
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-07 12:33 -0500 |
| Message-ID | <nt8m7u$2eo$1@dont-email.me> |
| In reply to | #51668 |
On 10/7/2016 8:18 AM, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: >> rickman <gnuarm@gmail.com> writes: >>> One of the issues in stack machines is dealing with more than a couple >>> or three stack items. I think a small offset into the stack will make >>> this work a lot better. >> >> The SPARC had a 24-register window, where each level of call got 8 local >> registers and could also see the local sets of the two higher calls. It >> seemed like a good idea at the time. I never dealt with it directly so >> I don't know what nonobvious issues it had, if any. > > The decision to go with register windows was based on a bunch of > benchmarks which seemed to indicate a performance improvement over > something more conventional. But the benchmarks weren't > representative enough, and the fixed size of the windows was > problematic because registers are left unused. In the end, register > windows are a loss: sophisticated register allocators can generate > better code which uses fewer physical registers. > > Andrew. > In the early 70's I designed and built my own CPU, it had register windows, 32 32 register windows, the purpose was for speedy interrupt handling, no registers needed saving to answer an interrupt, which made it fast, and predictable. It could be used in programming as the call and return instructions had an option to change register banks. It was handy in a few places but it was mainly an interrupt feature. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-10-08 01:12 -0400 |
| Message-ID | <nt9v6h$f1s$1@dont-email.me> |
| In reply to | #51674 |
On 10/7/2016 1:33 PM, Cecil Bayona wrote: > > > On 10/7/2016 8:18 AM, Andrew Haley wrote: >> Paul Rubin <no.email@nospam.invalid> wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> One of the issues in stack machines is dealing with more than a couple >>>> or three stack items. I think a small offset into the stack will make >>>> this work a lot better. >>> >>> The SPARC had a 24-register window, where each level of call got 8 local >>> registers and could also see the local sets of the two higher calls. It >>> seemed like a good idea at the time. I never dealt with it directly so >>> I don't know what nonobvious issues it had, if any. >> >> The decision to go with register windows was based on a bunch of >> benchmarks which seemed to indicate a performance improvement over >> something more conventional. But the benchmarks weren't >> representative enough, and the fixed size of the windows was >> problematic because registers are left unused. In the end, register >> windows are a loss: sophisticated register allocators can generate >> better code which uses fewer physical registers. >> >> Andrew. >> > > In the early 70's I designed and built my own CPU, it had register > windows, 32 32 register windows, the purpose was for speedy interrupt > handling, no registers needed saving to answer an interrupt, which made > it fast, and predictable. It could be used in programming as the call > and return instructions had an option to change register banks. It was > handy in a few places but it was mainly an interrupt feature. If there were no registers to save on a context switch, where did you save the register window pointer? Was this inherent in the interrupt you were running at the time? Where did you save the info on which interrupt you were running? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-10-07 23:05 -0400 |
| Message-ID | <20161007230503.2b35c2d3@_> |
| In reply to | #51657 |
On Fri, 7 Oct 2016 02:26:54 -0400 rickman <gnuarm@gmail.com> wrote: > On 10/7/2016 2:14 AM, Paul Rubin wrote: > > rickman <gnuarm@gmail.com> writes: > >> A register/stack hybrid by giving a limited range of access into > >> the stack for operands. > > > > This sounds like a register window architecture, e.g. SPARC. They > > were in vogue in workstation processors for a while, but then went > > out of favor, I think because of difficulties making them > > superscalar or something like that. For a small fpga softcore > > maybe that doesn't matter. > > Lol, no, I don't think not being "superscalar" matters to a MISC CPU. > Not familiar with register window, but that sounds a bit like it, but > put it on top of a stack. The idea is to do away with most of the > stack manipulations, OVER, DUP, etc. buy implementing them with small > offsets and stack pointer adjustments other than +1/0/-1. > > One of the issues in stack machines is dealing with more than a > couple or three stack items. I think a small offset into the stack > will make this work a lot better. > It would be useful if you could move the pointer from position at the top of the stack, while guaranteeing that items now above the new pointer location were not corrupted. E.g., if you wanted to swap the 3rd and 4th items, you could: 1) change data stack pointer to point to 3rd item 2) "protect" the items between new and old position, i.e., "guard" the 1st and 2nd items 3) SWAP, which would swap the 3rd and 4th items 4) restore data stack pointer 5) remove "guard" protecting 1st and 2nd items from being overwritten I noticed this type of situation come up both in Forth code and C code converted to Forth. This would make all data stack operations independent of the current stack position. I'm just not sure how to do it more effectively than moving items to the return stack. Guarding the data would be the hard part in software, I think, without needing to use to two block moves of data, which would slow this down. Swapping the stack pointer is quick and easy. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-10-07 21:56 -0700 |
| Message-ID | <b0c3636f-5a01-4f3e-be76-f14f753abbe3@googlegroups.com> |
| In reply to | #51687 |
On Friday, October 7, 2016 at 10:04:40 PM UTC-5, Rod Pemberton wrote: > On Fri, 7 Oct 2016 02:26:54 -0400 > rickman <gnuarm@gmail.com> wrote: > > > On 10/7/2016 2:14 AM, Paul Rubin wrote: > > > rickman <gnuarm@gmail.com> writes: > > > >> A register/stack hybrid by giving a limited range of access into > > >> the stack for operands. > > > > > > This sounds like a register window architecture, e.g. SPARC. They > > > were in vogue in workstation processors for a while, but then went > > > out of favor, I think because of difficulties making them > > > superscalar or something like that. For a small fpga softcore > > > maybe that doesn't matter. > > > > Lol, no, I don't think not being "superscalar" matters to a MISC CPU. > > Not familiar with register window, but that sounds a bit like it, but > > put it on top of a stack. The idea is to do away with most of the > > stack manipulations, OVER, DUP, etc. buy implementing them with small > > offsets and stack pointer adjustments other than +1/0/-1. > > > > One of the issues in stack machines is dealing with more than a > > couple or three stack items. I think a small offset into the stack > > will make this work a lot better. > > > > It would be useful if you could move the pointer from position at the > top of the stack, while guaranteeing that items now above the new > pointer location were not corrupted. E.g., if you wanted to swap the > 3rd and 4th items, you could: > > 1) change data stack pointer to point to 3rd item > 2) "protect" the items between new and old position, i.e., > "guard" the 1st and 2nd items > 3) SWAP, which would swap the 3rd and 4th items > 4) restore data stack pointer > 5) remove "guard" protecting 1st and 2nd items from being overwritten > > I noticed this type of situation come up both in Forth code and C code > converted to Forth. This would make all data stack operations > independent of the current stack position. I'm just not sure how to do > it more effectively than moving items to the return stack. Guarding > the data would be the hard part in software, I think, without needing > to use to two block moves of data, which would slow this down. Swapping > the stack pointer is quick and easy. > > > Rod Pemberton ]> 3) SWAP, which would swap the 3rd and 4th items Only way to do such a generalized SWAP in one clock cycle is to have even and odd location stack memory pairs? For an FPGA implementation, this means either two LUT RAM register files or two block RAM stack memories? Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-08 07:23 -0400 |
| Message-ID | <ntal08$1r85$1@gioia.aioe.org> |
| In reply to | #51687 |
On 2016-10-07 11:05 PM, Rod Pemberton wrote: > On Fri, 7 Oct 2016 02:26:54 -0400 rickman <gnuarm@gmail.com> wrote: > >> On 10/7/2016 2:14 AM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: > >>>> A register/stack hybrid by giving a limited range of access >>>> into the stack for operands. >>> >>> This sounds like a register window architecture, e.g. SPARC. >>> They were in vogue in workstation processors for a while, but >>> then went out of favor, I think because of difficulties making >>> them superscalar or something like that. For a small fpga >>> softcore maybe that doesn't matter. >> >> Lol, no, I don't think not being "superscalar" matters to a MISC >> CPU. Not familiar with register window, but that sounds a bit like >> it, but put it on top of a stack. The idea is to do away with most >> of the stack manipulations, OVER, DUP, etc. buy implementing them >> with small offsets and stack pointer adjustments other than >> +1/0/-1. >> >> One of the issues in stack machines is dealing with more than a >> couple or three stack items. I think a small offset into the >> stack will make this work a lot better. >> > > It would be useful if you could move the pointer from position at > the top of the stack, while guaranteeing that items now above the > new pointer location were not corrupted. E.g., if you wanted to swap > the 3rd and 4th items, you could: > > 1) change data stack pointer to point to 3rd item 2) "protect" the > items between new and old position, i.e., "guard" the 1st and 2nd > items 3) SWAP, which would swap the 3rd and 4th items 4) restore data > stack pointer 5) remove "guard" protecting 1st and 2nd items from > being overwritten > > I noticed this type of situation come up both in Forth code and C > code converted to Forth. This would make all data stack operations > independent of the current stack position. I'm just not sure how to > do it more effectively than moving items to the return stack. > Guarding the data would be the hard part in software, I think, > without needing to use to two block moves of data, which would slow > this down. Swapping the stack pointer is quick and easy. This is an accurate description of a very real problem. In both code generators and ISA projects I have worked on deal with the data stack is a problem because of fundamental assumptions. A lot of the ISA's out there make an assumption that if a stack pointer is created that looks a lot like an index register with a rich collection of math operations then everything will just work out. As your simple example points out there are really two problems. 1) There is a real need for two pointers for a stack one the simple pointer that indexes where data is pushed on and off the stack and a second that carries with it top and next operate. Combining the two as most systems do is always a compromise. 2) Operations on the stack have different ISA requirements than index register operations on Global variables. This difference starts with the role of the accumulator. The question of a primary accumulator, is it the TOP or separate AC. In your example above the AC needs to be TOP. From metrics (assuming appropriate code generation) we have shown that the TOP can always be the system AC without penalty but for stack operations an AC separate from top of stack can be expensive. Going back to your example there is the overhead of moving using whatever mechanism the register window somewhere on the stack. ISA developers have tried a lot of approaches. Stack indexing - address overhead. Pointer base addressing - set up overhead. Ivan Godard's belt to reduce offset address size offset by retaining most intermediate results. w..
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-11 22:39 -0700 |
| Message-ID | <52a00967-59c2-4cb7-94c7-3796e5c5eb05@googlegroups.com> |
| In reply to | #51687 |
On Saturday, October 8, 2016 at 4:04:40 PM UTC+13, Rod Pemberton wrote: > It would be useful if you could move the pointer from position at the > top of the stack, while guaranteeing that items now above the new > pointer location were not corrupted. Echos of the old PowerPC “red zone” concept...
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-10-07 08:21 +0200 |
| Message-ID | <86shs87k70.fsf@molnjunk.nocrew.org> |
| In reply to | #51656 |
Paul Rubin <no.email@nospam.invalid> writes: > This sounds like a register window architecture, e.g. SPARC. They > were in vogue in workstation processors for a while, but then went out > of favor Not completely. The newish Xtensa architecture has an option for register windows.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-07 09:22 +0200 |
| Message-ID | <nt7igf$gqo$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51656 |
In article <87k2dkwuqs.fsf@nightsong.com>, Paul Rubin <no.email@nospam.invalid> wrote: >rickman <gnuarm@gmail.com> writes: >> A register/stack hybrid by giving a limited range of access into the >> stack for operands. > >This sounds like a register window architecture, e.g. SPARC. They were >in vogue in workstation processors for a while, but then went out of >favor, I think because of difficulties making them superscalar or >something like that. For a small fpga softcore maybe that doesn't >matter. The most prestigious example of late of a register window is the Itanium. It is not clear to me whether thay fell prey to the success of Intel/Windows or there are legitimate technical difficulties. So much is sure that you don't hear a lot of them. I had the opportunity to lay hands on transputer and Dec Alpha hardware when they were on their way back. I'd love to try Forth on a register window machine like the Itanium. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-10-07 09:35 +0200 |
| Message-ID | <86oa2w7grn.fsf@molnjunk.nocrew.org> |
| In reply to | #51660 |
Albert van der Horst writes: > I'd love to try Forth on a register window machine like the Itanium. It shouldn't be hard get an ESP8266, but I don't know if its CPU implements the register window option. The ESP32 seems to have it.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-10-07 10:51 -0700 |
| Message-ID | <93773982-433c-4189-9b1c-f2ca2457d9f4@googlegroups.com> |
| In reply to | #51661 |
On Friday, October 7, 2016 at 2:35:57 AM UTC-5, Lars Brinkhoff wrote: > Albert van der Horst writes: > > I'd love to try Forth on a register window machine like the Itanium. > > It shouldn't be hard get an ESP8266, but I don't know if its CPU > implements the register window option. The ESP32 seems to have it. ]>The ESP32 seems to have it. FYI The Xtensa ISA reference manual shows register windows as optional. Also, via the ENTRY instruction, register windows can have 4, 8 or 12 registers as opposed to the 8 register window on SPARC.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-07 13:21 -0500 |
| Message-ID | <nt8p26$cuc$1@dont-email.me> |
| In reply to | #51661 |
That CPU family is insane, so many features, if I remember you can buy a board for under $10. I skimmed over some of the literature and it seems the whole family is designed so you can have a custom CPU made with the features and even extra instructions one wants. Any Forth available (dream on) or even a C compiler? On 10/7/2016 2:35 AM, Lars Brinkhoff wrote: > Albert van der Horst writes: >> I'd love to try Forth on a register window machine like the Itanium. > > It shouldn't be hard get an ESP8266, but I don't know if its CPU > implements the register window option. The ESP32 seems to have it. > -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-10-07 20:40 +0200 |
| Message-ID | <86eg3s6lz9.fsf@molnjunk.nocrew.org> |
| In reply to | #51676 |
Cecil Bayona <cbayona@cbayona.com> writes: > That CPU family is insane, so many features, if I remember you can buy > a board for under $10. Yes, it seems interesting! > Any Forth available (dream on) I know about three: https://github.com/niclash/forthright https://github.com/zeroflag/punyforth https://github.com/CraigLindley/ESP8266Forth > or even a C compiler? https://github.com/jcmvbkbc/gcc-xtensa
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-07 20:53 +0200 |
| Message-ID | <nt8qus$5il$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51676 |
In article <nt8p26$cuc$1@dont-email.me>, Cecil Bayona <cbayona@cbayona.com> wrote: >That CPU family is insane, so many features, if I remember you can buy a >board for under $10. I skimmed over some of the literature and it seems >the whole family is designed so you can have a custom CPU made with the >features and even extra instructions one wants. I was puzzling 5 minutes to find out what CPU family you could be talking about. Then I scolled down. Please don't top post. > >Any Forth available (dream on) or even a C compiler? > >On 10/7/2016 2:35 AM, Lars Brinkhoff wrote: >> Albert van der Horst writes: >>> I'd love to try Forth on a register window machine like the Itanium. >> >> It shouldn't be hard get an ESP8266, but I don't know if its CPU >> implements the register window option. The ESP32 seems to have it. >> > >-- >Cecil - k5nwa -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-07 07:35 +0000 |
| Message-ID | <2016Oct7.093523@mips.complang.tuwien.ac.at> |
| In reply to | #51656 |
Paul Rubin <no.email@nospam.invalid> writes:
>rickman <gnuarm@gmail.com> writes:
>This sounds like a register window architecture, e.g. SPARC. They were
>in vogue in workstation processors for a while, but then went out of
>favor, I think because of difficulties making them superscalar or
>something like that.
Their inclusion in IA-64 is counterevidence for this theory.
My guess is that it did not buy enough in the benchmarks, in
particular SPEC CPU (but I have my doubts that the benchmarks are
representative of real applications in this area).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-10-07 01:09 -0700 |
| Message-ID | <87bmywwpg1.fsf@nightsong.com> |
| In reply to | #51662 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Their inclusion in IA-64 is counterevidence for this theory. > My guess is that it did not buy enough in the benchmarks, SPARC was one of the faster processors around in its early days, but other designs got way ahead of it with comparable die sizes and processes. I have the impression that the register window scheme was the culprit one way or another. Today you can buy expensive recent SPARC chips that are still way slower than Intel, Power8, etc. I don't know how Itanic does compared to those. But I figure there's reasons nobody uses it.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-07 15:59 +0000 |
| Message-ID | <2016Oct7.175945@mips.complang.tuwien.ac.at> |
| In reply to | #51664 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Their inclusion in IA-64 is counterevidence for this theory.
>> My guess is that it did not buy enough in the benchmarks,
>
>SPARC was one of the faster processors around in its early days, but
>other designs got way ahead of it with comparable die sizes and
>processes. I have the impression that the register window scheme was
>the culprit one way or another.
And at some point the 68000 fell back and the 88000 fell back, and at
some point MIPS fell back, and at some point Alpha fell back, and at
some point Motorola's PowerPCs fell back, and they all had no register
windows. OTOH, Fujitsu's SPARC64 CPUs were doing comparatively well
AFAIK, to the point that Oracle sold them and did SPEC CPU submissions
with them (compare
<https://www.spec.org/cpu2006/results/res2011q2/cpu2006-20110328-15288.html>
and
<https://www.spec.org/cpu2006/results/res2011q2/cpu2006-20110328-15270.html>).
Intel CPUs now have ~200 or so physical registers, and accessing them
is more complicated than register window access (admittedly, they
would have to do register window access in addition to the register
renaming), yet they manage to get this to fly, so I expect that Intel
would also get register windows to fly if they put their minds to it.
I think the problem with most RISC architectures was that they were
relatively easy to develop at first, and their designers were not
prepared for dealing with the complexity that superscalar out-of-order
designs entail. So the designs were delayed, canceled, or slow.
Alpha with their VAX legacy were better prepared for that, but
apparently eventually ran out of money because of low revenue.
>I don't
>know how Itanic does compared to those. But I figure there's reasons
>nobody uses it.
IA-64 implementations have been relatively slow AFAICT; they have not
submitted results since 2010, so it's unclear how well the recent ones
do (it seems both Intel and HP only do these for the existing customer
base these days), which is a pity, because Poulson looks promising (at
least it should do quite a bit better than the earlier ones). The
IA-64 problem seems to be overall complexity and lack of commitment.
If Intel had been committed to it just as it was to IA-32 in the dark
386 times, they would have worked out how to make it fly over the
course of a few generations, but they just did minor updates of the
McKinley for a decade; of course, unlike for IA-32, there was little
software base for IA-64, and therefore little incentive to keep on
improving it.
Anyway, if anybody wants to play with IA-64, I looked around some time
ago, and you can get a second-hand Itanium II system complete with
memory for relatively little (IIRC starting at around EUR200).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2016-10-17 22:05 +0000 |
| Message-ID | <nu3huf$vjj$2@dont-email.me> |
| In reply to | #51671 |
Am Fri, 07 Oct 2016 15:59:45 +0000 schrieb Anton Ertl: > Intel CPUs now have ~200 or so physical registers, and accessing them is > more complicated than register window access (admittedly, they would > have to do register window access in addition to the register renaming), > yet they manage to get this to fly, so I expect that Intel would also > get register windows to fly if they put their minds to it. The usual way to do this is to have a handful of "hot" fast-path registers, which live in the bypass logic (as many as you can schedule operations per cycle), and can be accessed quickly (actually, they are the inputs of the ALUs and other units), and 200 more registers which take longer to access. That is completely orthogonal to any register renaming or register window scheme. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.forth
csiph-web