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

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.

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.

I seem to recall them machines not being cheaper, which was my main hope at the time :)

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.

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.

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

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.

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)

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. (:

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

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.

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).

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.

i loved working with z/Arch assembly. best job i ever had.

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

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.

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

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

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

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

> 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

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.

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

> "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/

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