Scali wrote:

That's the same thing, isn't it? I mean, the subject of Intel honouring the agreement or not was the i386, which Intel didn't be […]
Show full quote

gdjacobs wrote:

Actually, the case revolved primarily around Intel honoring the 1982 agreement (they were allowed to bargain stringently, not shut the door completely)

That's the same thing, isn't it?
I mean, the subject of Intel honouring the agreement or not was the i386, which Intel didn't believe they had to share with AMD.
Given the fact that AMD didn't offer Intel any products that were in the same ballpark, Intel was not required to do so. The court admitted this much.

Ultimately the Supreme Court of California disagreed. There's a difference between entering into negotiations with an open mind and entering with the objective of torpedoing everything.

Scali wrote:

It is not specific as to *which* patents though. Other sources say they are about microcode: https://en.wikipedia.org/wiki/Advan […]
Show full quote

gdjacobs wrote:

The 1976 deal was about patents.
https://books.google.ca/books?id=i3MLYUjRWisC … license&f=false

It is not specific as to *which* patents though.
Other sources say they are about microcode: https://en.wikipedia.org/wiki/Advanced_Micro_Devices

When Intel began installing microcode in its microprocessors in 1976, it entered into a cross-licensing agreement with AMD, granting AMD a copyright license to the microcode in its microprocessors and peripherals, effective October 1976.

And that is why AMD pointed to the 1976 deal when claiming they had the rights to the 386 microcode. Which they didn't.

I haven't found any authoritative sources that hint at or state this. I sometimes like to double check what Wikipedia posts.

gdjacobs wrote:

Ultimately the Supreme Court of California disagreed. There's a difference between entering into negotiations with an open mind and entering with the objective of torpedoing everything.

No, that's not what I meant.
I meant that the subject is the same. Please re-read what I wrote more carefully.
You're basically describing 'the other side of the elephant'. It's still an elephant. In this case the 'elephant' is bargaining of the 386 manufacturing package.

gdjacobs wrote:

I haven't found any authoritative sources that hint at or state this. I sometimes like to double check what Wikipedia posts.

Then you could have found for example this: https://www.sec.gov/litigation/admin/3437730.txt

In 1976, AMD entered into a contract with Intel that gave AMD a license to certain Intel patents and microprocessor microcode co […]
Show full quote

In 1976, AMD entered into a
contract with Intel that gave AMD a license to certain Intel
patents and microprocessor microcode copyrights (the "1976
Agreement").

Anyway, Intel already established that microcode was subject to copyright in an earlier court case against NEC with the V20/V30.
It was ruled however that the V20/V30 microcode was different enough not to violate the copyright directly (NEC having the same cross-license as AMD, being another second-source to Intel).

Therefore the arbitration on the 287/386 microcode copyright infringement of AMD says this:

The arbitrator stated that the intent of the award was to allow AMD to produce and sell its reverse-engineered version of Intel' […]
Show full quote

The arbitrator stated that the intent of the award was to allow
AMD to produce and sell its reverse-engineered version of Intel's
386 computer chip. The arbitrator, however, specified that he
was not expressing any opinion as to whether any Intel
intellectual property rights were incorporated in any of the
Am386 microprocessor family or whether any Am386 microprocessors
infringed any Intel intellectual property rights.

So basically they're saying they want to give AMD the right to use the microcode, but despite giving them this right, that does not imply that they did not infringe the copyright.
Very important there.

Scali wrote:

No, that's not what I meant. I meant that the subject is the same. Please re-read what I wrote more carefully. You're basically […]
Show full quote

gdjacobs wrote:

Ultimately the Supreme Court of California disagreed. There's a difference between entering into negotiations with an open mind and entering with the objective of torpedoing everything.

No, that's not what I meant.
I meant that the subject is the same. Please re-read what I wrote more carefully.
You're basically describing 'the other side of the elephant'. It's still an elephant. In this case the 'elephant' is bargaining of the 386 manufacturing package.

I just think it's important to capture the subtleties of this point as much of the ultimate ruling rode on it.

Scali wrote:

Then you could have found for example this: https://www.sec.gov/litigation/admin/3437730.txt […]
Show full quote

gdjacobs wrote:

I haven't found any authoritative sources that hint at or state this. I sometimes like to double check what Wikipedia posts.

Then you could have found for example this: https://www.sec.gov/litigation/admin/3437730.txt

In 1976, AMD entered into a contract with Intel that gave AMD a license to certain Intel patents and microprocessor microcode co […]
Show full quote

In 1976, AMD entered into a
contract with Intel that gave AMD a license to certain Intel
patents and microprocessor microcode copyrights (the "1976
Agreement").

Anyway, Intel already established that microcode was subject to copyright in an earlier court case against NEC with the V20/V30.
It was ruled however that the V20/V30 microcode was different enough not to violate the copyright directly (NEC having the same cross-license as AMD, being another second-source to Intel).

Therefore the arbitration on the 287/386 microcode copyright infringement of AMD says this:

The arbitrator stated that the intent of the award was to allow AMD to produce and sell its reverse-engineered version of Intel' […]
Show full quote

The arbitrator stated that the intent of the award was to allow
AMD to produce and sell its reverse-engineered version of Intel's
386 computer chip. The arbitrator, however, specified that he
was not expressing any opinion as to whether any Intel
intellectual property rights were incorporated in any of the
Am386 microprocessor family or whether any Am386 microprocessors
infringed any Intel intellectual property rights.

So basically they're saying they want to give AMD the right to use the microcode, but despite giving them this right, that does not imply that they did not infringe the copyright.
Very important there.

I actually read that document but didn't twig on the original mention of microcode. Thanks for finding it. Anyway, I don't dispute anything on this point. AMD definitely violated the Chinese wall. You and I aren't on the same page with respect to negotiating technology transfers under the 1982 agreement. The SCC felt that Intel should have found a way to make the negotiations work had they acted in good faith. Even if Intel felt the 386 was far more valuable than anything AMD had to trade, they could undoubtedly have traded elements of the design.

gdjacobs wrote:

The SCC felt that Intel should have found a way to make the negotiations work had they acted in good faith.

That's not how I read it.
How I read it was:
1) Intel may not have put in much effort in trying to make the negotiations work
2) However, AMD didn't really have much to negotiate with, and AMD also was rather lax in dealing with the failing negotiations.

