NoSpammer (no.delete@this.spam.com) on April 21, 2017 12:40 pm wrote:
> anon (spam.delete.delete@this.this.spam.com) on April 21, 2017 7:55 am wrote:
> > Like I said, if they have a plan on how to deal with the things
> > that usually kill VLIW it can work, if they don't it won't.
>
> It doesn't matter if they have a plan. Where's the solution?

?

>
> > Your argument so far is that horse A can't win the race because it didn't win the last race.
> > I'm skeptical, I'm just not ruling it out.
>
> Your argument is believing that a horse that someone is only thinking about at the moment is about to win.
>

No, I'm saying a horse that hasn't even participated yet because it's too young might win in the future.

These analogies are getting out of hand.

> > It is very clear what they are doing, you just haven't bothered to look it up so far.
> > Yes, it's basically transmeta with a few more years of experience
> > and a lot more spare ressources to throw at it.
>
> LOL, the way the guys are talking it's quite obvious they are seriously lacking in relevant experience.
> Like I don't see them attacking one thing that I find as bottleneck optimizing code recently.
> What spare resources? All the fat OOO CPUs recently have plenty of spare resources.

I was talking about Denver.
Multiple cores and more RAM.
Transmeta couldn't afford using enough RAM for buffering code. That problem doesn't exist anymore.
You also can't run code optimization in parallel to execution without multiple cores.

>
> They seem to be seriously lacking in compiler department and yet they
> want us to believe the magic compiler will be the magic solution.
>
> > Have you ever tried to simulate a CPU architecture including caches in software?
>
> Yes, several. What's the big deal about emulating caches?
>

Simulating a complete architecture is a pain in the ass.
Of course they're making life hard on themselves with byte level granularity.

> > It'd be years before you get any results.
> > They where about to find some investors (that's why they started doing those talks) and start working on an
> > FPGA implementation when the patent laws changed and they went full panic mode "file everything asap".
>
> Are you kidding? It takes maybe a few weeks to write an emulator of something that is architecturally
> similar enough to the Mill idea to be able to do some quantitative analysis. Let's say that you start
> with a plain really wide VLIW with instruction set and limitations similar to Mill. Then you define
> some fast registers that are about equivalent to the belt and some slow registers that correspond to
> scratch pad. Other mechanisms can be simplified in similar way. The idea is to map your architecture
> to a simple enough architecture that you don't spend more than a few months reworking one of the open-source
> compilers to generate some half-decent code. Then you do some quantitative analysis and try to attack
> the sore points. I'm sure you'll find more than RichardC has listed so far.

Do you think a massively simplified version will put up numbers that'll impress anyone?
Yes, if they've never verified that their concept works they'll have a problem.

>
> The alternative of course is you pretend all is great, go looking for naive investors,
> and while your are at it you go to RWT to try to make some hype and have several anonymous
> people talking favorably of it to maybe convince some non believers.
>
> If there's no compiler and no emulator in any form of even something architecturally similar to what you are
> selling after so many years, it's not difficult to conclude the game is about striking luck with some patents.

http://millcomputing.com/topic/simulation/#post-1547
They have something, which they have probably shown investors.
Doesn't mean they have to show everyone their cards yet.

So they're trying to make money by patenting something that doesn't even work?

This seems like the highest effort, lowest reward (none) scam if you are right.