[HN Gopher] A Real PowerBook: The Macintosh Application Environm...
       ___________________________________________________________________
        
       A Real PowerBook: The Macintosh Application Environment on a Pa-
       RISC Laptop
        
       Author : todsacerdoti
       Score  : 121 points
       Date   : 2025-08-03 06:38 UTC (16 hours ago)
        
 (HTM) web link (oldvcr.blogspot.com)
 (TXT) w3m dump (oldvcr.blogspot.com)
        
       | Telemakhos wrote:
       | RISC Mac? Why am I reminded of the original Mission Impossible
       | movie?
        
         | raddan wrote:
         | If you scroll down long enough there actually is some
         | discussion of the (unbadged) Macs that appear in Mission
         | Impossible!
        
         | bluedino wrote:
         | 686 protoypes with the artificial intelligence RISC chips
        
       | esafak wrote:
       | Ha, PA-RISC! I remember faxing HP as a teen for a brochure about
       | it. Back when HP was a contender :(
        
         | classichasclass wrote:
         | (author) I thought PA-RISC could go a lot further. It had good
         | performance and a fairly sane ISA, and HP put a lot of work
         | into it. Dropping it for Itanic was one of HP's poorest
         | decisions, because compilers just weren't sophisticated enough
         | to make EPIC VLIW efficient, and arguably still aren't. The
         | issue about the "one instruction per cycle" limit got addressed
         | in a different way.
        
           | jeffbee wrote:
           | I mean, the performance was better than "fair". Nothing could
           | touch it including Alpha. They abandoned it right at the top
           | of their game.
        
           | jimmaswell wrote:
           | I wonder if we could make an LLM or other modern machine
           | learning framework finally figure out how to compile to
           | Itanic in an optimized fashion.
        
             | o11c wrote:
             | No, VLIW is fundamentally a flawed idea; OoO is mandatory.
             | "We need better compilers" is purely Intel marketing
             | apologia.
        
               | whaleofatw2022 wrote:
               | Isn't VILW how a number of GPUs worked internally? That
               | said GPU isn't the same as GPC
        
               | classichasclass wrote:
               | Some older ones, yeah (TeraScale comes to mind) but
               | modern ones are more like RISC with whopping levels of
               | SIMD. It turns out that VLIW was hard for them too.
        
               | buildbot wrote:
               | Yes, as other noted AMD used VLIW for terscale in the
               | 2000-6000 series. https://en.wikipedia.org/wiki/TeraScale
               | _(microarchitecture)
               | 
               | They are used in a lot of DSP chips too, where you
               | (hopefully) have very simple branching if any and nice
               | data access patterns.
        
               | Sesse__ wrote:
               | And typically just fast RAM everywhere instead of caches,
               | so you don't have cache misses. (The flip side is that
               | you typically have very _little_ RAM.)
        
             | duskwuff wrote:
             | No. The problems involved are fundamental:
             | 
             | 1) Load/store latency is unpredictable - whenever you get a
             | cache miss (which is unpredictable*), you have to wait for
             | the value to come back from main memory (which is getting
             | longer and longer as CPUs get faster and memory latency
             | roughly stays the same). Statically scheduling around this
             | sort of unpredictable latency is extremely difficult;
             | you're better off doing it on the fly.
             | 
             | 2) Modern algorithms for branch prediction and speculative
             | execution are dynamic. They can make observations like
             | "this branch has been taken 15/16 of the last times we've
             | hit it, we'll predict it's taken the next time" which are
             | potentially workload-dependent. Compile-time optimization
             | can't do that.
             | 
             | *: if you could reliably predict when the cache would miss,
             | you'd use that to make a better cache replacement algorithm
        
           | ndiddy wrote:
           | HP, DEC/Compaq, and SGI all made the decision to drop their
           | various bespoke architectures for Itanium years before
           | prototypes were available based solely on what Intel claimed
           | performance would be on paper. Even Sun and IBM made noise
           | about doing the same thing. Honestly, I think it was
           | inevitable that something like this would happen. By the late
           | 90s, it was starting to get too expensive for each individual
           | high-end server/workstation company to continue investing in
           | high-performance chip design and leading edge fabs to make
           | low-volume parts, so it made sense for all of them to
           | standardize on a common architecture. The mistake everyone
           | made was choosing Itanium to be the industry standard.
        
             | classichasclass wrote:
             | Yes, that's all true, but I blame HP more than the others
             | because a large part of what went into Itanium _came_ from
             | HP. They thought that with their simulation results they
             | would eclipse all other architectures with Itanic, and they
             | were way off base, junking an architecture that had room to
             | grow in the process. Even so, PA-RISC was still competitive
             | at least into the days of Mako, though they kind of phoned
             | it in with Shortfin (the last PA-8900).
        
         | sgt wrote:
         | As a teen, I needed help with an Alpha 21164, and I phoned
         | Compaq. This was a year after Compaq had bought Digital. But
         | they had absolutely zero interest in helping a teenager with
         | hardware they probably believed I had no business using.
        
       | ethan_smith wrote:
       | MAE was Apple's fascinating attempt to run Mac OS on Unix
       | workstations, essentially creating a compatibility layer that
       | translated Mac Toolbox calls to X11, allowing Unix users to run
       | Mac software without actual Apple hardware.
        
       ___________________________________________________________________
       (page generated 2025-08-03 23:01 UTC)