HN Explorer

Ask HN: Weirdest Computer Architecture?

93 points by bckr ↗ HN
My limited understanding of “the stack” is:

  Physical substrate: Electronics
  Computation theory: Turing machines
  Smallest logical/physical parts: Transistors, Logic gates
  Largest logical/physical parts: Chips
  Lowest level programming: ARM/x64 instructions 
  First abstractions of programming: Assembly, C compiler
  Software architecture: Unix kernel , Binary interfaces
  User interface: Screen, Mouse, Keyboard, GNU
Does there exist a computer stack that changes all of these components?

Or at the least uses electronics but substitutes something else for Turing machines and above.

108 comments

[ 0.27 ms ] story [ 175 ms ] thread
solardev
Analog computers, quantum computers, light based computers, DNA based computers, etc.
runjake
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

2. Cell processor: https://en.wikipedia.org/wiki/Cell_(processor)

3. 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 (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-n... (Cognitive/neuromorphic computing)

Bluestein
> 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
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
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
I seem to recall them machines not being cheaper, which was my main hope at the time :)
em-bee
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
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
> 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
For those really wanting to dig into z/Architecture: <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
I put MVS 3.8J in a Docker image: 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
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
> 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/

nrr
Yeah, I've wondered what the lift would be to backport XA I/O to MVS 3.8j, among other things, but given that it's a pretty pervasive change to the system, I'm not surprised to learn that it's pretty heavy.

To your note about a hypervisor though: I did consider going this route. I already find VM/370 something of a more useful system anyway, and having my own VM/XA of sorts is an entertaining prospect.

skissane
It arguably doesn't require anything as remotely complex/feature-rich as full VM/XA: it wouldn't need to support multiple virtual machines, or complicated I/O virtualisation.

Primarily just intercept SIO/etc instructions, and replace them with the XA equivalent.

Another idea that comes to mind: you could locate the I/O instructions in MVS 3.8J and patch them over with branches to some new "I/O translation" module. The problem I think with that, is while the majority of IO goes through a few central places in the code (IOS invoked via SVC call made by EXCP), there's I/O instructions splattered everywhere in less central parts of the system (VTAM, TCAM, utilities, etc).

nrr
I leaned into the "well, what if my own VM/XA" because, uh, VM/CMS has the odd distinction among IBM's operating systems of the era of being both (1) source available and (2) site-assemblable. I've gone through my fair share of CMS and CP generations, which felt like a more complete rebuild of those nuclei than the MVS sysgens I've done.

That there makes me feel a little less confident in an MVS 3.8j patching effort.

patterner
i loved working with z/Arch assembly. best job i ever had.
lormayna
Why the Cell processor did not had success in AI/DL applications?
crote
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
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
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://www.usenix.org/system/files/login/articles/546-mirtc...

http://doc.cat-v.org/plan_9/IWP9/2007/11.highperf.lucho.pdf

PaulHoule
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

skissane
> 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

PaulHoule
I understand the 286 protected mode still made you mess around with segment registers, if you wanted to work with 24-bit long pointers you would have to emulate that behavior with the segment registers and it was a hassle.

I didn't think the segment registers were a big hassle in the 8086 real mode in fact I thought it was fun to do crazy stuff in assembly such as use segment register values as long pointers to large objects (with 16 byte granularity) I think the segment registers would have felt like more of a hassle if I was writing larger programs (e.g. 64k data + 64k code + 64k stack gets you further towards utilizing a 640k address space than it does towards a 16M address space).

I recently discovered

https://en.wikipedia.org/wiki/Zilog_eZ80

and think that 2001 design is close to an ideal 24 bit micro in that both regular and index registers are extended to 24 bits, you have long pointers and all the facilities to work in a 24 bit "problem space" based on an architecture that is reasonable to write compilers for. It would be nice to have an MMU so you could have a real OS, even something with bounds registers would please me, but with many reasonably priced dev boards like

https://www.tindie.com/products/lutherjohnson/makerlisp-ez80...

it is a dream you can live. I don't think anything else comes close, certainly not

https://en.wikipedia.org/wiki/WDC_65C816

where emulating long pointers would have been a terrible hassle and which didn't do anything to address the compiler hostility of the 6502.

---

Now if I wanted the huge register file of the old 360 I'd got to the thoroughly 8-bit AVR-8 where I sometimes have enough registers for your inner loop and interrupt handler variables. I use 24-bit pointers on AVR-8 to build data structures stored in flash for graphics and such and since even 16-bit operations are spelled out, 24 bit is a comfortable stop on the way to larger things.

skissane
> I understand the 286 protected mode still made you mess around with segment registers, if you wanted to work with 24-bit long pointers you would have to emulate that behavior with the segment registers and it was a hassle.

As an application programmer it wasn't much different from 16-bit real mode. Windows 3.x, OS/2 1.x and 16-bit DOS extenders gave you APIs for manipulating the segments (GDT/LDT/etc). You'd say you'd want to allocate a 64KB segment of memory, it would give you a selector number you could load into your DS or ES register – not fundamentally different from DOS. For an OS programmer perspective it was more complex, of course.

