Apple's M chips are the closest we have now. Though, it isn't entirely the same.

VLIW was explored in the early 2000s, almost every silicon manufacturer went through a phase of wanting to use it. Intel had their infamous Itanium architecture and ATI/AMD had TeraScale in the GPU space. There was also a couple of smaller players that tried their hands on VLIW. The problem is, it's just not a very good design choice and going out of order with multiple super scalar execution ports is just easier for everyone involved.

​​@@JustJustSid because it is very hard (maybe even impossible) to make good automatic compiler for VLIW. You need to predict the data, set the branch prediction in advance... x86 does it for you on hw. And transmeta was only one doing it in HW on real data without making the programmers and compilers to do the optimizations in advance. Which seems like the best strategy in hindsight after the Itanium and radeons HD5000

Nvidia bought Transmeta und used their technology to create a series of efficient and performance-wise extremely competitive ARMv8 CPUs "2014-2018: Denver 1&2, aswell as Carmel". After that, they switched over to ARM's regular CPU templates without ever publically stating a reason. Maybe they encountered the limits of this technology when it comes to performance scaling or they just deemed that in the current market, making use of such a special core design isn't worth the extra effort. Anyhow, maybe it'll get picked up again one day.

@@vogonp4287 Apple's chips are just ridiculously wide and use big caches and instruction reordering windows. They are engineered for lower clockspeeds, fabbed on the latest nodes, ship many fixed-function accelerators with tight software integration, and thus, run extremely energy efficient. Their CPUs are designed such that as many different micro-OPs (instructions -> macro OPs -> micro OPs -> buffer&reordering -> dispatch&execution) as possible can be in-flight at any given time, but they are dispatched independently from each other. VLIW performance on the other hand stands and falls with being able to dispatch a large enough piece of work to saturate all execution ports at once. If that cannot be done, a part of the CPUs execution units will remain idle. That bubble cannot be filled with other work. When using Transmeta's approach, you get a software instruction reorder buffer that's measured in megabytes instead of # of entries, which helps alleviating that problem. Having a good, deterministic (regarding compilation time) compiler design and a wide enough spectrum of instructions tailored towards fully covering the combined equivalents of many ARM/x86 instructions are another must though. These things have to be balanced against each other, because more possible instructions also means more compiler complexity.

Wow! thanks for sharing. The ideas behind these CPUs were amazing. Well done to you and everyone involved for shaking up the CPU market.

wow :D

oh shoot, if it's not too late, you should try to archive that VHS tape! i haven't seen it posted on youtube or the internet archive. all you need is a VCR and a cheap lil a/v capture card, i happen to have those on hand myself and it's a quick n dirty way to digitize VHS tapes!

@@EeveeEuphoria I still have them, but I don't believe it would be within my right to post them.

@@rafterrattler561 At least keep a digital version of it to yourself, don't risk losing them :)

What if it would only need to be morphed once, replacing the original code?

I imagine it would all be done in RAM or even cache or dedicated on-die memory.

@@widgity It takes allocates 16MB RAM from the system to use as a cache.

I'd love to see what performance it got with a SSD

If Linux and Transmeta coexisted together I think we could have reached much higher levels of optimization between silicon and code.

I JUST POSTED THE SAME. The Sage here got it 100% right.

​@es-zw3mg i mean 13th gen is insane on comparison and only really happened due to amd catching then off guard with server tech, and 10 years of 14nm.

The lack of innovation is why AMD is now a competitive player on the server market.

Hopefully you still have some of the equipment and didn't throw it away?

@@broklee I am no longer associated with that hackerspace, and have no idea what happened to it.

But even here Nvidia differs from Crusoe in having hardware decoders to give the binary translation a reasonable performance floor.

Do u know about e2k-architecture?

Similarly the modern M1 Macs do a similar thing in software, unlike the earlier Rosetta 1 which interpreted PPC instructions on x86 the current iteration actually optimises an x86 binary on the fly and permanently stores the converted ARM variant. Amiga did something similar when they switched architectures

