They're microcontrollers, but the Parallax Propeller ( <a href="https://en.wikipedia.org/wiki/Parallax_Propeller" rel="nofollow">https://en.wikipedia.org/wiki/Parallax_Propeller</a> ) and Propeller 2 ( <a href="https://www.parallax.com/propeller-2/" rel="nofollow">https://www.parallax.com/propeller-2/</a> ) are really interesting architectures for several reasons. For one, they allow the code running on an individual core to be packaged up and reused like a module. They also include a high level language in ROM along with useful lookup tables and very versatile and capable I/O hardware.
Was there ever a compiler that targeted the Crusoe architecture directly without having to go through the translation layer? I remember there was a big deal about how the thing would translate your code the first time you ran it and keep the translation in a cache, but I always had the impression that the translation layer was a bit unoptimized because it was a step away from the original code. Also, everybody ever who has tried to make a VLIW architecture for general computing has ended up with a slow and expensive processor that can't compete.<p>The article makes a big deal about CISC vs. RISC, but in the end all of the CISC architectures ended up being RISC under the hood with front end instruction translation for the more complex CISC instructions. The transition to 64 bit should offer chip manufacturers a golden opportunity to ditch old disused complexity, like multiple addressing modes and variable length instructions.
I still got one running, from the software side, its effectively an i586:<p><pre><code> vendor_id : GenuineTMx86
model name : Transmeta(tm) Crusoe(tm) Processor TM5800
cpu MHz : 800.023
flags : fpu vme de pse tsc msr cx8 sep cmov mmx longrun lrti constant_tsc cpuid
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
</code></pre>
But you can't do much with such a machine nowadays.
I was in Japan in 2005 and saw these tiny laptops running Transmeta's processor in the wild. The university I was studying in had them in their library. They ran windows and everything worked well. I've never seen laptops that small and tiny in the US, even during the netbook phase.
Here is a paper from 2000 describing the Crusoe arch and its code morphing scheme in very broad strokes:<p><a href="https://web.stanford.edu/class/cs343/resources/crusoe.pdf" rel="nofollow">https://web.stanford.edu/class/cs343/resources/crusoe.pdf</a>
Interestingly there were, I think, 3 companies working on similar projects at the time (including TM) - the others didn't make it to market (mostly due to the dot-com bust and the sudden drop in available funding).<p>A lot of the IP that people had to create involved getting around Intel's patents, some of which were both basic and likely bogus (prior art etc) but Intel was widely seen as having far more lawyers than anyone could afford so taking them on directly was best avoided<p>Not really mentioned in this article was TM's biggest score at the time, which was getting Linus to come work for them
There's a great paper from 2004 about reverse engineering the CMS of the Crusoe:<p><a href="https://www.realworldtech.com/crusoe-intro/" rel="nofollow">https://www.realworldtech.com/crusoe-intro/</a><p>To my knowledge the foreshadowed followup was never released.
This was interesting in 1995. By 2005-2010, SoCs included sophisticated cache architecture, memory controller, internal and external bus controller, transceivers, and maybe iGPU. All of which play a role in performance per watt. ISA was no longer preeminent. Plus, if you emulate multicore x86-64 with superscalar vliw scheduling you're still constrained by the memory model, too. There is only so much you can do.
I had a TC1000 with the Crusoe. In tasks like web browsing it was quite slow but it was surprisingly performant in games. I remember being shocked that I could play Star Trek: Bridge Commander with all the settings cranked up.
this article is terribly clueless. high-level languages <i>such as basic</i> had made pure assembly language a novelty? the sparc is a 'chipset'? transmeta invented vliw 11 years after multiflow (which isn't even mentioned)?<p>i don't have any complaint about people writing about things they don't know very much about; it's a great way to learn. i just don't think they should put on this fake authoritative tone, because they can mislead other people. i mean that's how we got the cda and dmca
Ah, the promise of VLIW. I played with one VLIW architecture when it came out (TI 320 C6000) and it looked exciting but after a while we got tired of waiting for the SW magic to materialize, I think similar problems have generally been the downfall of VLIW systems.<p>We did look at handwriting assembly code, since we were already intimately familiar with the classic TI 320C30s and C40s (fantastic DSPs!) but it was just so crazy. Even TI told us not to bother and wait for their super cool compilers.
It sounds very much like what current CPUs do, with x86 being mapped into execution units dynamically via microcode, except (I assume ? article was very low on detail) in case of Crusoe it just did it for big VLIV instruction blobs.
For some reason, the thing i most remember about Transmeta is their appearances in After Y2K, where they are some sort of sinister cabal with an underground base:<p><a href="https://joyoftech.com/geekycomics/Aftery2k/y2Karchives/125.html" rel="nofollow">https://joyoftech.com/geekycomics/Aftery2k/y2Karchives/125.h...</a><p><a href="https://joyoftech.com/geekycomics/Aftery2k/y2Karchives/158b.html" rel="nofollow">https://joyoftech.com/geekycomics/Aftery2k/y2Karchives/158b....</a>
No, <a href="https://en.wikipedia.org/wiki/Intel_iAPX_432" rel="nofollow">https://en.wikipedia.org/wiki/Intel_iAPX_432</a> was more interesting.