gdjacobs wrote:

Even if Intel felt the 386 was far more valuable than anything AMD had to trade, they could undoubtedly have traded elements of the design.

They could, but I don't see how Intel would be in any way obliged to do so. The cross-license was originally meant to create a 'commodity' platform, by making sure that:
1) More than one supplier could manufacture the same chips
2) Development of new chips was coordinated, so companies didn't reinvent the wheel, but built on the platform together.

By the time the 386 came around, the landscape changed completely, and Intel didn't need any other suppliers to manufacture their chips, nor to help develop the platform (which by the way, nobody ever did. The second-source suppliers didn't get beyond Intel's chips and slightly tweaked versions of it. New architectures and chipsets had to come from Intel).

The eventual ruling put them into this position however that they HAVE to trade their crown jewels (and nothing has changed really... the only time AMD made any worthwhile contribution to x86 was with the x64 architecture... which was little more than a 64-bit rehash of the 386... and actually worked against Intel, who wanted to launch a new and modern 64-bit architecture, and abandon x86), and took away the control from their own x86 architecture permanently.

I think it's strange that you can invent a CPU architecture, build up a strong market, and then have your invention taken away from you by some court, because some small-time competitor made illegitimate clones of your CPUs.
Can you imagine a court ruling that Coca Cola has to give the recipe up to Pepsi, just because Pepsi tried to copy cola?

Okay, I'm done. You certainly are entitled to your perspective, but I don't and will never agree with what I consider to be such a heavily biased interpretation of history.

gdjacobs wrote:

Okay, I'm done. You certainly are entitled to your perspective, but I don't and will never agree with what I consider to be such a heavily biased interpretation of history.

You don't have to agree, but I don't see why you would call it heavily biased, when I'm stating facts.
It is a fact that Intel developed the x86 (and its predecessors, with the 4004 being the first mass-produced microprocessor ever).
And it is a fact that AMD cloned Intel's 386 and 486 without having a license at the time, nor giving Intel back any reciprocal technology/products that would entitle them to such a license.
Which makes it a fact that these were illegitimate copies at the time.
It is also a fact that Intel has always been the driving force behind x86 and everything that goes with it (they also developed technologies such as PCI, AGP, PCI-e, USB, Thunderbolt, and SATA).
None of the second-source suppliers contributed much of significance to the x86-world. So Intel never got back much in terms of sharing of technology and developments, which was the original goal of the agreements.

I think I can see who's the 'heavily biased' one here.

Go on. I really laughed at your characterization of the Itanium saga.

gdjacobs wrote:

Go on. I really laughed at your characterization of the Itanium saga.

How is that? The Itanium may not have been the most successful architecture ever, but it certainly was forward-thinking compared to x64, and had some serious potential in various areas (Itanium-based systems were often at or near the top of the top 500 supercomputer list).
x86 only got where it is today because of the massive amount of R&D pumped into it. Considering x86's humble beginnings, any other architecture that would receive the same amount of R&D would have been at least as good.

Do you have any arguments whatsoever? Or did you just read that Itanium was a failure on the internet, like most people, and have absolutely no idea about what the Itanium even is or does? Or an x86 for that matter?
I'd like you to prove that you actually even know what you're talking about on a technical level.

