20 Jul
2016
20 Jul
'16
9:56 a.m.
From: Paul Koning
> I always felt that RISC meant 'making the
basic cycle time as fast as
> possible by finding the longest path through the logic - i.e. the
> limiting factor on the cycle time - and removing it (thereby making the
> instruction set less rich); then repeat'.
"Making the cycle time as fast as possible"
certainly applies, in
spades, to the 6600. The deeper you dig into its details, the more
impressed you will be by the many different ways in which it does things
faster than you would expect to be possible.
My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable. I'm not very familiar with the 6600 - does this
part apply too?
> RISC only makes (system-wide) sense in an
environment in which memory
> bandwidth is plentiful (so that having programs contain more, simpler
> instructions make sense)
I should have pointed out that programs of that sort take not just more memory
bandwidth, but more memory to hold them. In this day of massive memories, no
biggie, but back in the core memory days, it was more of an issue.
> One of the books about Turing argues that the ACE
can be seen as a RISC
> machine (it's not just that it's load-store; its overall architectural
> philosophy is all about maximizing instruction rates).
I looked, and it's "Alan Turing's Automatic Computing Engine"; in
Chapter 8,
"Computer architecture and the ACE computers", by Robert Doran (which is not,
for some reason, listed in the ToC).
I think a lot of machine designers, though not all,
were seriously
interested in making them go fast.
Again, RISC has two legs, not just making the machine fast, but making them
fast by using techniques that, as a side-effect, make them inscrutable, and
difficult to program. The concept was that they would not, in general, be
programmed in assembler - precisely because they were so finicky.
Remember, the 801 was a combined hardware/compiler project, in which
complexity was moved from the hardware to the compiler; and early RISC
machines has things like no interlocks between pipeline stages. So they really
were not intended to be programmed in assembler - the compiler was critical.
The ACE, on the surface, didn't follow this, as it had no compiler. However,
at a higher level, Turing definitely followed the RISC philosophy of making
the machine as fast as possible, by using techniques that made it very hard to
program; instead of moving the complexity to the compiler, he moved it to the
programmer - the latter not being a problem, if you're Alan Turing! :-)
Noel
20 Jul
20 Jul
11:17 a.m.
On 20/07/2016 14:56, Noel Chiappa wrote:
My formulation for RISC had two parts, though: not
just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable.
At least for some RISC, that's more than a side effect. While at Acorn
in about 1987, I attended talks run by Sophie Wilson and Steve Furber
where they described some of the design criteria for ARM. They were
very clear that the design goal was for every instruction to be executed
in a single cycle[1], not just discarding longer instructions. Thus the
process wasn't about removing instructions but rather about deciding
what (instructions and hardware) to put in as necessary and useful, so
that more complex operations could be built up from short sequences of
very fast instructions. Kind of like the Unix philosophy of pipelining
small utilities, in a way.
They also studied what had gone before: IBM 801, the Berkeley RISC
project, Clipper, and others. Steve describes some of this in his book
"VLSI RISC Architecture and Organisation", which is a good read if you
can find a copy.
[1] actually it's three clock cycles - fetch,decode,execute - but
there's a three-stage pipeline so although the duration of any given
instruction is 3 clocks, overall you get one instruction per clock [2].
[2] except I'm simplifying; for example there's only one memory port so
load and store instructions take an extra cycle, since they need one
memory access for the instruction fetch and one for the data - or more
if it's a block data transfer, obviously. And BTW it does have a mode
to take advantage of reduced access times for sequential access in
memories that support it. That's why the data sheets quote instruction
times in terms of S (sequential) and N (non-sequential) cycles.
--
Pete
11:44 a.m.
On Jul 20, 2016, at 9:56 AM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
Depending on what you mean by "less capable", I don't know that I would
agree with that. For example, I doubt that anyone would argue MIPS isn't a RISC
architecture. Yet MIPS is certainly very capable, and it certainly has a rather large
instruction set. The key point is that those instructions are, by and large, conceptually
straightforward, and lend themselves to efficient (small cycle count, small transistor
count) implementation. Also, RISC does not use, or need, microcode.
In that sense, the 6000 certainly qualifies. It has load/store, integer and float
arithmetic on registers, boolean ops, and basic transfer of control instructions.
That's about it. And the implementation is certainly straightforward. A 6600 has a
fair number of gates, but that stems from its multiple functional units, memory
scheduling, and intense emphasis on speed, not from the inherent complexity of its
instruction set. A 6400, which is a single functional unit implementation of the same
instruction set, is a whole lot smaller.
I recommend the excellent (and rather short) book by Thornton, one of the 6600 designers:
http://bitsavers.trailing-edge.com/pdf/cdc/cyber/books/DesignOfAComputer_CD… It
will take you through the design all the way from transistor considerations and circuit
elements to the instruction and memory scheduling machinery.
From: Paul Koning
> I always felt that RISC meant 'making the
basic cycle time as fast as
> possible by finding the longest path through the logic - i.e. the
> limiting factor on the cycle time - and removing it (thereby making the
> instruction set less rich); then repeat'.
"Making the cycle time as fast as
possible" certainly applies, in
spades, to the 6600. The deeper you dig into its details, the more
impressed you will be by the many different ways in which it does things
faster than you would expect to be possible.
My formulation for RISC had two parts, though: not just minizing the cycle
time, but doing so by doing things that (as a side-effect) make the
instruction set less capable. I'm not very familiar with the 6600 - does this
part apply too? > RISC only
makes (system-wide) sense in an environment in which memory
> bandwidth is plentiful (so that having programs contain more, simpler
> instructions make sense)
I should have pointed out that programs of that sort take not just more memory
bandwidth, but more memory to hold them. In this day of massive memories, no
biggie, but back in the core memory days, it was more of an issue. ...
It is true that a few RISC architectures are not very scrutable. Itanium is a notorious
example, as are some VLIW machines. But many RISC machines are much more sane. MIPS and
ARM certainly are no problem for any competent assembly language programmer. Alpha is a
bit harder but definitely doable too.
The burden on compiler optimizers tends to be higher. But I would argue that's true
for any high performance design: those have multiple pipelines, caches and prefetch, and
lots of other stuff that affects performance. The code optimizer has to know about these
things. (So does the assembly language programmer, if assembly is used for performance
rather than for esoteric bare metal stuff like boot or diagnostic code.) But, with the
possible exception of extremely bizarre designs like Itanium, that's all perfectly
doable.
paul
I think a lot of machine designers, though not
all, were seriously
interested in making them go fast.
Again, RISC has two legs, not just making the machine fast, but making them
fast by using techniques that, as a side-effect, make them inscrutable, and
difficult to program. The concept was that they would not, in general, be
programmed in assembler - precisely because they were so finicky.
12:42 p.m.
On 20/07/2016 16:44, Paul Koning wrote:
It is true that a few RISC architectures are not very
scrutable.
Itanium is a notorious example, as are some VLIW machines. But many
RISC machines are much more sane. MIPS and ARM certainly are no
problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard.
--
Pete
1:32 p.m.
New subject: RISC assembly by hand dammit was Re: Reproduction micros
It is true
that a few RISC architectures are not very scrutable.
Itanium is a notorious example, as are some VLIW machines. But many
RISC machines are much more sane. MIPS and ARM certainly are no
problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard. 
21 Jul
21 Jul
9:53 p.m.
On 7/20/2016 10:42 AM, Pete Turnbull wrote:
On 20/07/2016 16:44, Paul Koning wrote:
But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowlage?
Ben.
It is true that a few RISC architectures are not
very scrutable.
Itanium is a notorious example, as are some VLIW machines. But many
RISC machines are much more sane. MIPS and ARM certainly are no
problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard. 
11:34 p.m.
On Jul 21, 2016, at 6:53 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/20/2016 10:42 AM, Pete Turnbull wrote:
You read the Intel Optimization Guide.
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32…
TTFN - Guy
On 20/07/2016 16:44, Paul Koning wrote:
But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowledge? It is true that a few RISC architectures are not
very scrutable.
Itanium is a notorious example, as are some VLIW machines. But many
RISC machines are much more sane. MIPS and ARM certainly are no
problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard.
11:55 p.m.
On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote:
A read and cuss item I see. Thank you, but it seems it is still big $$$
for good compiler to follow the ever changing rules.
Ben.
On Jul 21, 2016, at 6:53 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/20/2016 10:42 AM, Pete Turnbull wrote:
You read the Intel Optimization Guide.
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32…
TTFN - Guy On 20/07/2016 16:44, Paul Koning wrote:
But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowledge? It is true that a few RISC architectures are not
very scrutable.
Itanium is a notorious example, as are some VLIW machines. But many
RISC machines are much more sane. MIPS and ARM certainly are no
problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard.
22 Jul
22 Jul
12:02 a.m.
On Jul 21, 2016, at 8:55 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote:
A read and cuss item I see. Thank you, but it seems it is still big $$$
for good compiler to follow the ever changing rules.
And yet they do. Processors are getting more and more complex in order
to deliver power/performance improvements. Larger caches with more ways,
deeper/wider pipes, more execution slots, number of rename registers, etc.
What do you expect? TNSTAAFL if you want to extract every last cycle of
performance out of a particular uArch. The good news is that most of the
time the uArch improvements work reasonably well with relatively non-specific
optimizations.
TTFN - Guy
On Jul 21, 2016, at 6:53 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/20/2016 10:42 AM, Pete Turnbull wrote:
You read the Intel Optimization Guide.
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32…
TTFN - Guy On 20/07/2016 16:44, Paul Koning wrote:
> It is true that a few RISC architectures are not very scrutable.
> Itanium is a notorious example, as are some VLIW machines. But many
> RISC machines are much more sane. MIPS and ARM certainly are no
> problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard.
But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowledge? 
5:24 a.m.
On Thu, Jul 21, 2016 at 09:55:26PM -0600, ben wrote:
[...]
A read and cuss item I see. Thank you, but it seems it
is still big $$$ for
good compiler to follow the ever changing rules.
Eh? The LLVM backend generates excellent code for at least x86 and ARM, and is
effectively BSD-licenced.
20 Jul
20 Jul
1:34 p.m.
Also, RISC does not use, or need, microcode.
I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- There are three kinds of people: those who can count and those who can't. --
1:42 p.m.
On Jul 20, 2016, at 1:34 PM, Cameron Kaiser
<spectre at floodgap.com> wrote:
What I meant is that I had no idea such things existed. Very curious. Learn something
new every day. What do they use this for?
The closest to microcode I'd ever heard of before is the "epicode" in Alpha.
Or was that Prism? Anyway, a DEC RISC architecture where some privileged stuff was done
in code running in a corner of the chip. Not actual microcode because it was essentially
the standard instruction set, somewhat extended and running in a special processor state.
paul
Also, RISC does not use, or need, microcode.
I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4). 
1:56 p.m.
On Jul 20, 2016, at 1:53 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
On Wed, 20 Jul 2016, Paul Koning wrote:
PALcode sounds right. I think "epicode" was the same thing, but in PRISM --
which was the second RISC chip architecture DEC built, and canceled before shipping it.
(Titan was the first; Alpha the third.)
paul
The closest to microcode I'd ever heard of
before is the "epicode" in
Alpha. Or was that Prism?
PALcode? That's sort of an amalgamation of microcode and emulation, IIRC.
I don't know what 'epicode' is, though.
2:16 p.m.
Also, RISC does not use, or need, microcode.
I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4). 
2:54 p.m.
On 20 July 2016 at 19:34, Cameron Kaiser <spectre at floodgap.com> wrote:
Isn't the general belief that many successful architectures that
started out as RISC, and are still marketed as RISC, aren't actually
very RISC-like at all any more?
And, secondarily, that ARM is one of the ones that has stayed closest
to its roots, unlike, e.g., POWER, SPARC and, well, most of the big
hot UNIX workstation chips of the '90s?
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)
Also, RISC
does not use, or need, microcode.
I'm not sure what you mean by this, but (for example) many POWER
implementations have microcode (example: the 970/G5, which is descended from
POWER4).
2:52 p.m.
On 20 July 2016 at 17:44, Paul Koning <paulkoning at comcast.net> wrote:
It is true that a few RISC architectures are not very
scrutable. Itanium is a notorious example, as are some VLIW machines.
Hang on. Itanium is not RISC -- it *is* VLIW. Isn't it?
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)
2872
days inactive
2874
days old
17 comments
10 participants
participants (10)
-
abuse＠cabal.org.uk -
aek＠bitsavers.org -
bfranchuk＠jetnet.ab.ca -
ggs＠shiresoft.com -
jnc＠mercury.lcs.mit.edu -
lproven＠gmail.com -
paulkoning＠comcast.net -
pete＠dunnington.plus.com -
spectre＠floodgap.com -
swiftgriggs＠gmail.com