Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #2012 > unrolled thread
| Started by | John Levine <johnl@iecc.com> |
|---|---|
| First post | 2011-06-02 19:36 +0000 |
| Last post | 2011-07-04 07:54 -0700 |
| Articles | 20 on this page of 92 — 24 participants |
Back to article view | Back to comp.arch
History of byte addressing John Levine <johnl@iecc.com> - 2011-06-02 19:36 +0000
Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-02 20:38 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 08:05 -0700
Re: History of byte addressing Alex McDonald <blog@rivadpm.com> - 2011-06-03 05:26 -0700
Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-03 09:48 -0400
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 07:49 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 10:56 -0700
Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-04 10:59 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-04 15:01 -0700
Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-04 22:53 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:40 -0700
Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-06-05 06:10 +0000
Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-05 10:00 -0700
Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-05 10:04 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:36 -0700
Re: History of byte addressing "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-05 11:00 -0700
Re: History of byte addressing Morten Reistad <first@last.name> - 2011-06-05 21:42 +0200
Re: History of byte addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-06-06 17:03 +0000
Re: History of byte addressing Andrew Reilly <areilly---@bigpond.net.au> - 2011-06-06 23:55 +0000
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:26 -0700
Re: History of byte addressing Andrew Reilly <areilly---@bigpond.net.au> - 2011-06-07 05:08 +0000
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-07 03:26 -0700
Re: History of byte addressing Roberto Waltman <usenet@rwaltman.com> - 2011-07-05 20:00 -0400
Re: History of byte addressing jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-06 00:15 +0000
Re: History of byte addressing George Neuner <gneuner2@comcast.net> - 2011-06-05 16:18 -0400
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:10 -0700
Re: History of byte addressing torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-06-07 10:50 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:02 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 15:51 +0200
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-05 13:43 -0600
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:12 -0700
Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-06 02:04 -0400
Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-05 23:49 -0700
Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-06 13:34 -0400
Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-06 10:49 -0700
Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-06 22:42 -0700
Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-07 07:37 -0400
Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-07 08:22 -0700
Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-11 09:56 -0700
Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-11 14:59 -0400
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-11 18:52 -0600
Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-12 12:40 -0700
Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-11 15:05 -0400
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 13:10 -0600
Re: History of byte addressing George Neuner <gneuner2@comcast.net> - 2011-06-06 16:41 -0400
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:13 -0700
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 23:50 -0600
Re: History of byte addressing Jim Haynes <jhaynes@alumni.uark.edu> - 2011-06-07 10:01 -0500
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-07 13:09 -0600
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-07 14:03 -0600
Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 05:16 -0600
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:44 -0700
Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-06-06 05:00 +0000
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:11 -0700
Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-06 08:00 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:16 -0700
Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 01:01 -0700
Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-06 08:30 +0100
Re: History of byte addressing Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-06-06 10:34 +0200
Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 03:29 -0700
Re: History of byte addressing Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-06-06 15:21 +0200
Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 03:23 -0700
Re: History of byte addressing MitchAlsup <MitchAlsup@aol.com> - 2011-06-07 08:01 -0700
Re: alignment, was History of byte addressing John Levine <johnl@iecc.com> - 2011-06-06 18:33 +0000
Re: alignment, was History of byte addressing nmm1@cam.ac.uk - 2011-06-06 19:30 +0100
Re: alignment, was History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-06 15:32 -0400
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:11 -0700
Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-06 06:48 -0700
Re: History of byte addressing jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-03 16:13 +0000
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-03 09:10 -0700
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:23 +0200
Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-07 08:26 -0700
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:25 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:45 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:48 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:59 +0200
Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 17:05 +0200
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-18 15:43 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 03:14 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 03:40 -0700
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 04:28 -0700
Re: History of byte addressing nmm1@cam.ac.uk - 2011-07-04 13:38 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 06:47 -0700
Re: History of byte addressing nmm1@cam.ac.uk - 2011-07-04 14:16 +0100
Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:53 +0100
Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:36 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 07:50 -0700
Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-07-04 19:46 +0000
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 15:29 -0700
Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-05 00:02 +0100
Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:47 +0100
Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 07:54 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2011-06-06 15:21 +0200 |
| Message-ID | <qs0vb8-e39.ln1@ntp6.tmsw.no> |
| In reply to | #2056 |
Michael S wrote: > On Jun 6, 10:34 am, Terje Mathisen<"terje.mathisen at tmsw.no"> > wrote: >> n...@cam.ac.uk wrote: >>> Even today, one of the golden rules of performance programming is >>> to align data. It may help a lot or negligibly, but it is always >>> worthwhile and doesn't need expensive investigation and machine- >>> dependent hacks. >> >> True. >> > > Terje, you are the last person from which I'd expect this sort of > response. > Getting old? Fortunately enough I'm still getting another day older every day. > >> The corrolary to that rule is that you should order your variables so >> that they pack together naturally, with no need for alignment padding. >> > > That's another matter. > "Free" alignment could be applied without thinking twice. > On the other hand, padding should be evaluated in specific context. > That is, if performance matter. If it does not, which is a majority of > cases, I am all for think-less padding, especially in the structures > that are exposed to the outside word. Padding can be both good and bad: Particularly bad if it makes all data structures a power of two in size, causing line trashing in your L1/L2 cache. Nick can tell us about Fortran compilers that would pad arrays so as to not be a power of two in size, right? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2011-06-06 03:23 -0700 |
| Message-ID | <b237d630-ac81-4a02-8457-cb681a3893d8@x3g2000yqj.googlegroups.com> |
| In reply to | #2053 |
On Jun 6, 9:30 am, n...@cam.ac.uk wrote: > In article <93eabd84-42a3-4f74-a96c-cc28e4dce...@v10g2000yqn.googlegroups.com>, > Michael S <already5cho...@yahoo.com> wrote: > > >On Jun 6, 7:11=A0am, Quadibloc <jsav...@ecn.ab.ca> wrote: > > >> But unaligned operands are still inefficient. > > >How do you know? Did you run relevant microbenchmarks on modern IBM > >hardware? > > Sigh. Do you know how caches and TLBs work? The inefficiency is > almost certainly vastly less than it was in the 1970s, but there > is an INHERENT inefficiency with unaligned working on machines > that use fixed alignment caching. No. There is no inherent inefficiency that can't be solved by throwing more hardware at it, especially in situation where your machine doesn't deliver max. theoretical throughput due to other bottlenecks. Which would be a VERY common common on 3-way superscalar machine like z196 predominantly running commercial workloads with typical IPC in 0.5-1.0 range. > > Even today, one of the golden rules of performance programming is > to align data. It may help a lot or negligibly, but it is always > worthwhile and doesn't need expensive investigation and machine- > dependent hacks. > > Regards, > Nick Maclaren. There is only one golden rule of performance programming: profile! Never trust your intuition, never trust previous experience unless the system you acquired that experience was very similar to one you are running now. Simply profile. Padding vs non-padding trade-offs are extremely hardware specific and very dependent on absolute size of the data set.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Date | 2011-06-07 08:01 -0700 |
| Message-ID | <e9a07349-529e-4370-a6c5-61a3c63f28cb@w10g2000yqh.googlegroups.com> |
| In reply to | #2055 |
On Jun 6, 5:23 am, Michael S <already5cho...@yahoo.com> wrote:
> On Jun 6, 9:30 am, n...@cam.ac.uk wrote:
>
> > In article <93eabd84-42a3-4f74-a96c-cc28e4dce...@v10g2000yqn.googlegroups.com>,
> > Michael S <already5cho...@yahoo.com> wrote:
>
> > >On Jun 6, 7:11=A0am, Quadibloc <jsav...@ecn.ab.ca> wrote:
>
> > >> But unaligned operands are still inefficient.
>
> > >How do you know? Did you run relevant microbenchmarks on modern IBM
> > >hardware?
>
> > Sigh. Do you know how caches and TLBs work? The inefficiency is
> > almost certainly vastly less than it was in the 1970s, but there
> > is an INHERENT inefficiency with unaligned working on machines
> > that use fixed alignment caching.
>
> No. There is no inherent inefficiency that can't be solved by throwing
> more hardware at it,
So, you are trading off pipeline efficiency for power efficiency. In
order to make misaligned memory references efficient, one needs to
have twice as many cache blocks as an aligned system. {I happen to be
a member of the "misaligned looks inexpensive" camp. It solves too
many other problems--like FORTRAN common lock alignments.}
Mitch
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@iecc.com> |
|---|---|
| Date | 2011-06-06 18:33 +0000 |
| Subject | Re: alignment, was History of byte addressing |
| Message-ID | <isj6h6$6se$1@gal.iecc.com> |
| In reply to | #2053 |
>Sigh. Do you know how caches and TLBs work? The inefficiency is >almost certainly vastly less than it was in the 1970s, but there >is an INHERENT inefficiency with unaligned working on machines >that use fixed alignment caching. I read somewhere that on modern IBM mainframes there is no speed penalty for unaligned operands. Apparently the pipeline can do two cache fetches or stores as fast as one. Their memory architecture is a little unusual since they typically have a dozen CPUs with fully coherent shared memory. R's, John
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2011-06-06 19:30 +0100 |
| Subject | Re: alignment, was History of byte addressing |
| Message-ID | <isj6c5$a44$1@gosset.csi.cam.ac.uk> |
| In reply to | #2063 |
In article <isj6h6$6se$1@gal.iecc.com>, John Levine <johnl@iecc.com> wrote: > >>Sigh. Do you know how caches and TLBs work? The inefficiency is >>almost certainly vastly less than it was in the 1970s, but there >>is an INHERENT inefficiency with unaligned working on machines >>that use fixed alignment caching. > >I read somewhere that on modern IBM mainframes there is no speed >penalty for unaligned operands. Apparently the pipeline can do two >cache fetches or stores as fast as one. Whether or not it can, that isn't the only source of inefficiency. >Their memory architecture is a little unusual since they typically >have a dozen CPUs with fully coherent shared memory. If you want real fun, there are some shared memory codes where unaligned accesses can double the number of lines that are on the wrong core when they are needed! And, while their architecture is unusual, it isn't exempt from inefficiencies due to such conflicts! Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2011-06-06 15:32 -0400 |
| Subject | Re: alignment, was History of byte addressing |
| Message-ID | <m3y61en4ca.fsf@garlic.com> |
| In reply to | #2064 |
nmm1@cam.ac.uk writes: > If you want real fun, there are some shared memory codes where > unaligned accesses can double the number of lines that are on > the wrong core when they are needed! > > And, while their architecture is unusual, it isn't exempt from > inefficiencies due to such conflicts! aka early 80s, at least MVS & VM370 operating systems had major work item to make internal kernel storage cache-line sensitive (i.e. started on cache line and ended on cache-line). claim was that it got 5-6% system thruput improvement in 4-way configuration (eliminating cache-line thrashing where different storage areas ... in use by different processors, shared cache line). another way of looking at some of the current stuff ... is that relative latencies for fetches have increased so ... there is lots of time to overlap/mask all sorts of stuff (as well as lots of extra circuits to perform the additional operations). for instance ... current generation is quoted as having 50% higher thruput than previous generation ... some comes from faster machine cycle ... but also 20% comes from the (new) introduction of out-of-order exectuion. all those spare circuits also help account for big expansion in instruction set ... compared to KISS from 360 days. one example (early instruction KISS) associated with was the introduction of compare-and-swap. Charlie invented compare-and-swap (CAS are charlie's initials) when he was doing work on multiprocessor fine-grain locking in cp67 (360/67 had test&set). Initial attempt to get compare-and-swap into 370 were rejected with reference to the POK favorite-son operating system believing that (360) test-and-set was more than adequate for multiprocessor implementations. The 370 architecture people said that in order to get compare-and-swap included in 370 architecture some non-multiprocessor uses would have to be created. Thus was born the multiprogramming (aka multi-threaded) application uses (like large DBMS operations) ... being able to do various kinds of atomic storage updates (w/o requiring kernel lock/serialization). misc. past posts mentioning compare&swap and/or multiprocessor http://www.garlic.com/~lynn/subtopic.html#smp -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-06-06 18:11 -0700 |
| Message-ID | <5798be5c-1394-4826-9d7a-5069f79ece3e@k16g2000yqm.googlegroups.com> |
| In reply to | #2052 |
On Jun 6, 2:01 am, Michael S <already5cho...@yahoo.com> wrote: > On Jun 6, 7:11 am, Quadibloc <jsav...@ecn.ab.ca> wrote: > > But unaligned operands are still inefficient. > > How do you know? Did you run relevant microbenchmarks on modern IBM > hardware? I know they *were* on the early 370s. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Robert Myers <rbmyersusa@gmail.com> |
|---|---|
| Date | 2011-06-06 06:48 -0700 |
| Message-ID | <27911734-807c-4753-a7bf-e3eaa28d5598@dr5g2000vbb.googlegroups.com> |
| In reply to | #2045 |
On Jun 6, 1:00 am, John Levine <jo...@iecc.com> wrote: > >My history of the subject: > > >Goodbye IBM == Goodbye incomprehensible alignment error messages. I > >suppose I should be grateful the arithmetic wasn't all decimal. > > You must have said goodbye a long time ago. IBM mainframes haven't > required aligned operands for almost 40 years. > About that. CDC/Cray for computation, IBM for W-2 forms. Robert.
[toc] | [prev] | [next] | [standalone]
| From | jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) |
|---|---|
| Date | 2011-07-03 16:13 +0000 |
| Message-ID | <4e10939b.242841@news.aioe.org> |
| In reply to | #2059 |
On Mon, 6 Jun 2011 06:48:51 -0700 (PDT), Robert Myers <rbmyersusa@gmail.com> wrote, in part: >About that. CDC/Cray for computation, IBM for W-2 forms. IBM is still making supercomputers, but basing them on their PowerPC chips, not on z/Architecture. In fact, while there was a vector arithmetic feature introduced on the 370 which survived until ESA/390, it's been dropped as part of z/Architecture. Which only makes sense, as IBM's zSeries is sold at premium prices for people who find it has advantages, either in running legacy code, or in the specific application area where it appears to shine - handling large databases. I think that the 360 ISA was inherently attractive, and it's certainly cleaner than the x86 ISA. So I'm kind of sad to see it shunted off to a niche. I will admit, though, that even when IBM was in full contention in high performance computing - the NORC, the STRETCH, and the 360/195 - this wasn't its core business. Even if the 360/85 and 360/91 included innovations that shaped the way today's computers work, back then a 6600 was better bang for the buck. John Savard http://www.quadibloc.com/index.html
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-07-03 09:10 -0700 |
| Message-ID | <0133dabd-bedc-428b-ae4a-080b7cf8eeb0@q1g2000vbj.googlegroups.com> |
| In reply to | #2036 |
On Jun 5, 11:00 am, Robert Myers <rbmyers...@gmail.com> wrote: > My history of the subject: > > Goodbye IBM == Goodbye incomprehensible alignment error messages. I > suppose I should be grateful the arithmetic wasn't all decimal. I am going to make another comment on this. I noted already, I think, that I didn't find the alignment requirements of the 360 to be hard to comprehend. To me, they were entirely reasonable and made perfect sense. And, thus, in my own design for an Instruction Set Architecture, to deal with things I really *did* find annoying - such as the fact that the 360 only had a 12-bit displacement field, or the 68000, which had a 16-bit displacement field, shrank that to 8 bits if you wanted to use an index register in addition to a base register, and the 68020 required memory reference instructions to expand to a huge 48 bits if you wanted a base register, an index register, and a 16-bit displacement - I copied an innovation from the SEL 32 computer, so that for those instructions whose use of opcode space I wished to minimize, it became *impossible* to code an instruction pointing to an unaligned operand. http://www.quadibloc.com/arch/ar010002.htm illustrates where I take this, using the same principle in 16-bit memory-reference instructions that manage a 10-bit displacement field, as well as inverting the idea to halve the opcode space used by 16-bit shift instructions - six bits are used for the shift when shifting a 64-bit argument, but then the field shrinks as the operands do. John Savard
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 16:23 +0200 |
| Message-ID | <9da4e$4dee3443$5419acc3$30489@cache3.tilbu1.nb.home.nl> |
| In reply to | #2012 |
" Back in the heroic era (the 1950s), computers were either word addressed, with kludges to extract smaller fields, or else by character, usually with instructions to handle strings of characters, but not to handle fixed sized groups of them. " This is a bit a strange statement. Numbers probably have to be "bit-group-sized" for arithmetic purposes. Characters need to be represented by numbers/alphabet so it makes sense to stuff characters into "bit-group-sized" as well. Your last sentence is weird: "but not to handle fixed sized groups of them" What would you expect otherwise ? character strings of a fixed size ? like 10 characters per human spoken word ? Seems only logical to me that character strings have some kind of flexibility to them. Though turbo pascal has 255 char limit and Delphi 2 GB limit because of memory system limitations. C has the null terminator character. You also mention: "usually with instructions to handle strings of characters" What kind of instructions would this be ? There could only be two: 1. Either instructions based on a maximum character string length, like turbo pascal/delphi. or 2. A null terminator approach, like scan string functions. Perhaps I am missing here something ? Did older machines have some special instructions for "flexible data sizes" ? Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <SFuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2011-06-07 08:26 -0700 |
| Message-ID | <islfvl$j1k$1@dont-email.me> |
| In reply to | #2087 |
On 6/7/2011 7:23 AM, Skybuck Flying wrote: > " > Back in the heroic era (the 1950s), computers were either word > addressed, with kludges to extract smaller fields, or else by > character, usually with instructions to handle strings of characters, > but not to handle fixed sized groups of them. > " > > This is a bit a strange statement. > > Numbers probably have to be "bit-group-sized" for arithmetic purposes. > > Characters need to be represented by numbers/alphabet so it makes sense > to stuff characters into "bit-group-sized" as well. > > Your last sentence is weird: > > "but not to handle fixed sized groups of them" > > What would you expect otherwise ? character strings of a fixed size ? > like 10 characters per human spoken word ? > > Seems only logical to me that character strings have some kind of > flexibility to them. > > Though turbo pascal has 255 char limit and Delphi 2 GB limit because of > memory system limitations. > > C has the null terminator character. > > You also mention: > > "usually with instructions to handle strings of characters" > > What kind of instructions would this be ? > > There could only be two: > > 1. Either instructions based on a maximum character string length, like > turbo pascal/delphi. > > or > > 2. A null terminator approach, like scan string functions. > > Perhaps I am missing here something ? > > Did older machines have some special instructions for "flexible data > sizes" ? Yes, some did. For example, see the IBM 1401 and the phrase "word mark". Hint, Wikipedia. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 16:25 +0200 |
| Message-ID | <6c5a7$4dee34d1$5419acc3$31284@cache3.tilbu1.nb.home.nl> |
| In reply to | #2012 |
Alternative ideas to "addressing in general" is probably some kind of stacking machine. It simply pushes and pops data as it executes. The stack itself might know about addressing but not necessarily the programs that use it. Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 16:45 +0200 |
| Message-ID | <24eff$4dee399a$5419acc3$5588@cache3.tilbu1.nb.home.nl> |
| In reply to | #2088 |
This pushing and popping idea might be used for a more general/flexibile addressing scheme. Instead of thinking as an address as an "absolute address" these pushes and pops could also be considered an "relative address". For example the program itself could keep track of where it pushed a certain variable. For example it pushes variable A. It keeps track of variable counterA. Every time it pushes something else it increases counterA Every time it pops something else it decreases counterA counterA is therefore an indication of how many pushes/pops away the variable A is. So one could say/reason: "Variable A is 5 pops away." Retrieving variable A could then be done via a special stack manager which understand these requests: "PopSeek 5" would then mean pop the previous 5 things that were pushed onto the stack but not really, don't really pop them... just pretend... and return whatever is there. This way anything could have been pushed... flexible data structures could have been pushed. But still offers some kind of "flexible addressing". Ofcourse this wouldn't hold if the stack changes... but that's what counterA is for... so in reality one would write: "PopSeek counterA IntoStorage" which would then return variable A from the stack without actually removing it... this can be considered a read. writing could be done as well "PushSeek counterA FromStorage" counterA still needs to be an arithmetic unit probably fixed bit, because of that it probably makes little sense to using this pushing/popping addressing technique... and counterA could be turned into a real/absolute pointer for fast access and less overhead of stack mechanism, which would also need to keep track of what was pushed and how large it's data sizes were. Stack structure would be: Data Size, Data pushed Data Size, Data pushed Data Size, Data pushed This way the stack structure knows how much data was pushed to make it flexible. Perhaps the counter variables could be attached to the real variable by the compiler and automatically be provided to the stack instructions/mechanism so it can automatically adjust these counters. Though there could be multiple and might consume some memory. It could have a counter stack as well: VariableCounter VariableCounter VariableCounter VariableCounter The compiler would be responsible for placing the variable counters into the stack's counter memory. All the stack has to do is modify each counter when something is pushed or popped. This does leave issues of variables coming and going out of scope... Perhaps it could grow and the compiler could modify the StackCounterCount variable to indicate how many counters there are at any given time. However a stack counter also has to be associated with a variable which is being used by the code. Perhaps the data structure would be simplified as follows: VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData This way the variable counter is fixed-bit size. This way the variable size is fixed bit size. This way the variable data can be any length, though this would be bad for performance, so it would still be smart to set a maximum for variable data. For example 4 or 8 or 16 bytes. This way the variables can be somewhat flexible and the stack can operate somewhat flexible. Though performance the performance wouldn't be as bad as my initial guess... Since the stack's modification of counters has to proceed in sequential fashion anyway it might as well keep track of variable size as it goes along. Therefore the requirement/advice of limiting variable data to a maximum is no longer required and can be let go. Conclusion is therefore that this could indeed provide truly flexible data from being pushed and popped onto the stack without to much of a performance hit. Quite an interesting though experiment and also with a practical vision onto this. I think this could probably work. And could be used for a universal machine using my universal code... however that was about bit flexibility which would be a bridge too far for nowadays cpu's... but the idea's in this posting could also be applied to a byte approach... byte flexibility. Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 16:48 +0200 |
| Message-ID | <425bc$4dee3a39$5419acc3$6346@cache3.tilbu1.nb.home.nl> |
| In reply to | #2089 |
In case this hasn't be invented before I shall call it: "Stack relative addressing" ;) Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 16:59 +0200 |
| Message-ID | <2bb72$4dee3cdd$5419acc3$9977@cache3.tilbu1.nb.home.nl> |
| In reply to | #2089 |
"Skybuck Flying" wrote in message news:24eff$4dee399a$5419acc3$5588@cache3.tilbu1.nb.home.nl... This pushing and popping idea might be used for a more general/flexibile addressing scheme. Instead of thinking as an address as an "absolute address" these pushes and pops could also be considered an "relative address". For example the program itself could keep track of where it pushed a certain variable. For example it pushes variable A. It keeps track of variable counterA. Every time it pushes something else it increases counterA Every time it pops something else it decreases counterA counterA is therefore an indication of how many pushes/pops away the variable A is. So one could say/reason: "Variable A is 5 pops away." Retrieving variable A could then be done via a special stack manager which understand these requests: "PopSeek 5" would then mean pop the previous 5 things that were pushed onto the stack but not really, don't really pop them... just pretend... and return whatever is there. This way anything could have been pushed... flexible data structures could have been pushed. But still offers some kind of "flexible addressing". Ofcourse this wouldn't hold if the stack changes... but that's what counterA is for... so in reality one would write: "PopSeek counterA IntoStorage" which would then return variable A from the stack without actually removing it... this can be considered a read. writing could be done as well "PushSeek counterA FromStorage" counterA still needs to be an arithmetic unit probably fixed bit, because of that it probably makes little sense to using this pushing/popping addressing technique... and counterA could be turned into a real/absolute pointer for fast access and less overhead of stack mechanism, which would also need to keep track of what was pushed and how large it's data sizes were. Stack structure would be: Data Size, Data pushed Data Size, Data pushed Data Size, Data pushed This way the stack structure knows how much data was pushed to make it flexible. Perhaps the counter variables could be attached to the real variable by the compiler and automatically be provided to the stack instructions/mechanism so it can automatically adjust these counters. Though there could be multiple and might consume some memory. It could have a counter stack as well: VariableCounter VariableCounter VariableCounter VariableCounter The compiler would be responsible for placing the variable counters into the stack's counter memory. All the stack has to do is modify each counter when something is pushed or popped. This does leave issues of variables coming and going out of scope... Perhaps it could grow and the compiler could modify the StackCounterCount variable to indicate how many counters there are at any given time. However a stack counter also has to be associated with a variable which is being used by the code. Perhaps the data structure would be simplified as follows: VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData This way the variable counter is fixed-bit size. This way the variable size is fixed bit size. This way the variable data can be any length, though this would be bad for performance, so it would still be smart to set a maximum for variable data. For example 4 or 8 or 16 bytes. This way the variables can be somewhat flexible and the stack can operate somewhat flexible. " Though performance the performance wouldn't be as bad as my initial guess... Since the stack's modification of counters has to proceed in sequential fashion anyway it might as well keep track of variable size as it goes along. " Little correction here: " Though perhaps the performance wouldn't be as bad as my initial guess... Since the stack's modification of counters would proceed in sequential fashion anyway it might as well keep track of variable size as it goes along. " Addition: Modifieing the stack counters could also happen in parallel, so I shouldn't have written "has to" that was a bit mean/restrictive ;) So in reality hardware could be created which does this counter modification almost for free... .. original continued...: Therefore the requirement/advice of limiting variable data to a maximum is no longer required and can be let go. Conclusion is therefore that this could indeed provide truly flexible data from being pushed and popped onto the stack without to much of a performance hit. Quite an interesting though experiment and also with a practical vision onto this. I think this could probably work. And could be used for a universal machine using my universal code... however that was about bit flexibility which would be a bridge too far for nowadays cpu's... but the idea's in this posting could also be applied to a byte approach... byte flexibility. Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> |
|---|---|
| Date | 2011-06-07 17:05 +0200 |
| Message-ID | <e1635$4dee3e27$5419acc3$11969@cache3.tilbu1.nb.home.nl> |
| In reply to | #2091 |
"Skybuck Flying" wrote in message news:2bb72$4dee3cdd$5419acc3$9977@cache3.tilbu1.nb.home.nl... "Skybuck Flying" wrote in message news:24eff$4dee399a$5419acc3$5588@cache3.tilbu1.nb.home.nl... This pushing and popping idea might be used for a more general/flexibile addressing scheme. Instead of thinking as an address as an "absolute address" these pushes and pops could also be considered an "relative address". For example the program itself could keep track of where it pushed a certain variable. For example it pushes variable A. It keeps track of variable counterA. Every time it pushes something else it increases counterA Every time it pops something else it decreases counterA counterA is therefore an indication of how many pushes/pops away the variable A is. So one could say/reason: "Variable A is 5 pops away." Retrieving variable A could then be done via a special stack manager which understand these requests: "PopSeek 5" would then mean pop the previous 5 things that were pushed onto the stack but not really, don't really pop them... just pretend... and return whatever is there. This way anything could have been pushed... flexible data structures could have been pushed. But still offers some kind of "flexible addressing". Ofcourse this wouldn't hold if the stack changes... but that's what counterA is for... so in reality one would write: "PopSeek counterA IntoStorage" which would then return variable A from the stack without actually removing it... this can be considered a read. writing could be done as well "PushSeek counterA FromStorage" counterA still needs to be an arithmetic unit probably fixed bit, because of that it probably makes little sense to using this pushing/popping addressing technique... and counterA could be turned into a real/absolute pointer for fast access and less overhead of stack mechanism, which would also need to keep track of what was pushed and how large it's data sizes were. Stack structure would be: Data Size, Data pushed Data Size, Data pushed Data Size, Data pushed This way the stack structure knows how much data was pushed to make it flexible. Perhaps the counter variables could be attached to the real variable by the compiler and automatically be provided to the stack instructions/mechanism so it can automatically adjust these counters. Though there could be multiple and might consume some memory. It could have a counter stack as well: VariableCounter VariableCounter VariableCounter VariableCounter The compiler would be responsible for placing the variable counters into the stack's counter memory. All the stack has to do is modify each counter when something is pushed or popped. This does leave issues of variables coming and going out of scope... Perhaps it could grow and the compiler could modify the StackCounterCount variable to indicate how many counters there are at any given time. However a stack counter also has to be associated with a variable which is being used by the code. Perhaps the data structure would be simplified as follows: VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData VariableCounter, VariableSize, VariableData This way the variable counter is fixed-bit size. This way the variable size is fixed bit size. This way the variable data can be any length, though this would be bad for performance, so it would still be smart to set a maximum for variable data. For example 4 or 8 or 16 bytes. This way the variables can be somewhat flexible and the stack can operate somewhat flexible. " Though performance the performance wouldn't be as bad as my initial guess... Since the stack's modification of counters has to proceed in sequential fashion anyway it might as well keep track of variable size as it goes along. " Little correction here: " Though perhaps the performance wouldn't be as bad as my initial guess... Since the stack's modification of counters would proceed in sequential fashion anyway it might as well keep track of variable size as it goes along. " Addition: Modifieing the stack counters could also happen in parallel, so I shouldn't have written "has to" that was a bit mean/restrictive ;) Further addition: Though now that I look at it again, this might be difficult to do, because of the flexible data... thus perhaps my initial hunch that it has to proceed sequentially is more realistic, lazy and easy to implement, so stick with that for now ! ;) :) So in reality hardware could be created which does this counter modification almost for free... .. original continued...: Therefore the requirement/advice of limiting variable data to a maximum is no longer required and can be let go. Conclusion is therefore that this could indeed provide truly flexible data from being pushed and popped onto the stack without to much of a performance hit. Quite an interesting though experiment and also with a practical vision onto this. I think this could probably work. And could be used for a universal machine using my universal code... however that was about bit flexibility which would be a bridge too far for nowadays cpu's... but the idea's in this posting could also be applied to a byte approach... byte flexibility. Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-06-18 15:43 -0700 |
| Message-ID | <05fffadd-5b5b-4409-889d-3815b69f7ee5@r20g2000yqd.googlegroups.com> |
| In reply to | #2012 |
On Jun 2, 1:36 pm, John Levine <jo...@iecc.com> wrote: > These days people think that it's practically a law of nature that computer > memory is composed of 8-bit bytes that can be addressed individually, or > in power-of-two groups up to whatever the machine's register size is. > > Back in the heroic era (the 1950s), computers were either word > addressed, with kludges to extract smaller fields, or else by > character, usually with instructions to handle strings of characters, > but not to handle fixed sized groups of them. This, of course, kind of explains why the power-of-two scheme became so popular after the IBM 360 presented it. I've noted why I think that the 360 really was the first, because IBM did originate, for that machine, the concept of allowing the same machine to handle both variable-length character strings and fixed-length binary words, so that a single architecture could be both "scientific" and "commercial". Of course, the IBM STRETCH, before the 360, also had a 64-bit word size and 8-bit characters. In addition, it had something else that the 360 did not which would have been a reason for dividing a 64-bit word into eight 8-bit characters... instead of a 48-bit word into eight 6- bit characters. It had instructions that addressed individual bits in the computer - in fact, it had two data types, floating-point numbers and arbitrary bit fields. (But the floating-point type was set up so that it could be used, with unnormalized instructions, for integer arithmetic, instead of having to accept the overhead of integer arithmetic on arbitrary bit fields.) I will mention again, since I've made some changes and additions to this section of my web site, that I've considered various ways of retaining the advantages of power-of-two addressing while also having the increased flexibility that some word lengths with a more diverse set of factors appear to have the potential of providing. http://www.quadibloc.com/arch/perint.htm with my latest brainstorm at http://www.quadibloc.com/arch/per04.htm John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-07-04 03:14 -0700 |
| Message-ID | <5173fb4c-6eeb-4adb-84ff-b5965915a281@h17g2000yqn.googlegroups.com> |
| In reply to | #2012 |
On Jun 2, 1:36 pm, John Levine <jo...@iecc.com> wrote: > The first machine I know of with modern byte addressing was the IBM > System/360. Did they invent it, or did someone else do it first? As I noted, the STRETCH had individual bit addressing, but not, as far as I knew anything like the IBM 360's byte addressing. However, while I think the 360 did pioneer having addressable *characters* on a word machine, I now realize that I was too parochial in looking for precedents to the 360's addressing. I dimly recall encountering some cases in which a machine had a word of, say, 40 bits - and had two jump instructions, one to "jump to first instruction in word" and another to "jump to second instruction in word". This would even anticipate the SEL 32 trick of including the LSBs of the address only when required. I don't yet have an example of this. I checked the Control Data 1604 and 6600, and found that they didn't address the individual parts of a word - they always branched to the first instruction in a word... except that returning from a subroutine always branched to the second instruction on the 1604, and the 6600 did something similar. But I have found one example already where an alignment restriction distinct from the limits of addressing existed on a machine before the IBM 360. The Bendix G-15 required that double-word integers begin at an even- numbered memory location. So if one looks for halfword addressing, then one may find things analogous to the 360. (Normally, there's no reason for double words to need to be aligned: the G-15, of course, was a drum machine, so different considerations applied.) John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2011-07-04 03:40 -0700 |
| Message-ID | <f66d7a95-a37e-4a5f-ad19-34263d72cb39@h14g2000yqg.googlegroups.com> |
| In reply to | #2341 |
I've turned up another example. The KDF 9 addressed memory as 48-bit words. However, jump instructions included an additional 3-bit field which indicated the 8-bit instruction syllable which was being referenced; values from 0 to 5 were valid, 6 and 7 were not. John Savard
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.arch
csiph-web