Itanium (VLIW in general) has been by and large a failed experiment. Instruction packing by the compiler seems to work well in some execution patterns (LINPACK does well as you noted), not so well in others. At the same time, traditional superscaler architectures (from IBM for example) have pushed through the same performance thresholds. It seems the cost in real estate and power is worth it for a more powerful, flexible execution front end.

Certainly for the DEC/Compaq/HP customers I know, Itanium seemed like a downgrade compared to Alpha. From a business perspective, partnering with Intel made a lot of sense. It allowed HP to avoid the cost of pushing the Alpha and PA-RISC architectures ahead and the business headaches of foundry hunting (Intel is definitely ahead of everyone else on this) for a dwindling market segment. From a performance perspective, it wasn't all roses.

Anyway, I'm not going to discuss this further. I think I've gone 10 rounds with you on the same subject before, and I don't want to repeat the process and continue derailing the thread.

gdjacobs wrote:

Itanium (VLIW in general) has been by and large a failed experiment. Instruction packing by the compiler seems to work well in some execution patterns (LINPACK does well as you noted), not so well in others.

So?
I sense a complete lack of vision, comprehension or historical awareness.
Do you think x86 still works the same way as it did when the 8086 debuted back in 1978? Things could not be further from the truth.
Both the CPU architectures and compilers have changed massively over the years.
x86 was once an in-order CISC CPU, not even pipelined. But look at what it has become today... A superscalar pipelined post-RISC backend, with an x86-to-micro-op frontend and out-of-order rescheduling logic inbetween.

In that light, claiming Itanium is a failed experiment is nothing short of ridiculous.
Both compilers and the CPUs themselves can and have been improved tremendously over the years. The conclusions of "the compilers don't work" date mainly to the very early days of Itanium, and mainly voiced by the competition. Nothing about these issues was insurmountable. If x86 taught us anything, then that would be it.

There's absolutely no reason why an Itanium CPU couldn't 'peel out' the micro-ops from the EPIC instruction bundles, and schedule them out-of-order on the fly, for example. x86 does basically the same thing, for basically the same reason: it's impossible to create an efficient x86 compiler. So instead, x86 now works like a RISC CPU. And it's easy to create an efficient RISC compiler. The CPU handles the rest of the gory details on-the-fly.

Editing out any snarky talk here.

gdjacobs wrote:

It seems the cost in real estate and power is worth it for a more powerful, flexible execution front end.

This statement lacks the context and detail to give it any meaningful interpretation.

gdjacobs wrote:

The whole point of EPIC was to simplify the front end and repurpose the silicon real estate and power budget saved.

The same goals as RISC then, just a slightly different view on how to go about doing this.
By your logic, RISC was a similar failure, since RISC CPUs work mostly like x86 these days, translating instructions to an internal format first, and re-scheduling them. Original RISC was meant to decode instructions directly, and execute them in-order.
However, the fact that they are based on a less archaic instructionset than x86 still gives them some benefit in terms of power consumption/efficiency. See eg ARM vs x86 SoCs.

gdjacobs wrote:

What you're suggesting is another superscalar architecture. Which is what Itanium was ostensibly meant to replace.

Depends on whether or not you consider EPIC superscalar.
If you define a superscalar architecture as an architecture that has two or more parallel execution pipelines, being fed different instructions from a single instruction stream, then technically EPIC qualifies.
However, if you are to claim that the way the bundles in the instruction stream are packed make it effectively multiple instruction streams, then yes you could argue that EPIC isn't really superscalar, but rather a derivative.
It is still general-purpose though, unlike eg the GPU approach with SIMD/VLIW etc, where you feed the same instruction to multiple units, which has a lot of downsides for many general purpose algorithms.

In that sense, EPIC is fundamentally different from VLIW in practice.
You could say that EPIC is where VLIW and superscalar meet.

And you could argue that it might be a good starting point for adding more traditional modern superscalar out-of-order logic to the CPU. The instructions being fed in explicitly parallel form, as well as the various 'predicates' compiled into the code gives you extra pre-knowledge to schedule the instructions more efficiently than traditional CISC/RISC instructionsets.

Ok guys, I don't see this discussion going anywhere and the tone is getting personal. Let's agree to disagree, shall we?

I apologize that I posted that stuff. It wasn't an attempt to be sneaky or anything. I let myself be drawn in before I reconsidered continuing the discussion. I'm in agreement, we should just stop.

🤣 they are basically identical...

wowie that's a necro of a thread

why that color as background? its had to even see the lines

PhilsComputerLab wrote:

Ok guys, I don't see this discussion going anywhere and the tone is getting personal. Let's agree to disagree, shall we?

They can't disagree as the two parties have no common ground regarding the subject discussed.
Scali is professional(just take a look at his blog) who knows his things from experience(theory + practice) whereas the "opponent" is typing hot air.