Linux Patch Pending To Fix Support For The Transmeta Crusoe CPU

[vladpetric]

I understand vladpetric.I don't agree with your method of communication, but understand that many embrace it, and am not offended by it.

As the only thing that truly offends me is the suffering of humanity, and our continued allowance of it. But that is another subject that I discuss in "A Future of the Brave" on my archived website "searingtruth.com".

And of course everyone always believed it was impossible, but I had VHDL simulations proving everything I said was true. In fact the last few pages of the document have two waveforms from a Data Generator. I don't know for certain what happened to the last simulation output pages, as they numbered around 50, and are not even readable by the FrameMaker 4 installation I have in my KVM Windows XP VM. I suspect it's because I've not been able to get the Adobe Font Manager and Pantone software to work, but when I restored the document I was primarily concerned with the text and gave up fairly quickly.

But I have all the VHDL code, libraries, and simulation code and settings for everything from Mimic to Thrust. And if I had to could convert them to work in modern simulators.

However I suspect that, even if I did, no one would believe it.

Just as so many times before, across the many failed inventions I created.

Alright, so I need to ask - at what level did you simulate things? A VHDL where you have one single signal triggering changes in ~10k logic blocks in a single clock cycle (assuming GHz frequencies) will work in a high level simulation, but it won't with a simulation of a fully synthesized chip. If you did a full synthesis, please specify at a minimum what technology and clock frequency you used.

There's at least two issues there (super simplified): signal propagation delays (RC delays, where R is the resistance of the wire, and C the residual capacitance of the input gate), and fan out. Problem btw is that with the most recent technologies, RC delays don't get better versus previous technologies (e.g., because thinner wires have increased resistivity ...)

Of course, I am making assumptions about things. If I'm making the wrong assumptions, please correct them ...

Now I don't actually think it's necessary to be able to reconfigure a full chip in a single cycle, but you did mention that.

[varikonniemi]

I understand vladpetric.I don't agree with your method of communication, but understand that many embrace it, and am not offended by it.

As the only thing that truly offends me is the suffering of humanity, and our continued allowance of it. But that is another subject that I discuss in "A Future of the Brave" on my archived website "searingtruth.com".

And of course everyone always believed it was impossible, but I had VHDL simulations proving everything I said was true. In fact the last few pages of the document have two waveforms from a Data Generator. I don't know for certain what happened to the last simulation output pages, as they numbered around 50, and are not even readable by the FrameMaker 4 installation I have in my KVM Windows XP VM. I suspect it's because I've not been able to get the Adobe Font Manager and Pantone software to work, but when I restored the document I was primarily concerned with the text and gave up fairly quickly.

But I have all the VHDL code, libraries, and simulation code and settings for everything from Mimic to Thrust. And if I had to could convert them to work in modern simulators.

However I suspect that, even if I did, no one would believe it.

Just as so many times before, across the many failed inventions I created.

I think the issue is that an infinite number of inventions can work well in the head, but when trying to actualize it some unforeseen issue arises that is not surmountable.

[muncrief]

It is effectively impossible to do what you're saying, assuming a sufficiently high number of logic elements (tens of millions or more), and a high enough clock (several Gigahertz).

If it were possible, everyone would be doing it ... this would be the holy grail. Seriously.

Not my intent to insult you in any way, I honestly thought you were trolling.

I understand vladpetric.I don't agree with your method of communication, but understand that many embrace it, and am not offended by it.

As the only thing that truly offends me is the suffering of humanity, and our continued allowance of it. But that is another subject that I discuss in "A Future of the Brave" on my archived website "searingtruth.com".

And of course everyone always believed it was impossible, but I had VHDL simulations proving everything I said was true. In fact the last few pages of the document have two waveforms from a Data Generator. I don't know for certain what happened to the last simulation output pages, as they numbered around 50, and are not even readable by the FrameMaker 4 installation I have in my KVM Windows XP VM. I suspect it's because I've not been able to get the Adobe Font Manager and Pantone software to work, but when I restored the document I was primarily concerned with the text and gave up fairly quickly.

But I have all the VHDL code, libraries, and simulation code and settings for everything from Mimic to Thrust. And if I had to could convert them to work in modern simulators.

However I suspect that, even if I did, no one would believe it.

Just as so many times before, across the many failed inventions I created.

[vladpetric]

How so vladpetric?

I appreciate you actually reading it rather than hurling insults by the way.

It is effectively impossible to do what you're saying, assuming a sufficiently high number of logic elements (tens of millions or more), and a high enough clock (several Gigahertz).

If it were possible, everyone would be doing it ... this would be the holy grail. Seriously.

Not my intent to insult you in any way, I honestly thought you were trolling.

[muncrief]

"Allowing everything from custom FPGAs to full custom ICs to be reconfigured in an almost infinite number of ways, in one clock cycle."

Personally I would delete the "in one clock cycle", it's a bit of a dead giveaway

How so vladpetric?