@@theharbingerofconflation also the M1 has some x86 compatibility hardware, which makes them fast with only a ~30% loss from native arm. interestingly they also have javascript specific instructions the itanium architecture was vliw, but failed due to lack of support. I think unless there's leaps in battery tech, at some point we'll see more risc/arm chips with x86 backward compatibility, or x86 coprocessors, at least in the mobile market, because of the performance/W gain.

​@@satibel x86 will close in on Apple's chips, they're not THAT impressive.

Yes, but it also has certain issues that almost make it unpractical for certain markets. For example, it hates dynamic recompilers like those used in emulators, it either crashes the emulator itself, or at best, gave no performance improvements, which makes it pretty bad for emulation. Source : I actually owned a laptop with a Transmeta Crusoe processor. Due to those bugs the 700Mhz Crusoe I had would perform, at best like a Pentium II 400Mhz processor on emulation (Made worse that dynamic recompilation doesn't work). Pretty great at everything else though.

@@StriderVM JIT compilation was only just starting to become important though, and I don't believe there were very many implementations that mattered. So, maybe being incompatible with JITs would have been excusable at the time; and Transmeta could have worked with the handful of JIT manufacturers to expose a direct API to Transmeta's morphing layer? Of course that's all hypothetical. Time moved on from there. On the other hand, the fact that dynamic code generation resulted in buggy execution has me worried. That sounds exactly like the type of problem that would have security implications. If you think that side-channel hardware bugs such as Spectre are a major pain, then I don't even want to think about what problems you run into when you can race the morphing software.

It is still a technology from the future. Imagine distributing only LLVM IR code and the CPU itself running a JIT compiler, the most efficient JIT compiler possible, making for better performance as it runs.

@@StriderVM Ironically the hardware is doing the dynamic recompilation itself, perhaps with a simpler emulator that just loaded and interpreted the instructions instead of double recompiling them.

@@gutschke "side-channel hardware bugs such as Spectre are a major pain" only for multi-tentant cloud providers. Why are we even sharing cache ? that's insanity, we need better isolation if you are going to run different tentant code in the same physical CPU.

I always loved the look of the black U3 and wanted one, still do!

When you watch companies like GPD basically make the same thing today but with far worse design, fit and finish, you have to show these guys who were literally writing the future blind, mad respect.

should be 50% of their profit AT LEAST. 250M is pocket change for intel.

@@simontay4851 i'm thinking more like 90% of the profit of every patent infringing processor sold, until the infringing technology was removed.

@@KOSMOS1701A Or 200% of their profits.

Intel basically admitted to stiffing multiple years of potential technology advancements by their competitor by simply infringing copyright on new technology and making them shut down by economies of scale. We could have had a magnitude faster consumer CPU by now. Intel should’ve been dissolved and the CEO + board of directors federally prosecuted for market manipulation at a MINIMUM.

Most JITs do the tier up thing, including all major JavaScript engines, the JVM, and some CPU emulators I think

Android no longer pre-compiles binaries. Instead, P-code is delivered in the package, and compiled at install time.

@@LMB222 I thought they were compiled to ARM these days by the developer.

The idea of x86 code translation the Crusoe was doing wasn't anything new. Code morphing from x86 to something "RISC" started with NexGen. Intel did its own thing in the Pentium Pro. This implementation survives today What Trasmeta wanted to do was run apps on a recompiler so instruction scheduling and execution could be made in away that made CPU core simpler. This idea has only been tried again by Elbrus (who did make a much better x86 compatible Crusoe-like CPU) and NVIDIA (who made Project Denver, which was in the Nexus 9 tablet)

it was killed purposefully, intellectual ventures owns the patents. guess who owns a 20% stake in that company? none other than edward jung the co-founder of intel. there's a picture.

That’s a really interesting question. Unfortunately not much is known because it was proprietary.

In the end it seems that Apple silicon has answered the question this posed - thatx86 emulation can be done, and done well, with low power consumption and incredible performance, and convince developers to port their code to native for better performance. The approach might be quite different but I think given enough time and development Transmeta would have gotten really close to native performance.

The transmeta cpus were never designed to be able to directly run application or operating system code. Their native code format doesn't have protected memory or supervisor mode or anything like that - those features of standard processors were actually emulated. It also wasn't *really* designed to switch architectures. A bunch of the native instructions were designed so that e.g. flags from performing certain mathematical or comparison operations were the same as native x86 instructions would produce, to reduce the overhead in emulation. That said, i do recall hearing about them making a prototype chip that could run java bytecode directly.

​@@kepstin Wow, very interesting! Thanks for the info. It seems like emulating security features would open up a big new attack surface for malware. Not that doing it in hardware has been much better (Spectre and Meltdown, I'm looking at you, lol). @Akshay - Yes! I have heard amazing things about Apple Silicon. I'm very eager to see what Intel and AMD's answer to it will be.

Seems likely they would have kept updating the internal architecture to further optimize things. When it's a private instruction set you have more flexibility in changes.

I also prefer the black one. Not easy to find though.

There was talk of a hybrid chip that could do either x86 or PowerPC. I'm certain this was part of Transmeta's planned strategy.

@@JanusCycle they were able to run java byte code on metal.

ALMOST on metal ;)

I think it was a sneaky way to make their devices look smaller and lighter but showing advertisements and listing size and weight numbers without the battery attached

By the way without battery it's looks great even today.

@@fatcat7msk7ru Well, imagine if Apple was to launch their new iPhone, and it didn't came with an internal battery. Pretty sure that thing would really look nice, at least until you connect the external battery. For rehabilitation, they later had devices with internal gumstick batteries, and the external attachment was optional, only if you wanted to use AAs.

Sharp MM10 is based on Transmeta processor too. It looks and operates nice.

My friend's friend bought the C1 but returned it after (our trip to CES in 2001) to the store as it was too slow for him

Nvidia and greed

@@thebyzocker was about to type exactly this

Unfortunately Transmeta didn't release enough fine details about how they did this. I'm glad modern projects like MiSTer exist, it's really important to preserve original hardware in this way.

@@JanusCycle oh, I mean just the general approach. I'm a programmer, I'm fairly sure they did JIT optimization and compilation, kind of how HLE (High Level Emulation) works for N64, or how Java works. The thing is with Java you have a high level representation of the code when compiling, whereas with HLE and (likely) Transmeta, you have to first decompile the code a little. Not too much, but just enough to see some of the more high-level structure, so you can reason about the code better. JIT became very popular by the end of the 90s: Symantec demoed their JIT compiler for Java in 1996. It was new and revolutionary and shook things up thanks to the performance gains - Java did not have JIT before. It would stand to reason that Torvalds & Co went "hmm, we can do this for all programming languages by putting it on the CPU" and one silicon development cycle later we had the Crusoe in 2000. After writing this, I read some other comments that mentioned running Java directly. Well that goes in line with what I said here.

for texting you don't really need android tho, just add a WWAN modem to your PC and use that? Or are you talking about a weird messaging app that only exists for Android?

That sticker was given to me many years ago by a graffiti artist.

You might like the GPD Pocket line of computers!

Yes. Although unlike this earlier implementation, the core functionality (kernel, OS, drivers, etc) have been rewritten to run on arm64 (the apple silicon architecture), and only runs x86 code when an older app is used with just-in-time (JIT) compilation where the instructions are translated in real time to arm code that usually isn't as fast as native x86, but does get the job done for most applications.

Windows XP installation theme, If you were lucky enough to have the Windows XP installer detect your sound card.

I personalized this myself with stickers and whatnot.

Ah! I see. I didn't realise you're Aussie. Great video!

Was about to comment on this... Spotted the logo also.

Yes but there is still an underlying processor to do the actual work which is probably RISC.

@@ky5666 the underlying processor is VLIW. x86 is translated to VLIW. That's how it works