4 ms·

Anyone else reminded of FX!32 on Windows NT for Alpha? https://en.wikipedia.org/wiki/FX!32 https://en.wikipedia.org/wiki/FX!32

mrbill 10y ago
Or the built-in ability to run 16-bit DOS/Windows apps on NT4 running on MIPS Magnum R4000. I had one for a while and it was rather nifty at the time... And then, as you mention, FX!32 for running 32-bit apps (slowly) on NT/Alpha - I had it running on a Multia for a while. Those were some fun tiny machines.
- glandium 10y ago
  A friend had an EV5 (iirc), and performance wasn't too bad for the time. FX!32 was actually pretty fast all things considered.
  - mrbill 10y ago
    It would have been interesting to see how the QuickTransit[1] tech would have evolved, had IBM not bought and basically killed it. Apple used it (as "Rosetta") to run PPC binaries on x86, but it supported other CPU architectures, both as emulated platform and native targets. [1] https://en.wikipedia.org/wiki/QuickTransit https://en.wikipedia.org/wiki/QuickTransit
ethanpil 10y ago
I remember reading somewhere that Bill Gates used a Windows NT Alpha workstation as his desktop...
groovy2shoes 10y ago
I miss Alpha. Such a good arch. I wish Intel would do something with it, though I know they never will because there's really no market for it. I'd do something drastic to get my hands on an Alpha system in a Raspberry Pi form factor, though... or an Alpha laptop, or desktop, or Chromebook, or tablet, or server, or... Last time I checked, there wasn't even a working emulator for Alpha. I've been thinking about trying my hand at it, if only I had the time and the resources...
- anarazel 10y ago
  Honest question: why? Maybe I'm focused to much on the memory model, but from my POV the support weak coherency makes Alpha uninteresting.
  - andreiw 10y ago
    And yet a weaker memory model (as well as explicit cache and TLB maintenance) remove a major glass ceiling from both theoretical chip performance, practical perf/watt and silicon design and manufacure costs.
  - KMag 10y ago
    Adding to andriew's comment, x86's more strict memory model reduces the hardware's flexibility and enforces a more strict ordering than usually required. If you think you really need the x86 memory model, you're probably doing something wrong, but can get it (at significant cost) by adding lots of memory fences. The Alpha was also interesting in that it tried extremely hard to avoid saddling itself or future versions with legacy baggage. Unlike x86, ARM, MIPS, POWER, PA-RISC, SuperH, etc., Alpha was designed without a legacy support 32-bit addressing mode. Of course, if you link against a malloc implementation that stays below the 4 GB boundary, you can use JVM-like pointer compression. (If you need to support heap objects with pointers to the stack, you'll of course also need your stack allocated below the 4 GB boundary.) A lot of pointer-heavy code, however, can be rewritten to use 32-bit array indexes instead. They tried to get away without single-byte load or store instructions (many string manipulations don't really act on single bytes), though they were added in a later revision. A friend hired to write compilers for DEC shortly before the Compaq buyout told me that hardware engineers had to show simulated benchmark improvements when arguing for new instructions. They pushed back hard to keep valuable instruction space from becoming a junkyard of legacy instructions. As mentioned, they made as few memory guarantees as practical and forced applications to use memory fence instructions to make their needs explicit to the processor. This left them more flexibility in implementing later models. The firmware (PAL Code) was almost a hypervisor/nanokernel, with the OS kernel making calls to the PAL Code. The PAL Code version used for Tru64 UNIX/Linux implemented just two protection rings, while the PAL Code version used with OpenVMS emulated more protection rings. As you remember, as long as access violations trap to the most privileged ring, you can emulate an arbitrary number of rings between the least and most privileged rings.

mrbill 10y ago

Or the built-in ability to run 16-bit DOS/Windows apps on NT4 running on MIPS Magnum R4000. I had one for a while and it was rather nifty at the time... And then, as you mention, FX!32 for running 32-bit apps (slowly) on NT/Alpha - I had it running on a Multia for a while. Those were some fun tiny machines.

glandium 10y ago
A friend had an EV5 (iirc), and performance wasn't too bad for the time. FX!32 was actually pretty fast all things considered.
- mrbill 10y ago
  It would have been interesting to see how the QuickTransit[1] tech would have evolved, had IBM not bought and basically killed it. Apple used it (as "Rosetta") to run PPC binaries on x86, but it supported other CPU architectures, both as emulated platform and native targets. [1] https://en.wikipedia.org/wiki/QuickTransit https://en.wikipedia.org/wiki/QuickTransit

ethanpil 10y ago

I remember reading somewhere that Bill Gates used a Windows NT Alpha workstation as his desktop...

groovy2shoes 10y ago

I miss Alpha. Such a good arch. I wish Intel would do something with it, though I know they never will because there's really no market for it. I'd do something drastic to get my hands on an Alpha system in a Raspberry Pi form factor, though... or an Alpha laptop, or desktop, or Chromebook, or tablet, or server, or... Last time I checked, there wasn't even a working emulator for Alpha. I've been thinking about trying my hand at it, if only I had the time and the resources...

anarazel 10y ago
Honest question: why? Maybe I'm focused to much on the memory model, but from my POV the support weak coherency makes Alpha uninteresting.
- andreiw 10y ago
  And yet a weaker memory model (as well as explicit cache and TLB maintenance) remove a major glass ceiling from both theoretical chip performance, practical perf/watt and silicon design and manufacure costs.
- KMag 10y ago
  Adding to andriew's comment, x86's more strict memory model reduces the hardware's flexibility and enforces a more strict ordering than usually required. If you think you really need the x86 memory model, you're probably doing something wrong, but can get it (at significant cost) by adding lots of memory fences. The Alpha was also interesting in that it tried extremely hard to avoid saddling itself or future versions with legacy baggage. Unlike x86, ARM, MIPS, POWER, PA-RISC, SuperH, etc., Alpha was designed without a legacy support 32-bit addressing mode. Of course, if you link against a malloc implementation that stays below the 4 GB boundary, you can use JVM-like pointer compression. (If you need to support heap objects with pointers to the stack, you'll of course also need your stack allocated below the 4 GB boundary.) A lot of pointer-heavy code, however, can be rewritten to use 32-bit array indexes instead. They tried to get away without single-byte load or store instructions (many string manipulations don't really act on single bytes), though they were added in a later revision. A friend hired to write compilers for DEC shortly before the Compaq buyout told me that hardware engineers had to show simulated benchmark improvements when arguing for new instructions. They pushed back hard to keep valuable instruction space from becoming a junkyard of legacy instructions. As mentioned, they made as few memory guarantees as practical and forced applications to use memory fence instructions to make their needs explicit to the processor. This left them more flexibility in implementing later models. The firmware (PAL Code) was almost a hypervisor/nanokernel, with the OS kernel making calls to the PAL Code. The PAL Code version used for Tru64 UNIX/Linux implemented just two protection rings, while the PAL Code version used with OpenVMS emulated more protection rings. As you remember, as long as access violations trap to the most privileged ring, you can emulate an arbitrary number of rings between the least and most privileged rings.