4 ms·

I want to get back to porting Chromium, because when AMD tries the second time around [0] (edit: maybe third time around, as wmf below points out) to do a pin-c

I want to get back to porting Chromium, because when AMD tries the second time around [0] (edit: maybe third time around, as wmf below points out) to do a pin-compatible RISC (maybe this time it's one of the Zen 4 platforms or whatever), I want to pop the phattest GPU in that thing and enjoy. [0]: https://www.extremetech.com/computing/181867-amds-project-skybridge-new-arm-and-x86-chips-that-are-pin-compatible https://www.extremetech.com/computing/181867-amds-project-sk...

wolfgke 8y ago
> because when AMD tries the second time around [0] to do a pin-compatible RISC (maybe this time it's one of the Zen 4 platforms or whatever), [...] > [0]: https://www.extremetech.com/computing/181867-amds-project-skybridge-new-arm-and-x86-chips-that-are-pin-compatible https://www.extremetech.com/computing/181867-amds-project-sk... The mentioned Project Skybridge is dead: https://wccftech.com/amd-cancelled-skybridge-glofo-terminated-20nm/ https://wccftech.com/amd-cancelled-skybridge-glofo-terminate...
- microcolonel 8y ago
  That's why I said tries the second time around, not succeeds yet again.
  - wolfgke 8y ago
    > That's why I said tries the second time around, not succeeds yet again. OK, point taken. But do you have evidence that AMD has plans to do a second attempt?
yjftsjthsd-h 8y ago
That's beautiful. Did it fall through?
- microcolonel 8y ago
  As wolfgke pointed out, yeah. They claim that it was because of issues with the availability of the process they intended to manufacture on, and I'd sure like to believe that that was all it was.
wmf 8y ago
Before that there was going to be an IBM Power chip to fit in an Opteron socket.
- classichasclass 8y ago
  I don't remember this. Source/details?
  - wmf 8y ago
    https://www.theregister.co.uk/2006/09/22/ibm_power7_opteron/ https://www.theregister.co.uk/2006/09/22/ibm_power7_opteron/
    - classichasclass 8y ago
      Fascinating! Thanks!
dfox 8y ago
Actually it would be fourth time around, as the K7 Athlons/Thunderbirds were electrically compatible with Alpha 21264, although OK, it was not pin nor mechanically compatible as Alpha CPUs need additional directly attached serial (EE)PROM with boot PALcode/microcode/firmware/initial contents of L2 cache. On the other hand on typical lowend Alpha systems this PROM contained complete enought i386 emulator that it could run PC-style BIOS as part of hardware initialization (ie. work with ISA/PCI cards with x86 code in PROMs), somewhat ugly and scary is the fact that large part of the firmware variant needed for booting Windows NT was actually i386 code running in said emulator. (And then there is Linux, which in the somewhat Tour de force way does not care about the underlying PALcode API) --- ) Alpha is to a large extent the ultimate RISC architecture that on the user side does not have any implicit sideefects of instructions and syscalls and interrupts work by simply exchanging two register sets. The idea is that there is PALcode which is the only privileged code running on the CPU, which then keeps track of whether whatever is currently running in userspace is user or kernel code and passes messages between these, to some extent it is microkernel as part of the CPU, which you additionally can as an OS modify (in reality you could not, because the PALcode is amalgamation of both the OS semantics, quirks of the actual CPU implementation and the actual motherboard in given system)
- monocasa 8y ago
  I was under the impression that Linux did care about the underlying PALcode, requiring the version originally meant for Tru64?
  - dfox 8y ago
    IIRC it is slightly more complex: the Tru64 callPAL API is the common subset of all the three variants (VMS/Tru64/NT), but the NT/AlphaBIOS has slightly incompatible ABI which Linux can detect and work around. And also IIRC original Linux port to Alpha expected the NT PALcode, which makes sense given the fact that DEC sold systems that didn't have SRM in PROM (ie. Multia and a-series PWS) and thus only supported NT or Linux.
- FullyFunctional 8y ago
  RISC-V is very VERY close to Alpha in this respect. There are no flags, everything is communicated via registers (which makes semantics clean and dynamic scheduling cheaper), and the equivalent of PALcode exist (called platform specific SBI calls, executing in M-mode). IMhO, RISC-V is slightly better than Alpha on a many fronts: the conditional branches which compares two registers would take two instructions on Alpha (on the critical path), RISC-V code density is better with compressed, the encoding is slightly cheaper for hardware, it ISA is more forward-looking/extensible, oh and it's open of course. The only thing I miss are the POPC/CTZ/CLZ instructions, but the B set will include them for implementations that have it. UPDATE: more RISC-V upsides
spitfire 8y ago
Back in the 1990's when the AMD Athlon first came out Slot 1 was supposed to share the bus with the DEC Alpha. The idea was you replace the bios and you could use the same motherboard for both DEC Alpha or AMD Athlon. Of course, that never happened. But people keep wishing.

wolfgke 8y ago

> because when AMD tries the second time around [0] to do a pin-compatible RISC (maybe this time it's one of the Zen 4 platforms or whatever), [...] > [0]: https://www.extremetech.com/computing/181867-amds-project-skybridge-new-arm-and-x86-chips-that-are-pin-compatible https://www.extremetech.com/computing/181867-amds-project-sk... The mentioned Project Skybridge is dead: https://wccftech.com/amd-cancelled-skybridge-glofo-terminated-20nm/ https://wccftech.com/amd-cancelled-skybridge-glofo-terminate...

microcolonel 8y ago
That's why I said tries the second time around, not succeeds yet again.
- wolfgke 8y ago
  > That's why I said tries the second time around, not succeeds yet again. OK, point taken. But do you have evidence that AMD has plans to do a second attempt?

yjftsjthsd-h 8y ago

That's beautiful. Did it fall through?

microcolonel 8y ago
As wolfgke pointed out, yeah. They claim that it was because of issues with the availability of the process they intended to manufacture on, and I'd sure like to believe that that was all it was.

wmf 8y ago

Before that there was going to be an IBM Power chip to fit in an Opteron socket.

classichasclass 8y ago
I don't remember this. Source/details?
- wmf 8y ago
  https://www.theregister.co.uk/2006/09/22/ibm_power7_opteron/ https://www.theregister.co.uk/2006/09/22/ibm_power7_opteron/
  - classichasclass 8y ago
    Fascinating! Thanks!

dfox 8y ago

Actually it would be fourth time around, as the K7 Athlons/Thunderbirds were electrically compatible with Alpha 21264, although OK, it was not pin nor mechanically compatible as Alpha CPUs need additional directly attached serial (EE)PROM with boot PALcode/microcode/firmware/initial contents of L2 cache. On the other hand on typical lowend Alpha systems this PROM contained complete enought i386 emulator that it could run PC-style BIOS as part of hardware initialization (ie. work with ISA/PCI cards with x86 code in PROMs), somewhat ugly and scary is the fact that large part of the firmware variant needed for booting Windows NT was actually i386 code running in said emulator. (And then there is Linux, which in the somewhat Tour de force way does not care about the underlying PALcode API) --- ) Alpha is to a large extent the ultimate RISC architecture that on the user side does not have any implicit sideefects of instructions and syscalls and interrupts work by simply exchanging two register sets. The idea is that there is PALcode which is the only privileged code running on the CPU, which then keeps track of whether whatever is currently running in userspace is user or kernel code and passes messages between these, to some extent it is microkernel as part of the CPU, which you additionally can as an OS modify (in reality you could not, because the PALcode is amalgamation of both the OS semantics, quirks of the actual CPU implementation and the actual motherboard in given system)

monocasa 8y ago
I was under the impression that Linux did care about the underlying PALcode, requiring the version originally meant for Tru64?
- dfox 8y ago
  IIRC it is slightly more complex: the Tru64 callPAL API is the common subset of all the three variants (VMS/Tru64/NT), but the NT/AlphaBIOS has slightly incompatible ABI which Linux can detect and work around. And also IIRC original Linux port to Alpha expected the NT PALcode, which makes sense given the fact that DEC sold systems that didn't have SRM in PROM (ie. Multia and a-series PWS) and thus only supported NT or Linux.
FullyFunctional 8y ago
RISC-V is very VERY close to Alpha in this respect. There are no flags, everything is communicated via registers (which makes semantics clean and dynamic scheduling cheaper), and the equivalent of PALcode exist (called platform specific SBI calls, executing in M-mode). IMhO, RISC-V is slightly better than Alpha on a many fronts: the conditional branches which compares two registers would take two instructions on Alpha (on the critical path), RISC-V code density is better with compressed, the encoding is slightly cheaper for hardware, it ISA is more forward-looking/extensible, oh and it's open of course. The only thing I miss are the POPC/CTZ/CLZ instructions, but the B set will include them for implementations that have it. UPDATE: more RISC-V upsides

spitfire 8y ago

Back in the 1990's when the AMD Athlon first came out Slot 1 was supposed to share the bus with the DEC Alpha. The idea was you replace the bios and you could use the same motherboard for both DEC Alpha or AMD Athlon. Of course, that never happened. But people keep wishing.