12 ms·

Here are some architectures that might interest you. Note these are links that lead to rabbit holes. 1. Transmeta: https://en.wikipedia.org/wiki/Transmeta http

Here are some architectures that might interest you. Note these are links that lead to rabbit holes. 1. Transmeta: https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta 2. Cell processor: https://en.wikipedia.org/wiki/Cell_(processor) https://en.wikipedia.org/wiki/Cell_(processor) 3. VAX: https://en.wikipedia.org/wiki/VAX https://en.wikipedia.org/wiki/VAX (Was unusual for it's time, but many concepts have since been adopted) 4. IBM zArchitecture: https://en.wikipedia.org/wiki/Z/Architecture https://en.wikipedia.org/wiki/Z/Architecture (This stuff is complete unlike conventional computing, particularly the "self-healing" features.) 5. IBM TrueNorth processor: https://open-neuromorphic.org/blog/truenorth-deep-dive-ibm-neuromorphic-chip-design/ https://open-neuromorphic.org/blog/truenorth-deep-dive-ibm-n... (Cognitive/neuromorphic computing)

Bluestein 2y ago
> Transmeta Whatever happened to them ... They had a somewhat serious go at being "third wheel" back in the early 2000s, mid 1990s? PS. Actually considered getting a Crusoe machine back in the day ...
- runjake 2y ago
  They released a couple processors with much lower performance than the market expected, shut that down, started licensing their IP to Intel, Nvidia, and others, and then got acquired.
- em-bee 2y ago
  i did get a sony picturebook with a transmeta processor. the problem was that as a consumer i didn't notice anything special about it. for transmeta to make it they would have had to either be cheaper or faster or use less power to be attractive for consumer devices.
  - Bluestein 2y ago
    I seem to recall them machines not being cheaper, which was my main hope at the time :)
    - em-bee 2y ago
      i got mine as a gift, so i don't remember the price, but i don't think it was cheap. however that would not even bother me. they would have at least had to be cheaper for manufacturers to make it worth it to put them into more devices.
- sliken 2y ago
  They had a great plan, that was promising, and Intel was focused entirely on the pentium-4, which had high clocks for bragging rights, long pipeline (related to the high clocks), and high power usage. However between Transmeta's idea and shipping a product Intel's Israel location came up with the Intel Core series. MUCH more energy efficienct, much better performance per clock, and ideal for lower power platforms like laptops. Sadly transmeta's no longer had a big enough advantage, sales decreased, and I heard many of the engineers ended up at Nvidia, which did use some of their ideas in a nvidia product.
  - Bluestein 2y ago
    > Sadly transmeta's no longer had a big enough advantage, sales decreased, and I heard many of the engineers ended up at Nvidia, which did use some of their ideas in a nvidia product. Funny how that came about. Talent finds a way, Now they're all sitting in a 3T ship.-
