Re: Motorola M88K books & user manuals (looking for)
> On Jan 1, 2019, at 10:17 PM, Jim Manley via cctalk > wrote: > > 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, ... 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. > ... > 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. 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. > 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. 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
Re: Motorola M88K books & user manuals (looking for)
On 1/1/19 7:17 PM, Jim Manley via cctalk wrote: > RISC was never just about compiler and hardware simplification for improved > performance of the most frequently-executed instructions. John Cocke is rolling over in his grave.
Re: Motorola M88K books & user manuals (looking for)
On Tue, Jan 1, 2019 at 7:18 PM Jim Manley via cctalk wrote: > 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. > Windows Phones were almost entirely (if not completely) based on MIPS and ARM processors. > > 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. OK... what does this have to do with RISC? > 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? Yep. That sure was a thing that existed. > 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? > So should I be running Excel on an IoT door lock, then? I'm confused. Were we talking about RISC? > > 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. > Good thing RISC solves all of these... uh, problems, then. You should probably send this mail to Microsoft so they can change their ways. > > 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. > Yes, as you say this is in no way a problem specific to any given architecture, it's endemic across many processor implementations that involve speculative execution. What exactly is your point? - Josh
Re: Motorola M88K books & user manuals (looking for)
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.
Re: Motorola M88K books & user manuals (looking for)
> On Jan 1, 2019, at 2:35 PM, 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. > > yup. I am a 68k programmer so I know what you mean. > the 68k is more comfortable to be programmed in assembly, and even the > EA modes (especially in the 68020 and CPU32) help a lot. > > unfortunately, the 68K is very complex to be designed, and the first > 68020 used microcode, which is a no-go for modern designs. 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
Re: Motorola M88K books & user manuals (looking for)
> On Jan 1, 2019, at 2:00 PM, ben via cctalk wrote: > > On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote: >> hi >> on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1). >> We are using the MIPS R2K and the RISC-V as the reference. >> In the end, it will be implemented in HDL -> FPGA. >> The page on DTB is related to a software emulator (written in C) for >> the whole system. CPU + RAM + ROM + UART, etc. so we can test and our >> ISA more comfortably. >> As a second reference, I'd like to consider the first Motorola RISC: >> 88K, which is very elegant and neat ISA; unfortunately, I have >> difficulties at finding user manuals and books about it. >> If someone wants to sell me a copy, it will be appreciated! >> Thanks and happy new year! > > 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. Huh? I don’t understand the 1 pass compiler statement requiring RISC. I was doing 1 pass compilers in the mid-to-late 70’s (well before RISC). So I’m not sure what you’re talking about. It also depends upon what you mean by “1 pass”. Most compilers nowadays make only one pass over the source but will make multiple passes over the intermediate form before finally generating code (even then it may make another pass over the resulting generated code for peep-hole optimizations. RISC is actually nice for a compiler because it’s simple and fairly regular (hard to actually generate code automatically for complex instructions) and RISC has a large number of registers. However, modern CPUs are all out-of-order execution with register renaming with ridiculous numbers of registers (I think current Intel Core x CPUs have 192+ registers for register renaming where the visible number of registers is 8). It also allows for speculative execution (following multiple paths through the code until the data required for the various decision points is finally available). > > 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. Deep pipelines are needed to get clock speeds up so that timing can be met. The problem with deep pipelines is that when any sort of exception (interrupts, etc) happen, there’s a lot of state that gets flushed and then restarted when the exception handling completes. Pipelines (especially if they’re not fixed depth for all operations) means that simple operations (those that require a minimum number of pipeline stages) can be completed quickly where as complex operations that require either a lot of logic or time to complete can be broken up in to multiple stages. This allows a higher clock rate and allows for the simple operations to be completed more quickly than if there was a very shallow pipeline. TTFN - Guy
Re: Motorola M88K books & user manuals (looking for)
On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote: hi on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1). We are using the MIPS R2K and the RISC-V as the reference. In the end, it will be implemented in HDL -> FPGA. The page on DTB is related to a software emulator (written in C) for the whole system. CPU + RAM + ROM + UART, etc. so we can test and our ISA more comfortably. As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. If someone wants to sell me a copy, it will be appreciated! Thanks and happy new year! 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.
Re: Motorola M88K books & user manuals (looking for)
Any chance of getting the list to add 'monthly digest' format? 12 doses of this a year would be about right. On 1/1/19 9:13 AM, Carlo Pissant wrote: > yes, but I prefer a printed copy > >> I have difficulties at finding user manuals and books about it. >>> >> http://bitsavers.org/components/motorola/88000 >>
Re: Motorola M88K books & user manuals (looking for)
On 2019-01-01 1:08 PM, Fred Cisin via cctalk wrote: > On Tue, 1 Jan 2019, Josh Dersch via cctalk wrote: >> There are these things called "printers." > > A lot of them are getting on in years and getting kinda cranky. 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
Re: Motorola M88K books & user manuals (looking for)
On Tue, 1 Jan 2019, Josh Dersch via cctalk wrote: There are these things called "printers." A lot of them are getting on in years and getting kinda cranky. There has been a decline in their business due to copy machines for small to medium volume, and overseas competition. But some of them would gladly help newcomers learn how to operate a press. Oh. Maybe you meant computer printers. There are little ones, such as the Centronics 101 (RS232, or a parallel data interface using a 36 pin Blue-ribbon connector), that will fit on a sturdy table. Recommend the 101A; 9x7 matrix is nicer than 5x7 http://bitsavers.trailing-edge.com/pdf/centronics/37400020G_Centronics_Model_101A_Printer_Technical_Manual_Dec1974.pdf Some of the new fancy computer printers even have lower case! Although excruciatingly slow (14.8 CPS, and do NOT exceed that!), the I/O Selectric is versatile. In many offices, newbies will be welcomed by somebody putting in the APL typeball.
Re: Motorola M88K books & user manuals (looking for)
I am looking for original printed copy Il giorno mar 1 gen 2019 alle ore 18:31 Josh Dersch via cctalk ha scritto: > > There are these things called "printers." > > - Josh > > On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: > > yes, but I prefer a printed copy > > > > Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk > > ha scritto: > >> > >> > >> On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > >>> hi > >>> As a second reference, I'd like to consider the first Motorola RISC: > >>> 88K, which is very elegant and neat ISA; unfortunately, I have > >>> difficulties at finding user manuals and books about it. > >>> > >> http://bitsavers.org/components/motorola/88000 > >>
Re: Motorola M88K books & user manuals (looking for)
There are these things called "printers." - Josh On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: hi As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. http://bitsavers.org/components/motorola/88000
Re: Motorola M88K books & user manuals (looking for)
There are these things called "printers." - Josh On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: hi As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. http://bitsavers.org/components/motorola/88000
Re: Motorola M88K books & user manuals (looking for)
yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: > > > > On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > > hi > > > As a second reference, I'd like to consider the first Motorola RISC: > > 88K, which is very elegant and neat ISA; unfortunately, I have > > difficulties at finding user manuals and books about it. > > > http://bitsavers.org/components/motorola/88000 >
Re: Motorola M88K books & user manuals (looking for)
On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > hi > As a second reference, I'd like to consider the first Motorola RISC: > 88K, which is very elegant and neat ISA; unfortunately, I have > difficulties at finding user manuals and books about it. > http://bitsavers.org/components/motorola/88000
Re: Motorola M88K books & user manuals (looking for)
Well as it turns out I have several boxes of databooks that I need to get catalogued and listed. (My decluttering task was supposed to be finished *last* year ...) Here we have: MC88100 RISC Microprocessor User's Manual MC88200 Cache/Memory Management Unit User's Manual Please pay shipping from Texas 78746. Whatever else you want to pay on top of that will be used exclusively to buy more high-quality beer :-) mcl