It was true that with 16-bit real mode you could relatively easily acquire >64KB of contiguous memory, in 16-bit protected mode that was more difficult to come by. (Although the OS could allocate you adjacent selector numbers–but I'm not sure if 16-bit Windows / OS/2 / etc actually offered that as an option.)

That said, 16-bit GDTs/LDTs have a relatively sensible logical structure. Their 32-bit equivalents were a bit of a mess due to backward compatibility requirements (the upper bits of the base and limit being stored in separate fields from the lower fields). And the 386, while it has a much richer feature set than the 286, those added features bring a lot of complexity that 286 OS developers didn't need to worry about. Even if you try your hardest (as contemporary OSes such as Linux and 32-bit Windows do) to avoid the 386's more esoteric features (such as hardware task switching and call gates)

abs0
> "There's no fundamental problem with getting a modern Unix to run on a VAX except for all the details"

Pretty much. The main issue with modern Unx on a VAX is memory size & performance, which combine to make native compiling under recent gcc versions "problematic", so cross building in gcc-10 or 12 is much easier.

The profusion of (from today's perspective) whacky addressing modes have made maintaining gcc for VAX more effort that it would be otherwise, but it's still there and in use for one modern UNx https://wiki.netbsd.org/ports/vax/ :)

You can download https://opensimh.org/ to get a VAX emulator and boot up to play

Simh also emulates a selection of other interesting and unusual architectures https://opensimh.org/simulators/

mass_and_energy
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
mikewarot
BitGrid is my hobby horse. It's a Cartesian grid of cells with 4 bit in, 4 bit out, LUTs (look up tables), latched in alternating phases to eliminate race conditions.

It's the response to the observation that most of the transistors in a computer are idle at any given instant.

There are a full rabbit hole worth of advantages to this architecture once you really dig into it.

Description https://esolangs.org/wiki/Bitgrid

Emulator https://github.com/mikewarot/Bitgrid

bjconlan
On reading this I thought "oh someone's doing the Green Arrays thing" but this looks like it pre-dates those CPUs by some time.

But as nobody has mentioned it yet surprisingly: https://www.greenarraychips.com/ albeit perhaps not weird; just different

mikewarot
The Green arrays chips are quite interesting in their own right. The ability to have a grid of CPUs each working at part of a problem could be used in parallelizing a lot of things, including the execution of LLMs.

There are secondary consequences of breaking computation down to a directed acyclic graph of binary logic operations. You can guarantee runtime, as you know a-priori how long each step will take. Splitting up computation to avoid the complications of Amdahl's law should be fairly easy.

I hope to eventually build a small array of Raspberry Pi Pico modules that can emulate a larger array than any one module can handle. Linear scaling is a given.

jononor
That is quite interesting. Seems quite easy and efficient to implement in an FPGA. Heck, one could make an ASIC for it via TinyTapeout - https://tinytapeout.com/
yen223
A lot of things are Turing-complete. The funniest one to me are Powerpoint slides.

https://beza1e1.tuxen.de/articles/accidentally_turing_comple...

https://gwern.net/turing-complete

jasomill
I prefer the x86 MOV instruction:

https://web.archive.org/web/20210214020524/https://stedolan....

Removing all but the mov instruction from future iterations of the x86 architecture would have many advantages: the instruction format would be greatly simplified, the expensive decode unit would become much cheaper, and silicon currently used for complex functional units could be repurposed as even more cache. As long as someone else implements the compiler.

nailer
The giant global computers that are Solana mainnet / devnet / testnet. The programs are compiled from Rust into (slightly tweaked) EBPF binaries and state updates every 400ms, using VDFs to sync clocks between the leaders that are allowed to update state.
mikewarot
I thought magnetic logic was an interesting technology when I first heard of it. It's never going to replace semiconductors, but if you want to compute on the surface of Venus. You just might be able to make it work there.

The basic limit is the curie point of the cores, and the source of clock drive signals.

https://en.m.wikipedia.org/wiki/Magnetic_logic

mikewarot
Vacuum tubes would be the perfect thing to generate the clock pulses, as they can be made to withstand the temperatures, vibrations, etc. I'm thinking a nuclear reactor to provide heat via thermopiles might be the way to power it.

However... it's unclear how thermally conductive the "atmosphere" there is, it might make heat engines unworkable, no matter how powerful.

dann0
The AMULET Project was an asynchronous version of ARM microprocessors. Maybe one could design away the clock like with these? https://en.wikipedia.org/wiki/AMULET_(processor)
mikewarot
In the case of magnetic logic, the multi-phase clock IS the power supply. Vacuum tubes are quite capable of operating for years in space, if properly designed. I assume the same could be done for the elevated pressures and temperatures on the surface of Venus. As long as you can keep the cathode significantly hotter than the anode, to drive thermionic emission in the right direction, that is.
defrost
Setun: three-valued ternary logic computer instead of the common binary- https://en.wikipedia.org/wiki/Setun

Not 'weird' but any architecture that doesn't have an 8-bit byte causes questions and discussion.

EG: Texas Instruments DSP chip family for digital signal processing, they're all about deep pipelined FFT computations with floats and doubles, not piddling about with 8-bit ASCII .. there's no hardware level bit operations to speak of, and the smallest addressable memory size is either 32 or 64 bits.

metaketa
HVM using interaction nets as alternative to Turing computation deserves a mention. Google: HigherOrderCompany
dongecko
Motorola used to have a one bit microprocessor, the MC14500B.
ksherlock
The tinker toy computer doesn't even use electricity.
trealira
The ENIAC, the first computer, didn't have assembly language. You programmed it by fiddling with circuits and switches. Also, it didn't use binary integers, but decimal ones, with 10 vacuum tubes to represent the digits 0-9.
RecycledEle
Using piloted pneumatic valves as logic gates blew my mind.

If you are looking for strangeness, the 1990's to early 2000's microcontrollers had I/O ports, but every single I/O port was different. None of them had a standard so that we could (for example) plug in a 10-pin header and connect the same peripheral to any of the I/O ports on a single microcontroller, much less any microcontroller they made in a family of microcontrollers.