I appreciate you actually reading it rather than hurling insults by the way.

[vladpetric]

Now that the link is working I'm looking forward to your feedback vladpetric.

"Allowing everything from custom FPGAs to full custom ICs to be reconfigured in an almost infinite number of ways, in one clock cycle."

Personally I would delete the "in one clock cycle", it's a bit of a dead giveaway

[muncrief]

M.Bahr and vladpetric : the both of you, just rent a room already and get it over with!

To put some oil into the fire: While the legacy ballast of X86_64 sucks, I do think that the general concept of CISC is still a good idea, because having an internal RISC core while the compiler emits CISC instructions, reduces compiler complexity, which is, as you can all remember, what ultimately killed VLIW - be it Itanum or AMD's Terrascale GPUs… Nvidia likely had an engineering reason aswell as to not use Transmeta's "X-to-VLIW" technology anymore after a certain point, despite "Project Denver" having been a huge success.

Anyhow, as soon as you're hitting a microcoded CISC instruction, you can be sure that the sub-instructions/µOPs or whatever this translates to, hits optimal performance paths on the specific chip it's executed on. Generic X86_64_v# instrs + microcode allows for compiler-independent "optimizations" happening during runtime and keeps code size down. Like why print a whole algorithm when you can just emit a keyword that resolves to a functionally equivalent, product specific macro?

You two available for a 3some btw?

muncrief Mega already deleted your virus…

ThrustRP allowed you to implement RISC or CISC, or both simultaneously kiffmet.

It was up to the designer to combine predefined components, and/or custom IP, in any way they wished.

https://mega.nz/file/oThwHILa#4Wn55sxxnII_CckiSfV9SwL-x8Via7qRNZEmKeEzarc

[muncrief]

Wow, the sarcasm over here is amazing!

Now that the link is working I'm looking forward to your feedback vladpetric.

[vladpetric]

I understand M.Bahr.

My technology, which I believe surpassed even Transmeta, was also rejected because others simply could not understand it at the time. And it appears still cannot.

As I posted earlier, I had a much better idea called "Thrust Reconfigurable Processor", which used VLIW in a revolutionary way, allowing everything from custom FPGAs to full custom ICs to be reconfigured in an almost infinite number of ways, in one clock cycle. It also included a Thrust microprocessor that could be configured for any bit width, and executed every instruction in one clock cycle as well. It essentially worked by changing the address of RAM banks that drove registers to configure a versatile set of components. Its predecessor, Mimic, had some funding from Sun Microsystems, but later management couldn't understand it and ended their participation. But I kept working on Mimic and ended up with Thrust, which of course is quite complex. But it also failed because most people with the money to fund it couldn't understand it and I couldn't secure the additional funding I needed to complete its development.

As I said though, for those interested I did the best I could to convert the original FrameMaker 4 documentation to Word format awhile ago (though some graphics were blacked out and other parts omitted), and posted it on Mega. It's a long read, around 68 pages, and with the missing graphics is a bit more difficult to comprehend, but those knowledgeable in digital systems and microprocessor architecture will understand. Here's a link to the last architectural document I had for it, minus the header and table of contents ...
https://mega.nz/file/oThwHILa#4Wn55s...7qRNZEmKeEzarc

Wow, the sarcasm over here is amazing!

[muncrief]

M.Bahr and vladpetric : the both of you, just rent a room already and get it over with!

To put some oil into the fire: While the legacy ballast of X86_64 sucks, I do think that the general concept of CISC is still a good idea, because having an internal RISC core while the compiler emits CISC instructions, reduces compiler complexity, which is, as you can all remember, what ultimately killed VLIW - be it Itanum or AMD's Terrascale GPUs… Nvidia likely had an engineering reason aswell as to not use Transmeta's "X-to-VLIW" technology anymore after a certain point, despite "Project Denver" having been a huge success.

Anyhow, as soon as you're hitting a microcoded CISC instruction, you can be sure that the sub-instructions/µOPs or whatever this translates to, hits optimal performance paths on the specific chip it's executed on. Generic X86_64_v# instrs + microcode allows for compiler-independent "optimizations" happening during runtime and keeps code size down. Like why print a whole algorithm when you can just emit a keyword that resolves to a functionally equivalent, product specific macro?

You two available for a 3some btw?

muncrief Mega already deleted your virus…

Actually the previous link wasn't working from my second post, which was odd, so I recreated it and now I can't access it via the new link either. So I'm going to delete the file and upload it again. It probably does have something to do with security, but not because it's a virus. It's most likely because I rarely use Mega and the sudden access and changing of keys set off an alarm of some kind.

Stay tuned ...

Hmmm ... It actually has something to do with Phoronix caching. So I uploaded it to Google, and then realized I need to delete the link from my Phoronix post, save the edit, and then add the link again. So here's the original Mega link:

https://mega.nz/file/oThwHILa#4Wn55sxxnII_CckiSfV9SwL-x8Via7qRNZEmKeEzarc