Re: One of the deeper dives into RISC vs CISC I've seen
At 12:56 PM 25/06/2019 +0200, Liam Proven wrote: >On Mon, 24 Jun 2019 at 12:31, Tony Aiuto via cctalk > wrote: >> >> On a related note, a fun talk about ARM >> https://www.youtube.com/watch?time_continue=2045=_6sh097Dk5k > >Remarkable. Thanks for the link. Astounding. Very thought-provoking. Yes, it is. Fascinating! And right now jdownloader is fetching me a local copy, as opposed to previously not working with that one video for some inexplicable reason. So thanks for reminding me to try again. Guy
Re: One of the deeper dives into RISC vs CISC I've seen
On Mon, 24 Jun 2019 at 12:31, Tony Aiuto via cctalk wrote: > > On a related note, a fun talk about ARM > https://www.youtube.com/watch?time_continue=2045=_6sh097Dk5k Remarkable. Thanks for the link. Astounding. Very thought-provoking. -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: One of the deeper dives into RISC vs CISC I've seen
On a related note, a fun talk about ARM https://www.youtube.com/watch?time_continue=2045=_6sh097Dk5k
Re: One of the deeper dives into RISC vs CISC I've seen
On Sat, Jun 15, 2019 at 08:25:13AM -0700, Chuck Guzis via cctalk wrote: > > It's difficult to say exactly, because of the constraints on the > definition. Or does something have to be RISC only if it came after > the definition? > I would say that one of the points he was making is that the definition is not very clear. It was enlightning to see that there are properties and traits other than instruction count and addressing mode counts that make a design RISCy or CISCy (I haven't read the whole thing yet, it requires some digestion: ) /P
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/16/19 8:17 AM, Noel Chiappa via cctalk wrote: > Still, the basic idea of RISC still applies; make the CPU clock rate as fast > as > possible by making the instructions simple, and let software deal with the > resulting > issues. I'll mention in passing here that the goal of executing the maximum number of instructions per unit time is a bit of a red herring. What really matters is delivering the largest number of results per unit time. So SIMD ISAs can blow away scalar RISC implementations for certain classes of problems, which is why they've been part of multimedia for a long time now and are even part of ARM (e.g. Neon). --Chuck
Re: One of the deeper dives into RISC vs CISC I've seen
I finally got around to reading that note. My principal reponse is that it got so far down into details that I couldn't see the larger picture any more. Going back to the original IBM 801 work, the RISC concept is very simple: to make the overall system as fast as possible; it did this by making the CPU cycle time as short as possible. This results in a CPU that is not as easy to work with; therefore the compiler has to be 'smarter'. In other words, engineering complexity is moved from the hardware to the software. This is an an acceptable tradeoff; the complexity in the software is not a recurring cost, whereas extra gates add cost to every machine produced. Moreover, while the more complex compiler may be more time-consuming to run, that cost is only paid once, whereas the efficiency of the binary is felt every time the program is run. Focusing on what features a CPU does or does not have in some ways misses the whole point of RISC: it's not about what specific features the CPU has, in isolation; it's about looking at the system as a whole, all the way up through the compilers, to maximize performance. I recall Tom Knight laying out the implication for CPU design very simply, in a seminar I took back when the idea had just come out: look at the CPU design, and find the longest signal path; this will set the lower limit on the clock time. Redesign to remove that path; since the capability that needed it will inevitably be used only part of the time, the execution increase caused by losing it will be outweighed by the speedup of all the other instructions. The other thing one needs to remember, talking about RISC, is that it's now been almost 40 years since the concept was devised (an eternity in the computing field), and the technology environment has changed drastically since then. So RISC has changed and adapted as that environment changed. Nowadays, when people throw a billion transistors at each CPU, the picture is somewhat different. Register widows were just the first instance of this sort of thing; we have this unused area of the chip, what can we put there? >> On 6/15/19 3:40 PM, ben via cctalk wrote: >> CISC design is now needed to handle the 'extended features'. ... RISC came >> along only because Compilers could only generate SIMPLE instructions, that >> matched the RISC format. No; compilers had been created that could use the more complex CISC instructions of, say, a VAX. RISC post-dated a lot of those developments, and had an entirely different point. > From: Chuck Guzis > For what it's worth, the number of instructions in the ISA does not define > RISC, but rather that the instructions execute quickly. Some RISC > implementations have large instruction sets. Right; what's reduced is the complexity of the instructions, which leads to the speedup which is the goal, not the number of them. In fact, a RISC CPU may actually have more instructions, e.g. separate ones for different cases, with the compiler being given the responsibility of picking the right one, instead of the CPU figuring it out as it goes. > RISC does carry a penalty in that you're executing more instructions to get > something done, so your code space is larger; but, you hopefully have them scheduled > such that the whole task runs faster. This in another aspect, which I've mentioned before, behind the rise of RISC, which is the changing size and speed of main memory, relative to the CPU. Simpler instructions are faster, but a given task will need more of them. This is acceptable if the memory can supply them fast enough. If the memory bandwidth is less, more complex instructions make sense, to get more out of the limited bandwidth. Also, if memory is of limited capacity, or expensive, then more complex instructions make sense, since more can be done with a fixed amount of memory. (The PDP-11 still scores very high in code density.) This too, however, has been overtaken by the march of technology. Still, the basic idea of RISC still applies; make the CPU clock rate as fast as possible by making the instructions simple, and let software deal with the resulting issues. Noel
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/15/19 3:40 PM, ben via cctalk wrote: > On 6/15/2019 8:47 AM, Stefan Skoglund via cctalk wrote: > >> With VAX 11/780 and S/360 involved ? I don't think so soo >> the Cyber series and 709(4) could be interesting. > > Well the early 1960's was the rise of BIG IRON that had REAL POWER > and that led to people thinking about high level languages and Computer > Science in general. We got PL/I (USA) and ALGOL (Every where ELSE) > that is a realy hard to compile into effective code. CISC design is > now needed to handle the 'extended features'. C was simmpler, > but still hand many features. RISC came along only because Compilers > could only generate SIMPLE instructions, that matched the RISC format. I'm not completely sure I'd agree with that assessment. Heck, we talked to the hardware design people to add/modify CISC instructions to fit the compiler needs. RISC had a benefit not so much for compiler work, but that a greater issue rate with the optimization and scheduling tasks left to the compiler (or programmer) rather than the hardware. I'll posit that RISC offers little gain on simple unified ALU CPUs or a CPU with a small register file. Where are are pipelined, segmented and multiple functional units, RISC starts to shine, provided that the register file is large enough and the instruction issue rate is fast enough. For what it's worth, the number of instructions in the ISA does not define RISC, but rather that the instructions execute quickly. Some RISC implementations have large instruction sets. In fact, RISC does carry a penalty in that you're executing more instructions to get something done, so your code space is larger; but, you hopefully have them scheduled such that the whole task runs faster. A related subject of "let the compiler do it" is VLIW. --Chuck
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/15/2019 8:47 AM, Stefan Skoglund via cctalk wrote: With VAX 11/780 and S/360 involved ? I don't think so soo the Cyber series and 709(4) could be interesting. Well the early 1960's was the rise of BIG IRON that had REAL POWER and that led to people thinking about high level languages and Computer Science in general. We got PL/I (USA) and ALGOL (Every where ELSE) that is a realy hard to compile into effective code. CISC design is now needed to handle the 'extended features'. C was simmpler, but still hand many features. RISC came along only because Compilers could only generate SIMPLE instructions, that matched the RISC format. My 2 cents. Ben.
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/15/19 7:47 AM, Stefan Skoglund wrote: > > With VAX 11/780 and S/360 involved ? I don't think so soo > the Cyber series and 709(4) could be interesting. It's difficult to say exactly, because of the constraints on the definition. Or does something have to be RISC only if it came after the definition? One of the issues with much older systems is that register memory was very expensive--and the corollary, of course, is that memory in general was expensive and a bottleneck. So, for example, the IBM 7030, with all of its very advanced architecture, remains out of the picture, because of its single-accumulator architecture. I don't think I'd call a 7090 a RISC architecture, either. There are plenty of early simple-architecture systems, (e.g. IBM 1130) that fail to qualify under the RISC definition because of this. One detail about the CDC 6000 that escapes many people is that there are no condition codes for branches. Given a three-address architecture, there's no "compare" instruction either (absent the CMU add-on). If you want to compare, say, registers X1 and X2 for equality, your code might look like this: IX0 X1-X2 ZR X0,equal-target The peculiar advantage of this is that condition codes don't come into the picture for the purposes of instruction scheduling--one simply uses the normal result reservation mechanism. The "compare" (IX0) above, can be anywhere in the preceding instruction stream before the zero jump. --Chuck
Re: One of the deeper dives into RISC vs CISC I've seen
ons 2019-06-12 klockan 14:35 -0700 skrev Chuck Guzis via cctalk: > On 6/12/19 1:47 PM, alan--- via cctalk wrote: > > I especially appreciated he not only offered an opinion - his > > specific > > ideas on where the boarder between RISC and CISC was - but then > > provided > > an analysis of a bunch of processors based on those criteria and an > > analysis of the outliers that challenged his criteria. It's a well > > thought-out and explained opinion that just doesn't happen often on > > the > > Internet. > > > > I assume from RS/6000, he meant generally the Power gen 1 > > architecture. > > And IBM RT/PC he meant ROMP. I'm pretty sure Alpha was well > > established > > when he wrote the analysis. Would have been nice to see that > > included. > > If I had more time, I'd research it. Maybe SuperH and WE32 as > > well. > > > > Is the discussion restricted to microprocessors? > > --Chuck > With VAX 11/780 and S/360 involved ? I don't think so soo the Cyber series and 709(4) could be interesting.
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/12/19 1:47 PM, alan--- via cctalk wrote: > > I especially appreciated he not only offered an opinion - his specific > ideas on where the boarder between RISC and CISC was - but then provided > an analysis of a bunch of processors based on those criteria and an > analysis of the outliers that challenged his criteria. It's a well > thought-out and explained opinion that just doesn't happen often on the > Internet. > > I assume from RS/6000, he meant generally the Power gen 1 architecture. > And IBM RT/PC he meant ROMP. I'm pretty sure Alpha was well established > when he wrote the analysis. Would have been nice to see that included. > If I had more time, I'd research it. Maybe SuperH and WE32 as well. > Is the discussion restricted to microprocessors? --Chuck
Re: One of the deeper dives into RISC vs CISC I've seen
Alan, > I especially appreciated he not only offered an opinion - his specific > ideas on where the boarder between RISC and CISC was - but then provided > an analysis of a bunch of processors based on those criteria and an > analysis of the outliers that challenged his criteria. It's a well > thought-out and explained opinion that just doesn't happen often on the > Internet. It does happen quite a lot but is drowned out by the far larger volume of nonsense. > I assume from RS/6000, he meant generally the Power gen 1 architecture. > And IBM RT/PC he meant ROMP. I'm pretty sure Alpha was well established > when he wrote the analysis. Would have been nice to see that included. The text explains the situation in 1991 and the Alpha was released in 1992. -- Jecel
Re: One of the deeper dives into RISC vs CISC I've seen
I especially appreciated he not only offered an opinion - his specific ideas on where the boarder between RISC and CISC was - but then provided an analysis of a bunch of processors based on those criteria and an analysis of the outliers that challenged his criteria. It's a well thought-out and explained opinion that just doesn't happen often on the Internet. I assume from RS/6000, he meant generally the Power gen 1 architecture. And IBM RT/PC he meant ROMP. I'm pretty sure Alpha was well established when he wrote the analysis. Would have been nice to see that included. If I had more time, I'd research it. Maybe SuperH and WE32 as well. Thanks for sharing! +1 -Alan H. On 2019-06-12 13:45, Chuck Guzis via cctalk wrote: On Jun 12, 2019, at 11:59 AM, Liam Proven via cctalk wrote: Goes a bit over my head but may be of interest: https://userpages.umbc.edu/~vijay/mashey.on.risc.html There are fuzzy areas. Consider the ETA 10--a very RISC scalar unit that pretty much fulfills the criteria laid out, bolted onto a vector unit (all memory-memory).
Re: One of the deeper dives into RISC vs CISC I've seen
> On June 12, 2019 at 12:45 PM Alan Perry via cctalk > wrote: > > > Ok. Here is a second thank you. An interesting read. > > On Jun 12, 2019, at 9:58 AM, Liam Proven via cctalk > > wrote: > > > On Wed, 12 Jun 2019 at 18:55, David wrote: > > > > > > I found it most interesting, thanks for sending out the link. > > Oh good. I'm glad to hear that. One "thank you" makes it worth the while. > > :-) > > > > -- > > Liam Proven - Profile: https://about.me/liamproven > > Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com > > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > > UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 And a third. CISC VS RISC MINUS RELIGION -- rare
Re: One of the deeper dives into RISC vs CISC I've seen
On 6/12/19 10:14 AM, Paul Koning via cctalk wrote: > > >> On Jun 12, 2019, at 11:59 AM, Liam Proven via cctalk >> wrote: >> >> Goes a bit over my head but may be of interest: >> >> https://userpages.umbc.edu/~vijay/mashey.on.risc.html > > Nice. Still reading through it. > > I like his definition of RISC. It captures the key points. Interesting that > a substantial fraction of those criteria apply to the CDC 6000 architecture, > which some of us like to call out as the first RISC architecture. Sure, it > has only 3 x 8 registers, but when registers are built up out of discrete > transistors that's understandable. The performance considerations that drive > the RISC design approaches carry over quite nicely. There are fuzzy areas. Consider the ETA 10--a very RISC scalar unit that pretty much fulfills the criteria laid out, bolted onto a vector unit (all memory-memory). --Chuck
Re: One of the deeper dives into RISC vs CISC I've seen
Ok. Here is a second thank you. An interesting read. > On Jun 12, 2019, at 9:58 AM, Liam Proven via cctalk > wrote: > >> On Wed, 12 Jun 2019 at 18:55, David wrote: >> >> I found it most interesting, thanks for sending out the link. > > Oh good. I'm glad to hear that. One "thank you" makes it worth the while. :-) > > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: One of the deeper dives into RISC vs CISC I've seen
> On Jun 12, 2019, at 11:59 AM, Liam Proven via cctalk > wrote: > > Goes a bit over my head but may be of interest: > > https://userpages.umbc.edu/~vijay/mashey.on.risc.html Nice. Still reading through it. I like his definition of RISC. It captures the key points. Interesting that a substantial fraction of those criteria apply to the CDC 6000 architecture, which some of us like to call out as the first RISC architecture. Sure, it has only 3 x 8 registers, but when registers are built up out of discrete transistors that's understandable. The performance considerations that drive the RISC design approaches carry over quite nicely. paul
Re: One of the deeper dives into RISC vs CISC I've seen
On Wed, 12 Jun 2019 at 18:55, David wrote: > > I found it most interesting, thanks for sending out the link. Oh good. I'm glad to hear that. One "thank you" makes it worth the while. :-) -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: One of the deeper dives into RISC vs CISC I've seen
I found it most interesting, thanks for sending out the link. David > On Jun 12, 2019, at 8:59 AM, Liam Proven via cctalk > wrote: > > Goes a bit over my head but may be of interest: > > https://userpages.umbc.edu/~vijay/mashey.on.risc.html > > -- > Liam Proven - Profile: https://about.me/liamproven > Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com > Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven > UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
