On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: http://bitsavers.org/components/motorola/88000

There are these things called "printers." - Josh On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote:

I am looking for original printed copy Il giorno mar 1 gen 2019 alle ore 18:31 Josh Dersch via cctalk <cctalk at classiccmp.org> ha scritto:

On 2019-01-01 1:08 PM, Fred Cisin via cctalk wrote: Speaking of which, it's a new year, can we not prolong this thread into a 100 post monster. Book was requested, book was offered, all poster's options are covered, surely, by now. --T

On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote: I was never a fan of RISC architecture as does not fit the standard high level language model. Everybody wants a 1 pass compiler, thus the RISC model. If you are doing your own RISC model, you might consider a model that supports Effective addressing better since we have got the point where fetching the data is taking longer than processing it. The other thought is the pipeline seems has too high speed of a clock, what is the use a fast clock, if you got one or two gates of logic between your clocks. Gate and line driving speed ratios remind me of the Vacuum tube era of computing. I have FPGA card here, as using it to develop a NICE 20 bit TTL computer.I just ordered a few 7437's from the Ukraine, so this might be the last year to stock up needed 74XXX spares. Good luck with your design. Ben.

Umm. Says who? Intel x86 CPUs makes *heavy* use of microcode. So do a number of other processors (IBM S/370, et al). The ISAs may be old but I would argue that in both examples, the underlying designs are *very* modern. TTFN - Guy

RISC was never just about compiler and hardware simplification for improved performance of the most frequently-executed instructions. It's also been front-and-center in low-power (e.g., mobile) and embedded (now including Internet of Things) applications, which each far outpace the number of devices produced for traditional desktop and top-end computing (high-performance computing, originally aka supercomputers). It's a big reason why no one is using Windows Phones, or IoT components based on x86/x64 hardware today. Microsoft and Intel made big bets on their accumulated legacy code and hardware bases being shoehorned into everything imaginable, with what should have been obviously poor results for most of the application areas pursued. Anyone remember trying to run Excel on a Windows Phone with largely the same mess of menus, submenus, subsubmenu items, dialogues, etc., as on the desktop version? IoT devices like door locks don't need scads of registers, instructions, caches, etc., and can you imagine an Apple or Galaxy Watch with cell capability running on a multicore x64 processor with a battery smaller than that for a vehicle? A Blue Screen of Death is truly fatal for a product that depends on an embedded device, like an ATM in the middle of dispensing over half a grand in cash, a DVR in a satellite TV receiver that requires upwards of ten minutes to restart and get back to where the viewer was (minus the permanently lost live recorded cache), or a self-driving vehicle at any speed above zero. Yes, BSoDs continue to happen when memory runs out before users run out of things they want to do all at one time. Windows systems can still routinely get to the point where it becomes impossible to dismiss a modal dialog, close a tab or window, bring up the Start menu or Task Manager, or other critical user interface element actions that should always be instantly accessible. This lack of attention to user experience is endemic to the Wintel way of doing things, going back deep in the estimated ~100 million lines in their code base. The x86/x64 instruction set complexity hasn't been helpful in reducing the security vulnerability of software running on those architectures, either. The multiple parallel pipelines that make possible speculative execution of a number of branches before associated decisions are computed, have resulted in the whole new class of security vulnerabilities such as Meltdown, Foreshadow, and Spectre. This isn't limited to x86/x64, however, as the most recent multicore ARM processors have also fallen victim to such issues, they've just been late to the game as the most advanced (and complex) features have been pursued (somewhat for me-too marketing purposes), so fewer families/generations have been affected.

On 1/1/19 7:17 PM, Jim Manley via cctalk wrote: John Cocke is rolling over in his grave.

I think you may be mixing up where we ended up vs. where we started. Mobile applications were science fiction when RISC started. Especially if you take the view that the first RISC architecture machines were designed before the term was invented -- for example, it would be easy to make the argument that the CDC 6600 is a RISC machine. As for compiler simplification, I'm not so sure. A CISC machine like VAX makes compilers easy because the instruction set is so regular and so nicely matches the higher level operations. RISC instructions less so. Then again, most machines predating the PDP-11 are more like RISC in their instruction set limits and compilers cope with that. The biggest difference I can see is that by the time RISC became a buzzword, optimizers were good enough that hand-coding assembly language became uncommon. And for many RISC architectures -- consider Alpha for example, never mind Itanium -- that is crucial because hand-coding is just painfully hard. Certainly, but in almost all cases this is a question of software quality and the designers' attitude to reliability and careful design. People have built reliable systems on CISC machines (VMS for example) and on machines that predate the term (AGC). They've also built unreliable systems on any of these architectures. Are you arguing that speculative instruction is a marketing toy? I thought it's a feature that delivers real performance gains. And it's widely implemented on high end machines of both flavors for that reason. I can believe it's more significant on x86 because of its more complex pipelines but the RISC pipe at this point is also so much faster than memory that it's interesting there too. And it's done there, too. The issue doesn't appear on many other RISC architectures because those don't aim to the top performance levels but rather at other market niches. So Spectre is universal. Meltdown is not; that one comes from an Intel decision to delay page access checking, and wasn't implemented by others. There is no good reason to have a Meltdown vulnerability in any CPU architecture. But Spectre is fundamental to speculative execution. You can avoid it either by software workarounds in the kernel that are fairly cheap, or by adding hardware mechanisms to close off timing channels. The latter tends to be hard, though there might be other reasons why it's worth trying. paul