nrr 2y ago
For those really wanting to dig into z/Architecture: <https://www.ibm.com/docs/en/module_1678991624569/pdf/SA22-7832-13.pdf https://www.ibm.com/docs/en/module_1678991624569/pdf/SA22-78...> The Wikipedia link has it as its first reference, but it's honestly worth linking directly here. I highly recommend trying to get someone to give you a TSO/E account and picking up HLASM.
- skissane 2y ago
  I put MVS 3.8J in a Docker image: https://github.com/skissane/mvs38j https://github.com/skissane/mvs38j Not TSO/E rather just plain old TSO. Not HLASM rather its predecessor Assembler F (IFOX00). Still, if you get the hang of the 1970s version, the 2020s version is just adding stuff. And some of the stuff it is adding is less unfamiliar (like Unix and Java)
  - nrr 2y ago
    About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing and maybe the older pre-XA I/O architecture. Having a simulated 3033 running at 10+ MIPS is pretty nice though. (:
    - skissane 2y ago
      > About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing I've never used it, but there's a hacked up version that adds 31-bit addressing [0]. It is truly a hack though – porting 24-bit MVS to XA is a monumental task, not primarily due to address mode (you can always ignore new processor modes, just like how a 286-only OS will happily run on a 386 without realising it is doing so), but rather due to the fundamental incompatibility in the IO architecture. The "proper" way to do it would be to have some kind of hypervisor which translates 370 IO operations to XA – which already exists, and has so for decades, it is called VM/XA, but sadly under IBM copyright restrictions just like MVS/XA is. I suppose someone could always write their own mini-hypervisor that did this, but the set of people with the time, inclination and necessary skills is approximately (if not exactly) zero. So instead the hacky approach is to modify Hercules to invent a new hybrid "S/380" architecture which combines XA addressing with 370 IO. Given it never physically existed, I doubt Hercules will ever agree to upstream it. Also, IIRC, it doesn't implement memory protection/etc for above-the-line addresses, making "MVS/380" essentially a single-tasking OS as far as 31-bit code goes. But the primary reason for its existence is that GCC can't compile itself under 24-bit since doing so consumes too much memory, and for that limited purpose you'd likely only ever run one program at a time anyway. I guess the other way of solving the problem would been to have modify GCC to do application-level swapping to disk - which is what a lot of historical compilers did to fit big compiles into limited memory. But I guess making those kinds of radical changes to GCC is too much work for a hobby. Or pick a different compiler altogether – GCC was designed from the beginning for 32-bit machines, and probably alternatives would go better in very limited memory – but people had already implemented 370 code generation for GCC (contemporary GCC supports 64-bit and 31-bit; I don't think contemporary mainline GCC supports 24-bit code generation any more, but people use an old version or branch which did.) I wonder about OpenWatcom, since that's originally a 370 compiler, and I believe the 370 code generator is still in the source tree, although I'm not sure if anybody has tried to use it. [0] https://mvs380.sourceforge.net/ https://mvs380.sourceforge.net/
lormayna 2y ago
Why the Cell processor did not had success in AI/DL applications?
- crote 2y ago
  It was released a decade and a half too early for that, and at the time it was too weird and awkward to use to stay relevant once CUDA caught on.
  - mass_and_energy 2y ago
    This. CUDA handles a lot of overhead that the dev is responsible for on the Cell architecture. Makes you wonder what PS3 games would have looked like with CUDA-style abstraction of the Cell's capabilities
    - sillywalk 2y ago
      I don't know the details of CUDA, so this may not be a good comparison, but there were efforts to abstract Cell's weirdness. It wasn't for the PS3, but for supercomputers. In particular the Roadrunner which had both Operteron and Cell processors. It was called CellFS and was based on the 9p protocol from Plan 9. It says there was 10-15% overhead, which may not have worked for PS3 games. https://fmt.ewi.utwente.nl/media/59.pdf https://fmt.ewi.utwente.nl/media/59.pdf https://www.usenix.org/system/files/login/articles/546-mirtchovski.pdf https://www.usenix.org/system/files/login/articles/546-mirtc... http://doc.cat-v.org/plan_9/IWP9/2007/11.highperf.lucho.pdf http://doc.cat-v.org/plan_9/IWP9/2007/11.highperf.lucho.pdf
