Motorola M88K books & user manuals (looking for)

Josh Dersch derschjo at gmail.com
Tue Jan 1 21:48:17 CST 2019


On Tue, Jan 1, 2019 at 7:18 PM Jim Manley via cctalk <cctalk at classiccmp.org>
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


More information about the cctalk mailing list