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 | 20 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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-10-18 12:12 -0700 |
| Subject | Re: Straight Forth Re: Stack Sizes |
| Message-ID | <d7ae8061-11de-49c4-9720-6bf6c7328786@googlegroups.com> |
| In reply to | #51998 |
On Tuesday, October 18, 2016 at 3:44:11 AM UTC-7, Albert van der Horst wrote: > In article <e5f2267c-b298-4555-9f71-68a69ff68cfd@googlegroups.com>, > <hughaguilar96@gmail.com> wrote: > >On Monday, October 17, 2016 at 5:03:21 PM UTC-7, Albert van der Horst wrote= > <SNIP> > >> > > >> I hate string stacks. They are a too heavy tool for every day use, > >> but when the heat is on ... > >> For the Pascal compiler I'm working on they just don't cut it, and > >> I'll be using strings that are ALLOCATE d (and have a SIZE). > >> String stack fall between the wall and the ship as the Dutch saying goes. > > > >The clever part of my string-stack.4th is that I don't ALLOCATE every time = > >that I make a duplicate on the string-stack (with DUP$ or OVER$ etc.). I ha= > >ve "unique" and "derivative" strings. For example,=20 > >DUP$ index length MID$=20 > >doesn't ALLOCATE to make a new string --- it just makes a derivative, meani= > >ng a reference to an existing string. I've already described this elsewhere= > > so I won't go into the details here. The point though, is that ALLOCATE an= > >d FREE are typically the big time sinks --- my string-stack.4th was designe= > >d to minimize how often these are called --- the actual work being done on = > >the strings is not very time consuming usually. > > <SNIP> > > Using ALLOCATE this is a sophisticated stringhandling mechanism. > Your strings are not on a stack, they can be randomly deleted and > allocated. > You shouldn't call it a string stack, which associates it with > restricted tools that have been published. Of course my strings are on a stack. I have DUP$ SWAP$ OVER$ etc.. The clever part, as I said, was that with my "unique" and "derivative" strings I minimize the calls to ALLOCATE and FREE as much as possible. It functions the same however, as if every duplicated string were ALLOCATED and copied, so the user doesn't have to concern himself with whether particular strings are uniques or derivatives. This was my own invention --- I've never heard of anybody else doing anything similar. My string-stack.4th is discussed here: https://groups.google.com/forum/#!searchin/comp.lang.forth/string$20stack$204th%7Csort:relevance/comp.lang.forth/CYR7FhjYMkg/e37LkXifBQAJ So far, only one person has examined string-stack.4th. This person wasn't Albert v.d.Horst --- as ususal, he is expressing opinions on a subject that he knows nothing about --- I don't actually know what the terms "heavy tool," "randomly deleted," etc. mean; I don't know what he is talking about. Nobody will ever use string-stack.4th because Elizabeth Rather has made it very clear that the use of general-purpose data-structures is not allowed --- I'm treating strings as a general-purpose data-structure --- my string-stack.4th is intended to be useful in any program that involves text handling.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-07 16:53 +0000 |
| Message-ID | <2016Oct7.185348@mips.complang.tuwien.ac.at> |
| In reply to | #51668 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> 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.
Not quite. When shifting the window, it is shifted by 16 registers.
You typically shift in one direction on call, and in the other on
return. So the callee (B) sees 8 of the registers that the caller (A)
saw, and the caller uses these to pass parameters; if the B wants to
make a call itself, it puts the parameters in the 8 registers at the
other end of the window; the 8 registers in between can only be used
for local data. The remaining 8 (or 7?) registers were not managed in
Windows.
>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
Representative of what? They were not representative of the SPEC CPU
benchmarks as typically used; but the SPEC CPU benchmarks as typically
used are not at all representative of most applications, in particular
wrt call overhead. So it might be that the benchmarks that showed
register windows to be a win are more representative of applications
than those that didn't.
>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.
Except that these sophisticated register allocators never materialized
in the real world. When I compile Gforth on MIPS or Alpha and use
more than one register for stack items, gcc spills some VM registers;
now gcc's register allocation is ancient, but last I heard, someone
tried replacing it with something more sophisticated, and found that
the result produced slower code.
Ok, Gforth may be a special case, so let's look at other stuff:
Applications that are dynamically linked (SPEC CPU benchmarks usually
are statically linked for performance) and use polymorphic calls (no
interprocedural register allocation for that, but fortunately rare in
SPEC CPU); static compiler sophistication will not help for these
cases.
The IA-64 designers had too much rather than too little faith in
sophisticated compilers, yet they included the register stack
(something like register windows, but without fixed shifts, avoiding
the waste "problem"); so they certainly did not buy the "sophisticated
register allocators can generate better code" argument.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-09 08:34 -0500 |
| Message-ID | <veGdnSHzHOHw2mfKnZ2dnUU7-f3NnZ2d@supernews.com> |
| In reply to | #51673 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Paul Rubin <no.email@nospam.invalid> wrote: >>> 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. > > Not quite. When shifting the window, it is shifted by 16 registers. > You typically shift in one direction on call, and in the other on > return. So the callee (B) sees 8 of the registers that the caller (A) > saw, and the caller uses these to pass parameters; if the B wants to > make a call itself, it puts the parameters in the 8 registers at the > other end of the window; the 8 registers in between can only be used > for local data. The remaining 8 (or 7?) registers were not managed in > Windows. > >>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 > > Representative of what? AIUI, of much of the real-world code which is run on SPARC processors. > They were not representative of the SPEC CPU benchmarks as typically > used; but the SPEC CPU benchmarks as typically used are not at all > representative of most applications, in particular wrt call > overhead. So it might be that the benchmarks that showed register > windows to be a win are more representative of applications than > those that didn't. :-) >>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. > > Except that these sophisticated register allocators never > materialized in the real world. I guess that depends on whether your glass is half empty or half full. There's no getting around register allocation being NP-complete, but IME approximate algorithms run in reasonable time on reasonably small programs. With some notable exceptions, of course. > When I compile Gforth on MIPS or Alpha and use more than one > register for stack items, gcc spills some VM registers; now gcc's > register allocation is ancient, but last I heard, someone tried > replacing it with something more sophisticated, and found that the > result produced slower code. That was some time ago. GCC's old register allocator has now successfully been replaced. > Ok, Gforth may be a special case, Probably, for reasons discussed here before. > so let's look at other stuff: Applications that are dynamically > linked (SPEC CPU benchmarks usually are statically linked for > performance) and use polymorphic calls (no interprocedural register > allocation for that, but fortunately rare in SPEC CPU); static > compiler sophistication will not help for these cases. Well, sure: an optimizing compiler can't optimize beyond its "optimization horizon": the amount of code that it can see. That's obvious, surely. You can't optimize what you can't see. > The IA-64 designers had too much rather than too little faith in > sophisticated compilers, yet they included the register stack > (something like register windows, but without fixed shifts, avoiding > the waste "problem"); so they certainly did not buy the "sophisticated > register allocators can generate better code" argument. The register stack isn't on the face of it such a terrible idea, but it's certainly questionable whether it's the best way to use the silicon. But the IA-64 does not, as you note, have fixed-size windows, which are the real Achilles' heel of the SPARC. And the reason that architecture hasn't much been imitated. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-09 16:03 +0000 |
| Message-ID | <2016Oct9.180314@mips.complang.tuwien.ac.at> |
| In reply to | #51724 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Paul Rubin <no.email@nospam.invalid> wrote:
>>>> 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.
>>
>> Not quite. When shifting the window, it is shifted by 16 registers.
>> You typically shift in one direction on call, and in the other on
>> return. So the callee (B) sees 8 of the registers that the caller (A)
>> saw, and the caller uses these to pass parameters; if the B wants to
>> make a call itself, it puts the parameters in the 8 registers at the
>> other end of the window; the 8 registers in between can only be used
>> for local data. The remaining 8 (or 7?) registers were not managed in
>> Windows.
>>
>>>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
>>
>> Representative of what?
>
>AIUI, of much of the real-world code which is run on SPARC processors.
Do you have any evidence for this claim?
>>>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.
>>
>> Except that these sophisticated register allocators never
>> materialized in the real world.
>
>I guess that depends on whether your glass is half empty or half full.
>There's no getting around register allocation being NP-complete, but
>IME approximate algorithms run in reasonable time on reasonably small
>programs.
Sure, but that does nothing to address the issues that register
windows address. A function that calls another function and has, say,
6 registers live across the call, needs to save 6 registers and
restore 6 registers somewhere (either save calle-saved registers on
entry and exit, or save caller-saved registers around the call).
Register Windows reduce that overhead. In theory, one can use
interprocedural register allocation to reduce these overheads. In
practice, one does not do that (except when compiling SPEC CPU
benchmarks).
>GCC's old register allocator has now
>successfully been replaced.
Since which version?
>> so let's look at other stuff: Applications that are dynamically
>> linked (SPEC CPU benchmarks usually are statically linked for
>> performance) and use polymorphic calls (no interprocedural register
>> allocation for that, but fortunately rare in SPEC CPU); static
>> compiler sophistication will not help for these cases.
>
>Well, sure: an optimizing compiler can't optimize beyond its
>"optimization horizon": the amount of code that it can see. That's
>obvious, surely. You can't optimize what you can't see.
But register windows work even for such calls.
>> The IA-64 designers had too much rather than too little faith in
>> sophisticated compilers, yet they included the register stack
>> (something like register windows, but without fixed shifts, avoiding
>> the waste "problem"); so they certainly did not buy the "sophisticated
>> register allocators can generate better code" argument.
>
>The register stack isn't on the face of it such a terrible idea, but
>it's certainly questionable whether it's the best way to use the
>silicon. But the IA-64 does not, as you note, have fixed-size
>windows, which are the real Achilles' heel of the SPARC.
I doubt that it's the Achilles' heel. Sure, variable shifts would
have made better use of the physical registers, but as long as the
number of overflows/underflows is small, that makes little difference.
And the number of physical registers was selected such that the number
of overflows was small in practice.
The Achilles' heel of SPARC were slow implementations.
>And the
>reason that architecture hasn't much been imitated.
I think the paper that claimed that interprocedural register
allocation makes register windows unnecessary played a big role.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-10 03:25 -0500 |
| Message-ID | <G5Odnb4Fh_UJzWbKnZ2dnUU7-W_NnZ2d@supernews.com> |
| In reply to | #51730 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>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 >>> >>> Representative of what? >> >>AIUI, of much of the real-world code which is run on SPARC processors. > > Do you have any evidence for this claim? No. >>>>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. >>> >>> Except that these sophisticated register allocators never >>> materialized in the real world. >> >>I guess that depends on whether your glass is half empty or half full. >>There's no getting around register allocation being NP-complete, but >>IME approximate algorithms run in reasonable time on reasonably small >>programs. > > Sure, but that does nothing to address the issues that register > windows address. A function that calls another function and has, say, > 6 registers live across the call, needs to save 6 registers and > restore 6 registers somewhere (either save calle-saved registers on > entry and exit, or save caller-saved registers around the call). > Register Windows reduce that overhead. In theory, one can use > interprocedural register allocation to reduce these overheads. Sure, but it's completely not free with regster windows either. Of course if every call fits neatly in the register window that's a win, but if they don't that's a loss. > In practice, one does not do that (except when compiling SPEC CPU > benchmarks). > >>GCC's old register allocator has now >>successfully been replaced. > > Since which version? I can't remember, and I don't have time to look it up right now. >>> so let's look at other stuff: Applications that are dynamically >>> linked (SPEC CPU benchmarks usually are statically linked for >>> performance) and use polymorphic calls (no interprocedural register >>> allocation for that, but fortunately rare in SPEC CPU); static >>> compiler sophistication will not help for these cases. >> >>Well, sure: an optimizing compiler can't optimize beyond its >>"optimization horizon": the amount of code that it can see. That's >>obvious, surely. You can't optimize what you can't see. > > But register windows work even for such calls. Sure, up to their intrinsic limitations caused by the fixed-size windows. >>The register stack isn't on the face of it such a terrible idea, but >>it's certainly questionable whether it's the best way to use the >>silicon. But the IA-64 does not, as you note, have fixed-size >>windows, which are the real Achilles' heel of the SPARC. > > I doubt that it's the Achilles' heel. Sure, variable shifts would > have made better use of the physical registers, but as long as the > number of overflows/underflows is small, that makes little difference. Indeed, but that's the big assumption: everything fits nicely in the available register sets. When that happens, SPARC is fantastic: no spills and fills, super-fast calls, etc. Even with somewhat inferior manufacturing technology, if register windows are a substantial architectural advantage they should have won, but didn't. > And the number of physical registers was selected such that the > number of overflows was small in practice. That's true iff you're prepared to dedicate a lot of silicon to register sets rather than something else. It's not free. > The Achilles' heel of SPARC were slow implementations. That too. In particular, the TI Viking was a profound disappointment and came at a time when SPARC was under real threat from Intel et al. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-10-10 10:29 -0500 |
| Message-ID | <ntgc3u$5t9$1@dont-email.me> |
| In reply to | #51737 |
On 10/10/2016 3:25 AM, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>> 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 >>>> >>>> Representative of what? >>> >>> AIUI, of much of the real-world code which is run on SPARC processors. >> >> Do you have any evidence for this claim? > > No. > >>>>> 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. >>>> >>>> Except that these sophisticated register allocators never >>>> materialized in the real world. >>> >>> I guess that depends on whether your glass is half empty or half full. >>> There's no getting around register allocation being NP-complete, but >>> IME approximate algorithms run in reasonable time on reasonably small >>> programs. >> >> Sure, but that does nothing to address the issues that register >> windows address. A function that calls another function and has, say, >> 6 registers live across the call, needs to save 6 registers and >> restore 6 registers somewhere (either save calle-saved registers on >> entry and exit, or save caller-saved registers around the call). >> Register Windows reduce that overhead. In theory, one can use >> interprocedural register allocation to reduce these overheads. > > Sure, but it's completely not free with regster windows either. Of > course if every call fits neatly in the register window that's a win, > but if they don't that's a loss. > >> In practice, one does not do that (except when compiling SPEC CPU >> benchmarks). >> >>> GCC's old register allocator has now >>> successfully been replaced. >> >> Since which version? > > I can't remember, and I don't have time to look it up right now. > >>>> so let's look at other stuff: Applications that are dynamically >>>> linked (SPEC CPU benchmarks usually are statically linked for >>>> performance) and use polymorphic calls (no interprocedural register >>>> allocation for that, but fortunately rare in SPEC CPU); static >>>> compiler sophistication will not help for these cases. >>> >>> Well, sure: an optimizing compiler can't optimize beyond its >>> "optimization horizon": the amount of code that it can see. That's >>> obvious, surely. You can't optimize what you can't see. >> >> But register windows work even for such calls. > > Sure, up to their intrinsic limitations caused by the fixed-size > windows. > >>> The register stack isn't on the face of it such a terrible idea, but >>> it's certainly questionable whether it's the best way to use the >>> silicon. But the IA-64 does not, as you note, have fixed-size >>> windows, which are the real Achilles' heel of the SPARC. >> >> I doubt that it's the Achilles' heel. Sure, variable shifts would >> have made better use of the physical registers, but as long as the >> number of overflows/underflows is small, that makes little difference. > > Indeed, but that's the big assumption: everything fits nicely in the > available register sets. When that happens, SPARC is fantastic: no > spills and fills, super-fast calls, etc. Even with somewhat inferior > manufacturing technology, if register windows are a substantial > architectural advantage they should have won, but didn't. > >> And the number of physical registers was selected such that the >> number of overflows was small in practice. > > That's true iff you're prepared to dedicate a lot of silicon to > register sets rather than something else. It's not free. > >> The Achilles' heel of SPARC were slow implementations. > > That too. In particular, the TI Viking was a profound disappointment > and came at a time when SPARC was under real threat from Intel et al. > > Andrew. > I bought a Spark Machine a long time ago on eBay and was disappointed by it's performance, somehow I expected better, it was a CPU from the early 90's, so I did not used it much and got rid of it. I did not program it in any fashion, and installed one of the BSD Linux flavors on it, at the time I considered it a waste of money and time. At that time an old Apple Power PC just blew it away also running BSD Linux. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-11 05:19 -0500 |
| Message-ID | <t-6dnaF6tvMAIWHKnZ2dnUU7-R2dnZ2d@supernews.com> |
| In reply to | #51741 |
Cecil Bayona <cbayona@cbayona.com> wrote: > On 10/10/2016 3:25 AM, Andrew Haley wrote: >> the TI Viking was a profound disappointment >> and came at a time when SPARC was under real threat from Intel et al. >> > I bought a Spark Machine a long time ago on eBay and was disappointed by > it's performance, somehow I expected better, it was a CPU from the early > 90's, so I did not used it much and got rid of it. I did not program it > in any fashion, and installed one of the BSD Linux flavors on it, at the > time I considered it a waste of money and time. Mmm. Yep, early 90s, that might well have been the Viking. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-10 14:41 +0000 |
| Message-ID | <2016Oct10.164120@mips.complang.tuwien.ac.at> |
| In reply to | #51737 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>I guess that depends on whether your glass is half empty or half full.
>>>There's no getting around register allocation being NP-complete, but
>>>IME approximate algorithms run in reasonable time on reasonably small
>>>programs.
>>
>> Sure, but that does nothing to address the issues that register
>> windows address. A function that calls another function and has, say,
>> 6 registers live across the call, needs to save 6 registers and
>> restore 6 registers somewhere (either save calle-saved registers on
>> entry and exit, or save caller-saved registers around the call).
>> Register Windows reduce that overhead. In theory, one can use
>> interprocedural register allocation to reduce these overheads.
>
>Sure, but it's completely not free with regster windows either. Of
>course if every call fits neatly in the register window that's a win,
>but if they don't that's a loss.
If a function needs more registers, it's certainly not worse off then
if the machine has no register windows: When it calls another
function, it shifts the window before the call and shifts it back
after, and presto, 16 registers are saved that would have required 16
stores before the call and 16 loads after; apart from that, the
register allocator has to spill registers just as it would without
register windows; the register windows certainly are a win here.
>>>Well, sure: an optimizing compiler can't optimize beyond its
>>>"optimization horizon": the amount of code that it can see. That's
>>>obvious, surely. You can't optimize what you can't see.
>>
>> But register windows work even for such calls.
>
>Sure, up to their intrinsic limitations caused by the fixed-size
>windows.
What do you have in mind?
>>>The register stack isn't on the face of it such a terrible idea, but
>>>it's certainly questionable whether it's the best way to use the
>>>silicon. But the IA-64 does not, as you note, have fixed-size
>>>windows, which are the real Achilles' heel of the SPARC.
>>
>> I doubt that it's the Achilles' heel. Sure, variable shifts would
>> have made better use of the physical registers, but as long as the
>> number of overflows/underflows is small, that makes little difference.
>
>Indeed, but that's the big assumption
Not at all, because the physical register size can be (and has been)
chosen such that overflows/underflows are rare.
Apart from that, if the fixed shift had been such a big problem, they
could have added variable shifts in later revisions of the
architecture (in particular in the move to 64 bits), but they chose
not to; so apparently it was not a big problem, much less an Achilles'
heel.
>Even with somewhat inferior
>manufacturing technology, if register windows are a substantial
>architectural advantage they should have won, but didn't.
Superior computer architecture always wins? Maybe on another world.
In this world, architectures with lots of software win.
Anyway, back to register windows:
Are they a substantial advantage for statically-linked SPEC CPU
benchmarks? Obviously not, otherwise more architectures would have
adopted them.
Are they a small advantage for real-world applications (dynamically
linked, with polymorphic calls)? I think so, and apparently the IA-64
architects thought so, too.
Do they justify the additional silicon? If it was a justifiable use
of silicon in 1986, it certainly is justfifiable now.
Do they justify the additional design complexity (with possible
knock-on effects on clock rate and time-to-market). The SPARC,
AMD29K, and IA-64 architects thought so, the others didn't. It's
probably not a clear-cut issue.
>> And the number of physical registers was selected such that the
>> number of overflows was small in practice.
>
>That's true iff you're prepared to dedicate a lot of silicon to
>register sets rather than something else. It's not free.
Somehow the CPU people ran out of things that they need silicon for
some years ago, so now they give us more than one core per CPU chip.
Interestingly, SPARC implementations are pretty far along on the
multi-core game: SPARC64 X (2012) has 16 cores (with 2 threads each)
on a chip, i.e., 32 instances of the register set; actually, already
the UntraSPARC T1 from 2005 has 8 cores with 4 threads each, again
needing 32 instances of the register set, and the SPARC T3 and T5 have
16 cores with 8 threads each, for 128 instances of the register set.
Would they have gone for more cores and more threads if they did not
have such big register sets? Maybe, but no other server CPUs with
more threads come to my mind, so probably not.
If register windows were really as much as a problem you make them out
to be, they could have been obsoleted over time: First, let compilers
produce code without window shifts, then reduce the number of physical
registers to the allowed minimum, and eventually remove register
windows support, especially in the 32-bit to 64-bit transition; look
at what ARM did with shifts and conditional instructions in the move
to 64 bits (or AMD with segments in the move to 64 bits).
- 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-10-10 20:23 +0200 |
| Message-ID | <86int05aie.fsf@molnjunk.nocrew.org> |
| In reply to | #51742 |
Anton Ertl wrote: > Do [register windows] justify the additional design complexity (with > possible knock-on effects on clock rate and time-to-market). The > SPARC, AMD29K, and IA-64 architects thought so, the others didn't. Also the Xtensa architecture, which can shift its 16-register window by 4, 8, or 12. Tensilica was founded in 1997.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-11 05:16 -0500 |
| Message-ID | <t-6dnaZ6tvNyJmHKnZ2dnUU7-R3NnZ2d@supernews.com> |
| In reply to | #51742 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>I guess that depends on whether your glass is half empty or half full. >>>>There's no getting around register allocation being NP-complete, but >>>>IME approximate algorithms run in reasonable time on reasonably small >>>>programs. >>> >>> Sure, but that does nothing to address the issues that register >>> windows address. A function that calls another function and has, say, >>> 6 registers live across the call, needs to save 6 registers and >>> restore 6 registers somewhere (either save calle-saved registers on >>> entry and exit, or save caller-saved registers around the call). >>> Register Windows reduce that overhead. In theory, one can use >>> interprocedural register allocation to reduce these overheads. >> >>Sure, but it's completely not free with regster windows either. Of >>course if every call fits neatly in the register window that's a win, >>but if they don't that's a loss. > > If a function needs more registers, it's certainly not worse off then > if the machine has no register windows: No, obviously not. >>> Sure, variable shifts would have made better use of the physical >>> registers, but as long as the number of overflows/underflows is >>> small, that makes little difference. >> >>Indeed, but that's the big assumption > > Not at all, because the physical register size can be (and has been) > chosen such that overflows/underflows are rare. There is always a tradeoff: the size of a register file has a strong effect on its access time, area and, obviously, power. As I've said, the question isn't whether register windows can be nice to have sometimes but whether they're worth what they cost. If having just 32 registers means that you can reduce power and reduce cycle time, then the tradeoff may not be worth it. > Are they a substantial advantage for statically-linked SPEC CPU > benchmarks? Obviously not, otherwise more architectures would have > adopted them. Umm, what? You're claiming that the adoption of architectural features is solely determined by statically-linked SPEC CPU benchmarks? > Do they justify the additional silicon? If it was a justifiable use > of silicon in 1986, it certainly is justfifiable now. That's a big "if", and see above. > Do they justify the additional design complexity (with possible > knock-on effects on clock rate and time-to-market). The SPARC, > AMD29K, and IA-64 architects thought so, the others didn't. It's > probably not a clear-cut issue. OK, so it's probably not a clear-cut issue. > Somehow the CPU people ran out of things that they need silicon for > some years ago, so now they give us more than one core per CPU chip. We're skipping ahead 30ish years, and trade-offs are very different. Multiple physical register sets in out-of-order processors shadow the architectural registers, and bypass logic can avoid delays caused by spills and fills. This is a completely different game, and therefore a completely different argument. To my mind, register windows are much like delay slots: seemed like a good idea at the time. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-12 12:54 +0000 |
| Message-ID | <2016Oct12.145412@mips.complang.tuwien.ac.at> |
| In reply to | #51761 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Not at all, because the physical register size can be (and has been)
>> chosen such that overflows/underflows are rare.
>
>There is always a tradeoff: the size of a register file has a strong
>effect on its access time, area and, obviously, power. As I've said,
>the question isn't whether register windows can be nice to have
>sometimes but whether they're worth what they cost. If having just 32
>registers means that you can reduce power and reduce cycle time, then
>the tradeoff may not be worth it.
Comparing the SPARC M7 (4.13GHz) to other CPUs (Intel 4GHz; Power9
4GHz), it does not look like register windowing prevents low cycle
times.
Concerning power, if you don't have register windowing, you may have
cheaper register access (except that you have to deal with ~200
physical registers in an Intel CPU anyway), but you have more memory
accesses, and a memory access is substantially more power-hungry than
a register access (address translation overhead with it's TLB access
(typically fully associative, i.e., lot's of active transistors), plus
cache tags access (e.g. 8-way associative, again lots of active
transitors), plus the cache access itself (more memory than a register
file, so more energy)), so register windowing might even save power.
Moreover, if 32-register files really had significant access time and
power advantages, you could actually build the thing as a 32-register
file with small extras: the window shift actually moves the data
around to a place that is not involved in the ordinary register access
and therefore does not have any access time or power effects on that;
for this kind of implementation the fixed shift helps a lot.
>> Are they a substantial advantage for statically-linked SPEC CPU
>> benchmarks? Obviously not, otherwise more architectures would have
>> adopted them.
>
>Umm, what? You're claiming that the adoption of architectural
>features is solely determined by statically-linked SPEC CPU
>benchmarks?
For special-purpose features like AES instructions, probably not, but
for general-purpose features like register windowing vs. not, pretty
much, yes:
Look at what they do in marketing: If a CPU works well on standard
benchmarks, these benchmarks get touted (if not, then the real
marketing expertise comes to the fore). So how do architects decide
whether it is worth including a feature: They use standard benchmarks,
because that's what the marketing people then use. For an
architectural feature, they of course use benchmarks that are
available in source (binary benchmarks like 3Dmark will never use a
new architectural feature, and therefore cannot be used for evaluating
a new (for the architecture) architectural feature). Now there are
benchmarks like TPC-C, which are also much reported, but they require
quite a lot of setup and environment and are too unwieldy for
evaluating architectural features. As a result, one mostly sees SPEC
CPU in ISCA proceedings, and given that both academia and marketing
looks for these results, why should architects optimize for something
else?
And of course, since SPEC CPU submissions are statically linked,
that's what they do in their architecture evaluation, too. Why would
you build the SPEC benchmark for your architectural evaluation in a
different way than that which you eventually use for benchmark
submission, marketing, and paper publishing.
>> Somehow the CPU people ran out of things that they need silicon for
>> some years ago, so now they give us more than one core per CPU chip.
>
>We're skipping ahead 30ish years,
A little less than 20: UntraSPARC IV 2004, Pentium D 2005, Athlon 64
X2 2005, ...
>Multiple physical register sets in out-of-order processors shadow the
>architectural registers, and bypass logic can avoid delays caused by
>spills and fills.
I have no idea what you mean with "shadow" here, and "bypass logic"
also does not seem to have its conventional meaning (already the
earliest RISCs had bypasses from the outputs of functional units to
the inputs, in order to achieve single-cycle execution of dependent
ALU instructions).
As for the idea that spills and fills become free, because
out-of-order execution schedules them in otherwise unused execution
slots, that's a cute idea, but storing and loading a value also has a
latency effect for this value, and can also affect the latency of
other memory accesses (potential aliasing is mostly avoided by alias
prediction, but you still have to prepare for the possibility of a
misprediction, and that costs, too, even if the prediction is
correct); the high effectiveness of register allocation is evidence
against this idea. In the end it is another variation of the fairy
tale about memory/cache accesses being as fast as register accesses.
>To my mind, register windows are
>much like delay slots: seemed like a good idea at the time.
No general-purpose architecture after 1988 introduced delay slots, and
instruction sets that included both (e.g., 88k) deprecated the delay
slots soon after. And even MIPS, which only had delay slots at the
start, has introduced branches without delay slots in MIPS32/64
Release 6 (load delay slots already stopped being required with MIPS
III in 1992). Essentially, delay slots only fit a single
implementation style (e.g., single-issue five-stage pipeline in the
case of MIPS delay slots), and are therefore not a good idea in a
general-purpose architecture.
Register windowing/stacking has been included in IA-64 from the late
1990s as well as SPARC and AMD29K (from the mid-1980s), and none of
them has deprecated this feature yet, although that would have been
dead easy in the transition to 64-bits on the SPARC. This feature is
not linked to a particular implementation style.
In a word: No. Register windowing is unlike delay slots.
- 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-12 18:27 +0200 |
| Message-ID | <ntlo8o$som$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51795 |
In article <2016Oct12.145412@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: <SNIP> > >Register windowing/stacking has been included in IA-64 from the late >1990s as well as SPARC and AMD29K (from the mid-1980s), and none of >them has deprecated this feature yet, although that would have been >dead easy in the transition to 64-bits on the SPARC. This feature is >not linked to a particular implementation style. > >In a word: No. Register windowing is unlike delay slots. Talking about IA-64 I was not able to find you EURO 200 second hand servers. It is more like EURO 2000. Some better hints? > >- anton -- 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-12 17:06 +0000 |
| Message-ID | <2016Oct12.190622@mips.complang.tuwien.ac.at> |
| In reply to | #51797 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Talking about IA-64 I was not able to find you EURO 200
>second hand servers. It is more like EURO 2000.
>Some better hints?
<http://www.ebay.de/sch/i.html?_odkw=Itaanium&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR3.TRC1.A0.H0.XItanium.TRS0&_nkw=Itanium&_sacat=0>
E.g., the first one, for EUR 125 (+EUR 20 for shipping, plus disk):
<http://www.ebay.de/itm/HP-Bladeserver-BL860c-G1-2-x-Itanium-II-9015-16-GB-ohne-Festplatten-/152263511759?hash=item23739ccecf:g:OFQAAOSw9mFWI5Bp>
Or EUR 105+shipping+disk:
<http://www.ebay.de/itm/HP-Bladeserver-BL860c-G1-1-x-Itanium-II-9015-24-GB-ohne-Festplatten-/391580796032?hash=item5b2c08c480:g:OFQAAOSw9mFWI5Bp>
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-10-12 13:01 -0500 |
| Message-ID | <wsmdnY0TXcYd52PKnZ2dnUU7-VvNnZ2d@supernews.com> |
| In reply to | #51795 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Not at all, because the physical register size can be (and has been) >>> chosen such that overflows/underflows are rare. >> >>There is always a tradeoff: the size of a register file has a strong >>effect on its access time, area and, obviously, power. As I've said, >>the question isn't whether register windows can be nice to have >>sometimes but whether they're worth what they cost. If having just 32 >>registers means that you can reduce power and reduce cycle time, then >>the tradeoff may not be worth it. > > Comparing the SPARC M7 (4.13GHz) to other CPUs (Intel 4GHz; Power9 > 4GHz), it does not look like register windowing prevents low cycle > times. > > Concerning power, if you don't have register windowing, you may have > cheaper register access (except that you have to deal with ~200 > physical registers in an Intel CPU anyway), but you have more memory > accesses, and a memory access is substantially more power-hungry than > a register access (address translation overhead with it's TLB access > (typically fully associative, i.e., lot's of active transistors), plus > cache tags access (e.g. 8-way associative, again lots of active > transitors), plus the cache access itself (more memory than a register > file, so more energy)), so register windowing might even save power. True enough. That's not entirely impossible if spills and fills and the associated delays are a very large part of the computation. > Moreover, if 32-register files really had significant access time and > power advantages, There isn't much doubt that the size of a register file has significant effects. Whether that's enough to overwhelm all of the other variables is another matter. > you could actually build the thing as a 32-register file with small > extras: the window shift actually moves the data around to a place > that is not involved in the ordinary register access and therefore > does not have any access time or power effects on that; for this > kind of implementation the fixed shift helps a lot. I don't know that's its ever been done that way, but it's not impossible. >>> Are they a substantial advantage for statically-linked SPEC CPU >>> benchmarks? Obviously not, otherwise more architectures would have >>> adopted them. >> >>Umm, what? You're claiming that the adoption of architectural >>features is solely determined by statically-linked SPEC CPU >>benchmarks? > > For special-purpose features like AES instructions, probably not, but > for general-purpose features like register windowing vs. not, pretty > much, yes: > > Look at what they do in marketing: If a CPU works well on standard > benchmarks, these benchmarks get touted (if not, then the real > marketing expertise comes to the fore). So how do architects decide > whether it is worth including a feature: They use standard benchmarks, > because that's what the marketing people then use. Believe what you will. That seems to me like an extremely cynical take on how things are done, and it doesn't match the attitude of the processor architects I know. Of course you have to have benchmarks to evaluate designs, but the notion that architects deliberately choose unrepresentative benchmarks in order to make marketing people happy I find rather far-fetched. >>To my mind, register windows are much like delay slots: seemed like >>a good idea at the time. > > No general-purpose architecture after 1988 introduced delay slots, and > instruction sets that included both (e.g., 88k) deprecated the delay > slots soon after. No general-purpose architecture after 1988 introduced (SPARC-style) register windows either. > Register windowing/stacking has been included in IA-64 from the late > 1990s as well as SPARC and AMD29K (from the mid-1980s), and none of > them has deprecated this feature yet, although that would have been > dead easy in the transition to 64-bits on the SPARC. AMD92K and SPARC were contemporaries, and IA-64's register windows are not like those of SPARC. Register windowing, as done in SPARC, is more or less a 1980s fashion. I don't think we'll see it again, but stranger things have happened. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-12 17:07 -0400 |
| Message-ID | <ntm8mk$1n2$1@gioia.aioe.org> |
| In reply to | #51804 |
On 2016-10-12 2:01 PM, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> >> Look at what they do in marketing: If a CPU works well on standard >> benchmarks, these benchmarks get touted (if not, then the real >> marketing expertise comes to the fore). So how do architects >> decide whether it is worth including a feature: They use standard >> benchmarks, because that's what the marketing people then use. > > Believe what you will. That seems to me like an extremely cynical > take on how things are done, and it doesn't match the attitude of the > processor architects I know. Of course you have to have benchmarks > to evaluate designs, but the notion that architects deliberately > choose unrepresentative benchmarks in order to make marketing people > happy I find rather far-fetched. To add a single data point to this thread. I have worked on quite a few ISA developments all in the embedded systems area. The appearance of selective benchmarks is likely the result of targeting an ISA to a specific application area than selectively promoting a general purpose processor that doesn't do well in some applications (or benchmarks). My experience is that ISA designs and supporting tools have very specific goals by the developers even if those goals are sometimes not well articulated. I have never been involved in an ISA development that wasn't committed to maximizing the intended application performance. In the developments I have been part of benchmarks are often run but the biggest feedback is application reference designs often developed at the same time. The reference design metrics early in an ISA development significantly change how an application area is understood. At a minimum it identifies data and control flow bottlenecks and focuses on potential instruction set changes. w..
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-10-13 03:18 +0200 |
| Message-ID | <ntmncd$ua4$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51812 |
In article <ntm8mk$1n2$1@gioia.aioe.org>, Walter Banks <walter@bytecraft.com> wrote: >On 2016-10-12 2:01 PM, Andrew Haley wrote: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>> >>> Look at what they do in marketing: If a CPU works well on standard >>> benchmarks, these benchmarks get touted (if not, then the real >>> marketing expertise comes to the fore). So how do architects >>> decide whether it is worth including a feature: They use standard >>> benchmarks, because that's what the marketing people then use. >> >> Believe what you will. That seems to me like an extremely cynical >> take on how things are done, and it doesn't match the attitude of the >> processor architects I know. Of course you have to have benchmarks >> to evaluate designs, but the notion that architects deliberately >> choose unrepresentative benchmarks in order to make marketing people >> happy I find rather far-fetched. > >To add a single data point to this thread. I have worked on quite a few >ISA developments all in the embedded systems area. The appearance of >selective benchmarks is likely the result of targeting an ISA to a >specific application area than selectively promoting a general purpose >processor that doesn't do well in some applications (or benchmarks). > >My experience is that ISA designs and supporting tools have very >specific goals by the developers even if those goals are sometimes not >well articulated. I have never been involved in an ISA development that >wasn't committed to maximizing the intended application performance. > >In the developments I have been part of benchmarks are often run but the >biggest feedback is application reference designs often developed at the >same time. The reference design metrics early in an ISA development >significantly change how an application area is understood. At a minimum >it identifies data and control flow bottlenecks and focuses on potential >instruction set changes. Then there are the gamers. Their benchmarks cannot be subverted. More frames per second by a higher resolution is a criterium that indicates a total performance. Also hitches and lack of smoothness will be noticed. > >w.. > 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 | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-10-14 14:26 -0400 |
| Message-ID | <ntr81a$1s9a$1@gioia.aioe.org> |
| In reply to | #51819 |
On 2016-10-12 9:18 PM, Albert van der Horst wrote: > In article <ntm8mk$1n2$1@gioia.aioe.org>, Walter Banks > <walter@bytecraft.com> wrote: >> To add a single data point to this thread. I have worked on quite a >> few ISA developments all in the embedded systems area. The >> appearance of selective benchmarks is likely the result of >> targeting an ISA to a specific application area than selectively >> promoting a general purpose processor that doesn't do well in some >> applications (or benchmarks). >> >> My experience is that ISA designs and supporting tools have very >> specific goals by the developers even if those goals are sometimes >> not well articulated. I have never been involved in an ISA >> development that wasn't committed to maximizing the intended >> application performance. >> >> In the developments I have been part of benchmarks are often run >> but the biggest feedback is application reference designs often >> developed at the same time. The reference design metrics early in >> an ISA development significantly change how an application area is >> understood. At a minimum it identifies data and control flow >> bottlenecks and focuses on potential instruction set changes. > > Then there are the gamers. Their benchmarks cannot be subverted. More > frames per second by a higher resolution is a criterium that > indicates a total performance. Also hitches and lack of smoothness > will be noticed. As I said applications area and real application code are far more important than the generalized benchmarks in the process of developing ISA's and support tools. w..
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-12 20:30 -0700 |
| Message-ID | <e381f84e-cff9-43ca-8ccc-363df68b6c77@googlegroups.com> |
| In reply to | #51795 |
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. Designing an architecture just to do well in benchmarks would be stupid.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-10-13 15:52 +0000 |
| Message-ID | <2016Oct13.175257@mips.complang.tuwien.ac.at> |
| In reply to | #51822 |
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?
- 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 | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-10-13 15:05 -0700 |
| Message-ID | <b8d27016-82d4-498f-a6bd-1939b23dcd8d@googlegroups.com> |
| In reply to | #51834 |
On Friday, October 14, 2016 at 5:11:21 AM UTC+13, Anton Ertl wrote: > Lawrence D’Oliveiro 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, it’s what customers buy the machines for.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web