ramses0 2y ago
Excellent summary, add "Water Computers" to the mix for completeness. https://www.ultimatetechnologiesgroup.com/blog/computer-ran-on-water-1936/ https://www.ultimatetechnologiesgroup.com/blog/computer-ran-...
PaulHoule 2y ago
I wouldn't say the VAX was unusual even though it was a pathfinder in that it showed what 32-bit architectures were going to look like. In the big picture the 386, 68040, SPARC and other chips since then have looked a lot like a VAX, particularly in how virtual memory works. There's no fundamental problem with getting a modern Unix to run on a VAX except for all the details. Z is definitely interesting from it's history with the IBM 360 and its 24 bit address space. (24 bit micros existed in the 1980s such as the 286 but I never had one that was straightforward to program in 24 bit mode) which, around the time the VAX came out, got expanded to 31-bits https://en.wikipedia.org/wiki/IBM_System/370-XA https://en.wikipedia.org/wiki/IBM_System/370-XA
- skissane 2y ago
  > 24 bit micros existed in the 1980s such as the 286 but I never had one that was straightforward to program in 24 bit mode Making clear that we are talking about 24-bit physical or virtual addressing (machines with a 24-bit data word we’re quite rare, mainly DSPs, also some non-IBM mainframes like SDS 940): 286’s 16-bit protected mode was heavily used by Windows 3.x in Standard mode. And even though 386 Enhanced Mode used 32-bit addressing, from an application developer viewpoint it was largely indistinguishable from 286 protected mode, prior to Win32s. And then Windows NT and 95 changed all that. 286’s protected mode was also heavily used by earlier DOS extenders, OS/2 1.x, earlier versions of NetWare and earlier versions of Unix variants such as Xenix. Plus 32-bit operating systems such as Windows 9x/Me/NT/2000/XP/etc and OS/2 2.x+ still used it for backward compatibility when running older 16-bit software (Windows 3.x and OS/2 1.x) Other widely used CPU architectures with 24-bit addressing included anything with a Motorola 68000 or 68010 (32-bit addressing was only added with the 68020 onwards, while the 68012 had 31-bit addressing). So that includes early versions of classic MacOS, AmigaOS, Atari TOS - and also Apple Lisa, various early Unix workstations, and umpteen random operating systems which ran under 68K which you may have never heard of (everything from CP/M-68K to OS/9 to VERSAdos to AMOS/L). ARM1 (available as an optional coprocessor for the BBC Micro) and ARM2 (used in the earliest RISC OS systems) were slightly more than 24-bit, with 26-bit addressing. And some late pre-XA IBM mainframes actually used 26-bit physical addressing despite only having 24-bit virtual addresses. Rather similar to how 32-bit Intel processors ended up with 36-bit physical addressing via PAE
mass_and_energy 2y ago
The use of the Cell processor in the PlayStation 3 was an interesting choice by Sony. It was the perfect successor to the PS2's VU0 and VU1s, so if you were a game developer coming from the PS2 space and were well-versed in the concepts of "my programs job is to feed the VUs", you can scale that knowledge up to keep the cores of the Cell working. The trick seems to be in managing synchronization between them all

Bluestein 2y ago

> Transmeta Whatever happened to them ... They had a somewhat serious go at being "third wheel" back in the early 2000s, mid 1990s? PS. Actually considered getting a Crusoe machine back in the day ...

runjake 2y ago
They released a couple processors with much lower performance than the market expected, shut that down, started licensing their IP to Intel, Nvidia, and others, and then got acquired.
em-bee 2y ago
i did get a sony picturebook with a transmeta processor. the problem was that as a consumer i didn't notice anything special about it. for transmeta to make it they would have had to either be cheaper or faster or use less power to be attractive for consumer devices.
- Bluestein 2y ago
  I seem to recall them machines not being cheaper, which was my main hope at the time :)
  - em-bee 2y ago
    i got mine as a gift, so i don't remember the price, but i don't think it was cheap. however that would not even bother me. they would have at least had to be cheaper for manufacturers to make it worth it to put them into more devices.
sliken 2y ago
They had a great plan, that was promising, and Intel was focused entirely on the pentium-4, which had high clocks for bragging rights, long pipeline (related to the high clocks), and high power usage. However between Transmeta's idea and shipping a product Intel's Israel location came up with the Intel Core series. MUCH more energy efficienct, much better performance per clock, and ideal for lower power platforms like laptops. Sadly transmeta's no longer had a big enough advantage, sales decreased, and I heard many of the engineers ended up at Nvidia, which did use some of their ideas in a nvidia product.
- Bluestein 2y ago
  > Sadly transmeta's no longer had a big enough advantage, sales decreased, and I heard many of the engineers ended up at Nvidia, which did use some of their ideas in a nvidia product. Funny how that came about. Talent finds a way, Now they're all sitting in a 3T ship.-

nrr 2y ago

For those really wanting to dig into z/Architecture: <https://www.ibm.com/docs/en/module_1678991624569/pdf/SA22-7832-13.pdf https://www.ibm.com/docs/en/module_1678991624569/pdf/SA22-78...> The Wikipedia link has it as its first reference, but it's honestly worth linking directly here. I highly recommend trying to get someone to give you a TSO/E account and picking up HLASM.

skissane 2y ago
I put MVS 3.8J in a Docker image: https://github.com/skissane/mvs38j https://github.com/skissane/mvs38j Not TSO/E rather just plain old TSO. Not HLASM rather its predecessor Assembler F (IFOX00). Still, if you get the hang of the 1970s version, the 2020s version is just adding stuff. And some of the stuff it is adding is less unfamiliar (like Unix and Java)
- nrr 2y ago
  About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing and maybe the older pre-XA I/O architecture. Having a simulated 3033 running at 10+ MIPS is pretty nice though. (:
  - skissane 2y ago
    > About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing I've never used it, but there's a hacked up version that adds 31-bit addressing [0]. It is truly a hack though – porting 24-bit MVS to XA is a monumental task, not primarily due to address mode (you can always ignore new processor modes, just like how a 286-only OS will happily run on a 386 without realising it is doing so), but rather due to the fundamental incompatibility in the IO architecture. The "proper" way to do it would be to have some kind of hypervisor which translates 370 IO operations to XA – which already exists, and has so for decades, it is called VM/XA, but sadly under IBM copyright restrictions just like MVS/XA is. I suppose someone could always write their own mini-hypervisor that did this, but the set of people with the time, inclination and necessary skills is approximately (if not exactly) zero. So instead the hacky approach is to modify Hercules to invent a new hybrid "S/380" architecture which combines XA addressing with 370 IO. Given it never physically existed, I doubt Hercules will ever agree to upstream it. Also, IIRC, it doesn't implement memory protection/etc for above-the-line addresses, making "MVS/380" essentially a single-tasking OS as far as 31-bit code goes. But the primary reason for its existence is that GCC can't compile itself under 24-bit since doing so consumes too much memory, and for that limited purpose you'd likely only ever run one program at a time anyway. I guess the other way of solving the problem would been to have modify GCC to do application-level swapping to disk - which is what a lot of historical compilers did to fit big compiles into limited memory. But I guess making those kinds of radical changes to GCC is too much work for a hobby. Or pick a different compiler altogether – GCC was designed from the beginning for 32-bit machines, and probably alternatives would go better in very limited memory – but people had already implemented 370 code generation for GCC (contemporary GCC supports 64-bit and 31-bit; I don't think contemporary mainline GCC supports 24-bit code generation any more, but people use an old version or branch which did.) I wonder about OpenWatcom, since that's originally a 370 compiler, and I believe the 370 code generator is still in the source tree, although I'm not sure if anybody has tried to use it. [0] https://mvs380.sourceforge.net/ https://mvs380.sourceforge.net/

lormayna 2y ago

Why the Cell processor did not had success in AI/DL applications?

crote 2y ago
It was released a decade and a half too early for that, and at the time it was too weird and awkward to use to stay relevant once CUDA caught on.
- mass_and_energy 2y ago
  This. CUDA handles a lot of overhead that the dev is responsible for on the Cell architecture. Makes you wonder what PS3 games would have looked like with CUDA-style abstraction of the Cell's capabilities
  - sillywalk 2y ago
    I don't know the details of CUDA, so this may not be a good comparison, but there were efforts to abstract Cell's weirdness. It wasn't for the PS3, but for supercomputers. In particular the Roadrunner which had both Operteron and Cell processors. It was called CellFS and was based on the 9p protocol from Plan 9. It says there was 10-15% overhead, which may not have worked for PS3 games. https://fmt.ewi.utwente.nl/media/59.pdf https://fmt.ewi.utwente.nl/media/59.pdf https://www.usenix.org/system/files/login/articles/546-mirtchovski.pdf https://www.usenix.org/system/files/login/articles/546-mirtc... http://doc.cat-v.org/plan_9/IWP9/2007/11.highperf.lucho.pdf http://doc.cat-v.org/plan_9/IWP9/2007/11.highperf.lucho.pdf

ramses0 2y ago

Excellent summary, add "Water Computers" to the mix for completeness. https://www.ultimatetechnologiesgroup.com/blog/computer-ran-on-water-1936/ https://www.ultimatetechnologiesgroup.com/blog/computer-ran-...

PaulHoule 2y ago

I wouldn't say the VAX was unusual even though it was a pathfinder in that it showed what 32-bit architectures were going to look like. In the big picture the 386, 68040, SPARC and other chips since then have looked a lot like a VAX, particularly in how virtual memory works. There's no fundamental problem with getting a modern Unix to run on a VAX except for all the details. Z is definitely interesting from it's history with the IBM 360 and its 24 bit address space. (24 bit micros existed in the 1980s such as the 286 but I never had one that was straightforward to program in 24 bit mode) which, around the time the VAX came out, got expanded to 31-bits https://en.wikipedia.org/wiki/IBM_System/370-XA https://en.wikipedia.org/wiki/IBM_System/370-XA

skissane 2y ago
> 24 bit micros existed in the 1980s such as the 286 but I never had one that was straightforward to program in 24 bit mode Making clear that we are talking about 24-bit physical or virtual addressing (machines with a 24-bit data word we’re quite rare, mainly DSPs, also some non-IBM mainframes like SDS 940): 286’s 16-bit protected mode was heavily used by Windows 3.x in Standard mode. And even though 386 Enhanced Mode used 32-bit addressing, from an application developer viewpoint it was largely indistinguishable from 286 protected mode, prior to Win32s. And then Windows NT and 95 changed all that. 286’s protected mode was also heavily used by earlier DOS extenders, OS/2 1.x, earlier versions of NetWare and earlier versions of Unix variants such as Xenix. Plus 32-bit operating systems such as Windows 9x/Me/NT/2000/XP/etc and OS/2 2.x+ still used it for backward compatibility when running older 16-bit software (Windows 3.x and OS/2 1.x) Other widely used CPU architectures with 24-bit addressing included anything with a Motorola 68000 or 68010 (32-bit addressing was only added with the 68020 onwards, while the 68012 had 31-bit addressing). So that includes early versions of classic MacOS, AmigaOS, Atari TOS - and also Apple Lisa, various early Unix workstations, and umpteen random operating systems which ran under 68K which you may have never heard of (everything from CP/M-68K to OS/9 to VERSAdos to AMOS/L). ARM1 (available as an optional coprocessor for the BBC Micro) and ARM2 (used in the earliest RISC OS systems) were slightly more than 24-bit, with 26-bit addressing. And some late pre-XA IBM mainframes actually used 26-bit physical addressing despite only having 24-bit virtual addresses. Rather similar to how 32-bit Intel processors ended up with 36-bit physical addressing via PAE

mass_and_energy 2y ago

The use of the Cell processor in the PlayStation 3 was an interesting choice by Sony. It was the perfect successor to the PS2's VU0 and VU1s, so if you were a game developer coming from the PS2 space and were well-versed in the concepts of "my programs job is to feed the VUs", you can scale that knowledge up to keep the cores of the Cell working. The trick seems to be in managing synchronization between them all