An article in the New York Times about Dr. Ivan Sutherland's recommendation
for how the U.S. could take the lead in semiconductors was mentioned in
alt.folklore.computers, but without details on its content.
So I went and took a look; what he recommended was looking into
superconducting circuits.
This is indeed a promising technology. So is quantum computing, and so are
carbon nanotubes and boron nitride.
I think that I _do_ agree that superconducting electronics is a technology that
is being neglected despite the level of promise it holds - unlike the others,
which seem to be chased by many private companies.
Silicon, though, keeps improving enough to have stayed ahead of at least
some technologies viewed as superior. Thus, "stretched silicon" has allowed
silicon to behave as if it was gallium arsenide, and thus it ended up not being
outflanked by gallium arsenide.
The main quarrel I have with Dr. Sutherland's view, though, is not that
there's anything wrong with directing some funding towards
superconducting electronics. I'm all for that.
The thing is, though, this should be done with a clear understanding of
why it is being done, and what such expenditures are for.
Their purpose would be to keep the U.S. in the game - and put it in a
leadership position - *after* Moore's Law died, and the last remnants of
Dennard Scaling went away, leaving little further improvement in energy
efficiency at smaller feature sizes.
It would not be to make the United States the leader _now_.
Presumably, "leadership" would mean that suddenly AMD, IBM, Motorola,
RCA, Fairchild, and National Semiconductor all suddenly took checkbooks
in hand, and started building their own leading-edge fabs once again.
In order to make this possible, one thing the U.S. government would have
to do is force Intel to license the x86 architecture to Motorola, RCA,
Fairchild, and National Semiconductor, so that these companies would
have access to the microprocessor market; otherwise, what's the point of
having a leading-edge fab?
And the United States would presumably have to contact NXP, too, and
make a deal, so that Motorola, Fairchild, National Semiconductor, as well
as AMD and Intel could all start making 68000-architecture chips as well
(with a 64-bit extension to the architecture) to provide a more diverse
computer ecosystem.
Intel made smartphones running Android on x86 chips for a while.
The POWER architecture is an *American* RISC architecture, The
feasibility of making the PowerPC ISA the new standard for Android
should be investigated (and I suppose RISC-V and MIPS are other
potential candidates). However, this is less urgent, since in general
companies don't have issues getting licenses to make ARM chips,
although recently Qualcomm ran into a snag.

John Savard

In article <012341f1-6ec4-4c93-8180-72916f27fbe0n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> Intel made smartphones running Android on x86 chips for a while.

They did, but almost nobody bought them. Google's Android app build
system still defaults to building native code for x86 as well as ARM, but
it goes almost completely unused.

> The POWER architecture is an *American* RISC architecture, The
> feasibility of making the PowerPC ISA the new standard for Android
> should be investigated (and I suppose RISC-V and MIPS are other
> potential candidates).

POWER is not significantly optimised for low power usage. One of Apple's
major reasons for switching Macs from POWER to x86 was that they could
not get IBM to build them POWER processors with a performance-per-watt
that was competitive with x86, let alone ARM. They then did iOS as an ARM
platform, and liked that enough that they switched Macs again.

I don't know how possible it is to create low-wattage fast POWER
implementations, but there would presumably be a lot of development
required.

I asked about Android on RISC-V, and it isn't happening just yet: Google
are going to do it, but there are a bunch of issues with RISC-V that need
to be dealt with, linked from the discussion at:
<https://groups.google.com/g/android-ndk/c/CR5mcMu_x80>

MIPS is not a candidate: MIPS Technologies have abandoned it in favour of
RISC-V.
<https://www.eejournal.com/article/wait-what-mips-becomes-risc-v/>

> However, this is less urgent, since in general companies don't
> have issues getting licenses to make ARM chips, although recently
> Qualcomm ran into a snag.

Quite a lot of ARM's design work is done in Austin, Texas. What was
Qualcomm's problem?

John

On Wednesday, April 26, 2023 at 6:06:42 PM UTC-5, John Dallman wrote:
> In article <012341f1-6ec4-4c93...@googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) wrote:
>
> > Intel made smartphones running Android on x86 chips for a while.
> They did, but almost nobody bought them. Google's Android app build
> system still defaults to building native code for x86 as well as ARM, but
> it goes almost completely unused.
> > The POWER architecture is an *American* RISC architecture, The
> > feasibility of making the PowerPC ISA the new standard for Android
> > should be investigated (and I suppose RISC-V and MIPS are other
> > potential candidates).
> POWER is not significantly optimised for low power usage. One of Apple's
> major reasons for switching Macs from POWER to x86 was that they could
> not get IBM to build them POWER processors with a performance-per-watt
> that was competitive with x86, let alone ARM. They then did iOS as an ARM
> platform, and liked that enough that they switched Macs again.
>
> I don't know how possible it is to create low-wattage fast POWER
> implementations, but there would presumably be a lot of development
> required.
<
good-fast-cheap:: choose any 2.
>
> I asked about Android on RISC-V, and it isn't happening just yet: Google
> are going to do it, but there are a bunch of issues with RISC-V that need
> to be dealt with, linked from the discussion at:
> <https://groups.google.com/g/android-ndk/c/CR5mcMu_x80>
>
> MIPS is not a candidate: MIPS Technologies have abandoned it in favour of
> RISC-V.
> <https://www.eejournal.com/article/wait-what-mips-becomes-risc-v/>
> > However, this is less urgent, since in general companies don't
> > have issues getting licenses to make ARM chips, although recently
> > Qualcomm ran into a snag.
> Quite a lot of ARM's design work is done in Austin, Texas. What was
> Qualcomm's problem?
>
> John

On Wednesday, April 26, 2023 at 6:06:42 PM UTC-5, John Dallman wrote:

> Quite a lot of ARM's design work is done in Austin, Texas. What was
> Qualcomm's problem?
<
Cost structure of ARM licensing.
>
> John

On Wednesday, April 26, 2023 at 5:06:42 PM UTC-6, John Dallman wrote:

> Quite a lot of ARM's design work is done in Austin, Texas. What was
> Qualcomm's problem?

They paid for a license to the ARM architecture that let them design
their own chips.

They bought a company that also had an ARM license which was working
on a chip design that they found useful.

ARM told them that because ARM *licenses* aren't transferable, this
also meant that the work the other company did on a new chip, under
their license, couldn't be used under Qualcomm's license.

Qualcomm found this to be wasteful, and double-dipping, and so
it went to court. ARM retaliated by raising the fees to license ARM,
at least for companies like Qualcomm.

If ARM does not lose in the courts soundly, Android will need to be
ported, or smartphones will become expensive.

John Savard

jgd@cix.co.uk (John Dallman) writes:
> ... They then did iOS as an ARM
> platform, and liked that enough that they switched Macs again.

ISTR that they acquired a company to bring in-house ARM design talent (P.A.
Semi?)--I'm pretty sure this was right around the time of the first iPhone.
From that point, many people were waiting for the rest of Apple to follow.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Wednesday, April 26, 2023 at 11:06:41 AM UTC+1, Quadibloc wrote:

> as AMD and Intel could all start making 68000-architecture chips as well
> (with a 64-bit extension to the architecture)

look up apollo project, named the 68080. pretty awesome.

> to provide a more diverse
> computer ecosystem.
> Intel made smartphones running Android on x86 chips for a while.
> The POWER architecture is an *American* RISC architecture, The
> feasibility of making the PowerPC ISA the new standard for Android
> should be investigated

on it. needs a serious upgrade first: it's been 12 years, IBM has focussed on VSX,
leaving the Scalar instructions anaemic. i'm correcting that.
https://libre-soc.org/openpower/sv/rfc

> (and I suppose RISC-V

er no. https://news.ycombinator.com/item?id=24459314

benchmarks for RISC-V systems show an astonishing 25% of ARM or x86
figures.

> potential candidates). However, this is less urgent, since in general
> companies don't have issues getting licenses to make ARM chips,
> although recently Qualcomm ran into a snag.

no: qualcomm bought Nuvia, where Nuvia specifically had a NON TRANSFERRABLE
Architectural License. qualcomm then refused to cease and desist use of UNLICENSED
technology.

basically qualcomm's lawyers fucked up by failing to do Due Diligence on Nuvia,
and then decided that their best interests would be served by exploiting the US Court
system by first suing ARM then publishing what would normally be Defamation but
in a Court case is considered "legal opinion".

ARM intends to compete with its own licensees now.

l.

Andy Valencia <vandys@vsta.org> writes:
>jgd@cix.co.uk (John Dallman) writes:
>> ... They then did iOS as an ARM
>> platform, and liked that enough that they switched Macs again.
>
>ISTR that they acquired a company to bring in-house ARM design talent (P.A.
>Semi?)

Yes, they bought P.A.Semi and their CPU core design expertise is
presumably the basis for Apple's own cores, starting with the Swift
core in the Apple A6 in 2012. Before that, Apple used ARM-designed
cores. And the reason for that is that P.A.Semi had no ARM
experience. They had designed a PowerPC implementation in the hope of
selling it to Apple, but Apple decided to switch to Intel, and as a
result, they could buy P.A. Semi for cheap.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, April 28, 2023 at 7:22:11 PM UTC-6, luke.l...@gmail.com wrote:

> no: qualcomm bought Nuvia, where Nuvia specifically had a NON TRANSFERRABLE
> Architectural License. qualcomm then refused to cease and desist use of UNLICENSED
> technology.

This does not make sense.

If Qualcomm did not have an architectural license of its own, then indeed they couldn't
get one by buying Nuvia, since Nuvia's architectural license wasn't transferable. I'm not
disputing that.

But that should have absolutely nothing to do with the ARM design Nuvia made with
its architectural license, since Qualcomm has an architectural license of its own.

Apparently, ARM's licenses must have some very tricky clauses in them, covering
other things besides the license itself - since this kind of behavior could lead to
waste - specifically of the time and effort spent by Nuvia's engineers - the government
should intervene and squash ARM's lawsuit pre-emptively, because human effort is
a scarce resource, and we can't afford to waste any of it when it could be making our
country richer.

John Savard

Quadibloc wrote:
> On Friday, April 28, 2023 at 7:22:11 PM UTC-6, luke.l...@gmail.com wrote:
>
>> no: qualcomm bought Nuvia, where Nuvia specifically had a NON TRANSFERRABLE
>> Architectural License. qualcomm then refused to cease and desist use of UNLICENSED
>> technology.
>
> This does not make sense.
>
> If Qualcomm did not have an architectural license of its own, then indeed they couldn't
> get one by buying Nuvia, since Nuvia's architectural license wasn't transferable. I'm not
> disputing that.
>
> But that should have absolutely nothing to do with the ARM design Nuvia made with
> its architectural license, since Qualcomm has an architectural license of its own.

I'm guessing Arm's view is that Nuvia's non-transferable architectural
license was voided the moment Nuvia was purchased by Qualcomm since
the entity Nuvia no longer exists. Thus any derived designs became
unlicensed.

I do wonder just what is being licensed with an "architectural license"
as any new design (microarchitecture) would be the designer's own I.P.
and I don't think an ISA can be protected by copyright or patent.
The license might just be a promise to not sue you by a big company
with very deep pockets.

DEC reputedly had such an approach to people selling their own designed
boards that plugged into the Unibus - the threat of being endlessly sued
by a large company was enough to get most people to make the business
decision to sign, irrespective of the rightness of their position.

> Apparently, ARM's licenses must have some very tricky clauses in them, covering
> other things besides the license itself - since this kind of behavior could lead to
> waste - specifically of the time and effort spent by Nuvia's engineers - the government
> should intervene and squash ARM's lawsuit pre-emptively, because human effort is
> a scarce resource, and we can't afford to waste any of it when it could be making our
> country richer.
>
> John Savard

This is just two big businesses playing chicken as a negotiation tactic.
Once the amount of pain money exceeds the amount of reward money for
one side or the other, they will settle.
Then it's hookers and cocaine all around.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>I do wonder just what is being licensed with an "architectural license"
>as any new design (microarchitecture) would be the designer's own I.P.
>and I don't think an ISA can be protected by copyright or patent.

It seems that the industry agrees that an ISA can be monopolized
("protected") in some way. What I imagine is that individual
instructions are patented; ARM has some innovative ones in the A64
instruction set, and patent law as practiced seems to set a low bar
for making things patentable.

Maybe the encoding is monopolized in some way. Could it be copyright?
Maybe the argument is that the decoder in the CPU core is a
derived work of the copyrighted encoding.

>The license might just be a promise to not sue you by a big company
>with very deep pockets.

Given the difference in revenue between Apple and ARM, it seems to me
that ARM has real teeth, or Apple would not pay the license fee to
them; OTOH, I don't know how small the license fee is that Apple pays.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Saturday, April 29, 2023 at 6:09:52 PM UTC+1, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >I do wonder just what is being licensed with an "architectural license"
> >as any new design (microarchitecture) would be the designer's own I.P.
> >and I don't think an ISA can be protected by copyright or patent.

if represented as mathematics - which it is - no an ISA may not
be Copyrighted. the document *containing* the descriptive words
may be made Copyright, but the *mathematical concepts* may not.
(i used this loophole to extract the *concept* of the Power ISA
into machine-readable form, despite the implementations being
IBM Copyright CC 4.0 Licensed in the case of Microwatt, and
directly from the Power ISA 3.0 Specification - IBM Copyright
at the time - now the Copyright of the OpenPOWER Foundation).

except those fucking morons Oracle tried to do exactly that:
consider an "API" to be "Copyrightable" which given that ISAs are
a form of an "API", it would have meant that retrospectively
every single ISA suddenly became Copyright material. which
would have been a serious world-wide fuckup. so deeply
irresponsible and greedy that they decided "Java APIs" were
Copyrighted material, absolutely no thought whatsoever for
the devastating consequences *including for themselves*.
boo hoo hoo.

> It seems that the industry agrees that an ISA can be monopolized
> ("protected") in some way.

Trademark Law. the *name* of the ISA may be protected.

if you rename the ISA and *in no way* make *any* mention of
its origins (no "this is ARM-like" or "this is ARM-compatible")
you get away with it. of course, you are highly likely in any
implementation to run smack into a shit-load of patents (not
just from ARM but from Intel, NVIDIA, AMD, IBM, Samsung)
but that is another matter entirely.

> What I imagine is that individual
> instructions are patented;

no, any special innovations of the *implementation* underneath the
instruction it may be patented.

> ARM has some innovative ones in the A64 instruction set,

*snort*.

> Maybe the encoding is monopolized in some way. Could it be copyright?

no. it's an API (effectively).
> Maybe the argument is that the decoder in the CPU core is a
> derived work of the copyrighted encoding.

which cannot be copyrighted because it is a mathematical
concept (and an API).

a particularly efficient *implementation* - a novel *decoder* -
may be patented.

> Given the difference in revenue between Apple and ARM, it seems to me
> that ARM has real teeth,

no, Trademark Law does. Apple - unlike Qualcomm - has respect
for Trademark Law. they don't want *their* Trademark disrupted,
they are on shaky enough ground with the word "apple" as it is.

l.

On Saturday, April 29, 2023 at 12:27:05 PM UTC-5, luke.l...@gmail.com wrote:
> On Saturday, April 29, 2023 at 6:09:52 PM UTC+1, Anton Ertl wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> > >I do wonder just what is being licensed with an "architectural license"
> > >as any new design (microarchitecture) would be the designer's own I.P.
> > >and I don't think an ISA can be protected by copyright or patent.
> if represented as mathematics - which it is - no an ISA may not
> be Copyrighted. the document *containing* the descriptive words
> may be made Copyright, but the *mathematical concepts* may not.
> (i used this loophole to extract the *concept* of the Power ISA
> into machine-readable form, despite the implementations being
> IBM Copyright CC 4.0 Licensed in the case of Microwatt, and
> directly from the Power ISA 3.0 Specification - IBM Copyright
> at the time - now the Copyright of the OpenPOWER Foundation).
>
> except those fucking morons Oracle tried to do exactly that:
> consider an "API" to be "Copyrightable" which given that ISAs are
> a form of an "API", it would have meant that retrospectively
> every single ISA suddenly became Copyright material. which
> would have been a serious world-wide fuckup. so deeply
> irresponsible and greedy that they decided "Java APIs" were
> Copyrighted material, absolutely no thought whatsoever for
> the devastating consequences *including for themselves*.
> boo hoo hoo.
> > It seems that the industry agrees that an ISA can be monopolized
> > ("protected") in some way.
> Trademark Law. the *name* of the ISA may be protected.
>
> if you rename the ISA and *in no way* make *any* mention of
> its origins (no "this is ARM-like" or "this is ARM-compatible")
> you get away with it. of course, you are highly likely in any
> implementation to run smack into a shit-load of patents (not
> just from ARM but from Intel, NVIDIA, AMD, IBM, Samsung)
> but that is another matter entirely.
> > What I imagine is that individual
> > instructions are patented;
<
> no, any special innovations of the *implementation* underneath the
> instruction it may be patented.
<
It is the method and apparatus of how an instruction performs its work
that can be patented. Sometimes how an instruction is inserted into an
existing ISA can be patented.
<
> > ARM has some innovative ones in the A64 instruction set,
> *snort*.
<
> > Maybe the encoding is monopolized in some way. Could it be copyright?
> no. it's an API (effectively).
<
Not the encoding itself, but how that encoding was chosen to address
several other problems simultaneously, that can be patented (i.e., method)
<
> > Maybe the argument is that the decoder in the CPU core is a
> > derived work of the copyrighted encoding.
<
> which cannot be copyrighted because it is a mathematical
> concept (and an API).
<
Ultimately what can be patented is determined by USPTO and other similar
bodies worldwide.
>
> a particularly efficient *implementation* - a novel *decoder* -
> may be patented.
<
The method and apparatus, not the "input" of the thing being decoded.
<
> > Given the difference in revenue between Apple and ARM, it seems to me
> > that ARM has real teeth,
<
> no, Trademark Law does. Apple - unlike Qualcomm - has respect
> for Trademark Law. they don't want *their* Trademark disrupted,
> they are on shaky enough ground with the word "apple" as it is.
<
This was settled a while back wrt Apple records.
>
> l.

"luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>if represented as mathematics - which it is - no an ISA may not
>be Copyrighted.

Are you confusing copyright and patent law? You cannot patent
mathematical concepts, but you can copyright mathematics texts, and, I
expect, also other expressions of mathematical ideas.

But an ISA is not mathematics.

>> Given the difference in revenue between Apple and ARM, it seems to me=20
>> that ARM has real teeth,
>
>no, Trademark Law does. Apple - unlike Qualcomm - has respect
>for Trademark Law. they don't want *their* Trademark disrupted,
>they are on shaky enough ground with the word "apple" as it is.

Apple may have respect for the trademark law, but I doubt that it's
trademark law that keeps them paying ARM. Just like the CPUs are now
Apple Silicon, they would implement the Apple Architecture if that
would eliminate their payments to ARM. Actually I would not be
surprised if they called it the Apple Architecture if possible, even
if that would not reduce their payments to ARM.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Quadibloc wrote:

>
>I do wonder just what is being licensed with an "architectural license"
>as any new design (microarchitecture) would be the designer's own I.P.
>and I don't think an ISA can be protected by copyright or patent.
>The license might just be a promise to not sue you by a big company
>with very deep pockets.

The ARM architectural license is quite comprehensive and is
beneficial to the licensee in a number of ways. The agreements
themselves are subject, of course, to non-disclosure agreements,
thus you'll not be likely to find examples of the terms in public
forums.

Scott Lurndal <scott@slp53.sl.home> schrieb:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>Quadibloc wrote:
>
>>
>>I do wonder just what is being licensed with an "architectural license"
>>as any new design (microarchitecture) would be the designer's own I.P.
>>and I don't think an ISA can be protected by copyright or patent.
>>The license might just be a promise to not sue you by a big company
>>with very deep pockets.
>
> The ARM architectural license is quite comprehensive and is
> beneficial to the licensee in a number of ways.

That statement is quite opaque (and could come from an ARM
salesman who does not want to go into specifics because there
is something nasty hidden somewhere).

> The agreements
> themselves are subject, of course, to non-disclosure agreements,

Why "of course"?

> thus you'll not be likely to find examples of the terms in public
> forums.

Can you be more specific?

Some of the licence agreements I've heard of are pretty nasty,
such as the licensor owning all improvements made by the licensee.
But that is another area (and companies that sell licenses without
such strings attached sell more - surprise, surprise).

Thomas Koenig <tkoenig@netcologne.de> writes:
>Scott Lurndal <scott@slp53.sl.home> schrieb:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>>Quadibloc wrote:
>>
>>>
>>>I do wonder just what is being licensed with an "architectural license"
>>>as any new design (microarchitecture) would be the designer's own I.P.
>>>and I don't think an ISA can be protected by copyright or patent.
>>>The license might just be a promise to not sue you by a big company
>>>with very deep pockets.
>>
>> The ARM architectural license is quite comprehensive and is
>> beneficial to the licensee in a number of ways.
>
>That statement is quite opaque (and could come from an ARM
>salesman who does not want to go into specifics because there
>is something nasty hidden somewhere).

Or the statement could be from a licensee who is under an NDA.

MitchAlsup wrote:
> On Saturday, April 29, 2023 at 12:27:05 PM UTC-5, luke.l...@gmail.com wrote:
>> On Saturday, April 29, 2023 at 6:09:52 PM UTC+1, Anton Ertl wrote:
>>> EricP <ThatWould...@thevillage.com> writes:
>>>> I do wonder just what is being licensed with an "architectural license"
>>>> as any new design (microarchitecture) would be the designer's own I.P.
>>>> and I don't think an ISA can be protected by copyright or patent.
>> if represented as mathematics - which it is - no an ISA may not
>> be Copyrighted. the document *containing* the descriptive words
>> may be made Copyright, but the *mathematical concepts* may not.
>> (i used this loophole to extract the *concept* of the Power ISA
>> into machine-readable form, despite the implementations being
>> IBM Copyright CC 4.0 Licensed in the case of Microwatt, and
>> directly from the Power ISA 3.0 Specification - IBM Copyright
>> at the time - now the Copyright of the OpenPOWER Foundation).
>>
>> except those fucking morons Oracle tried to do exactly that:
>> consider an "API" to be "Copyrightable" which given that ISAs are
>> a form of an "API", it would have meant that retrospectively
>> every single ISA suddenly became Copyright material. which
>> would have been a serious world-wide fuckup. so deeply
>> irresponsible and greedy that they decided "Java APIs" were
>> Copyrighted material, absolutely no thought whatsoever for
>> the devastating consequences *including for themselves*.
>> boo hoo hoo.
>>> It seems that the industry agrees that an ISA can be monopolized
>>> ("protected") in some way.
>> Trademark Law. the *name* of the ISA may be protected.
>>
>> if you rename the ISA and *in no way* make *any* mention of
>> its origins (no "this is ARM-like" or "this is ARM-compatible")
>> you get away with it. of course, you are highly likely in any
>> implementation to run smack into a shit-load of patents (not
>> just from ARM but from Intel, NVIDIA, AMD, IBM, Samsung)
>> but that is another matter entirely.
>>> What I imagine is that individual
>>> instructions are patented;
> <
>> no, any special innovations of the *implementation* underneath the
>> instruction it may be patented.
> <
> It is the method and apparatus of how an instruction performs its work
> that can be patented. Sometimes how an instruction is inserted into an
> existing ISA can be patented.
> <
>>> ARM has some innovative ones in the A64 instruction set,
>> *snort*.
> <
>>> Maybe the encoding is monopolized in some way. Could it be copyright?
>> no. it's an API (effectively).
> <
> Not the encoding itself, but how that encoding was chosen to address
> several other problems simultaneously, that can be patented (i.e., method)
> <
>>> Maybe the argument is that the decoder in the CPU core is a
>>> derived work of the copyrighted encoding.
> <
>> which cannot be copyrighted because it is a mathematical
>> concept (and an API).
> <
> Ultimately what can be patented is determined by USPTO and other similar
> bodies worldwide.

Afaik, there _are_ no similar bodies anywhere in the
(western/civilized?) world. The USPTO seems to use the classic GitHub PR
approach: LGTM! I.e. just grant the patent, leaving it up to the lawyers
and the court system to figure out which of them should not be valid.

On top of this we have the unique idea of pure SW patents. :-(

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Scott Lurndal wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Quadibloc wrote:
>
>> I do wonder just what is being licensed with an "architectural license"
>> as any new design (microarchitecture) would be the designer's own I.P.
>> and I don't think an ISA can be protected by copyright or patent.
>> The license might just be a promise to not sue you by a big company
>> with very deep pockets.
>
> The ARM architectural license is quite comprehensive and is
> beneficial to the licensee in a number of ways. The agreements
> themselves are subject, of course, to non-disclosure agreements,
> thus you'll not be likely to find examples of the terms in public
> forums.
>

No doubt it offers benefits otherwise no one would sign.
Even if I design my own core I might not want to design everything,
at least not from the start. So I might use someone else's modules for
a memory controller or PCIe adapter.

But such modules are available from many sources so that would be limited
incentive to sign a license. Is there any examples of someone doing their
own core design using an ARM ISA without an Arm license?
To avoid royalties at the low performance, low cost end,
in an FPGA where one has the tools to build it if so desired.
(I haven't heard of anything but I don't track that market.)

I would also expect that it would be a simple matter to just
remove the license-compromised modules. As that does not seem
to have happened, me thinks there must be other factors a-foot.

On Sunday, April 30, 2023 at 10:53:04 AM UTC-5, EricP wrote:
> Scott Lurndal wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >> Quadibloc wrote:
> >
> >> I do wonder just what is being licensed with an "architectural license"
> >> as any new design (microarchitecture) would be the designer's own I.P.
> >> and I don't think an ISA can be protected by copyright or patent.
> >> The license might just be a promise to not sue you by a big company
> >> with very deep pockets.
> >
> > The ARM architectural license is quite comprehensive and is
> > beneficial to the licensee in a number of ways. The agreements
> > themselves are subject, of course, to non-disclosure agreements,
> > thus you'll not be likely to find examples of the terms in public
> > forums.
> >
> No doubt it offers benefits otherwise no one would sign.
> Even if I design my own core I might not want to design everything,
> at least not from the start. So I might use someone else's modules for
> a memory controller or PCIe adapter.
>
> But such modules are available from many sources so that would be limited
> incentive to sign a license. Is there any examples of someone doing their
> own core design using an ARM ISA without an Arm license?
> To avoid royalties at the low performance, low cost end,
> in an FPGA where one has the tools to build it if so desired.
> (I haven't heard of anything but I don't track that market.)
>
> I would also expect that it would be a simple matter to just
> remove the license-compromised modules. As that does not seem
> to have happened, me thinks there must be other factors a-foot.
<
When I was working on SPARC processors for Fujitsu, SUN stated
that SPARC architecture was "Open" and available to all. However,
the MMU, control register architecture were not available, and SUN
hung onto the notion that for them to buy it it had to boot with an
unmodified binary Solaris.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Scott Lurndal wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> Quadibloc wrote:
>>
>>> I do wonder just what is being licensed with an "architectural license"
>>> as any new design (microarchitecture) would be the designer's own I.P.
>>> and I don't think an ISA can be protected by copyright or patent.
>>> The license might just be a promise to not sue you by a big company
>>> with very deep pockets.
>>
>> The ARM architectural license is quite comprehensive and is
>> beneficial to the licensee in a number of ways. The agreements
>> themselves are subject, of course, to non-disclosure agreements,
>> thus you'll not be likely to find examples of the terms in public
>> forums.
>>
>
>No doubt it offers benefits otherwise no one would sign.
>Even if I design my own core I might not want to design everything,
>at least not from the start. So I might use someone else's modules for
>a memory controller or PCIe adapter.
>
>But such modules are available from many sources so that would be limited
>incentive to sign a license. Is there any examples of someone doing their
>own core design using an ARM ISA without an Arm license?
>To avoid royalties at the low performance, low cost end,
>in an FPGA where one has the tools to build it if so desired.
>(I haven't heard of anything but I don't track that market.)
>
>I would also expect that it would be a simple matter to just
>remove the license-compromised modules. As that does not seem
>to have happened, me thinks there must be other factors a-foot.

For the most part, arm architecture licensees provide their own
peripheral IP (internal bus structures, inter-core mesh/crossbar,
memory controllers, pci express controllers, uarts, i2c/i3c
controllers, emmc/sd/SPI/MPI controllers, accelerators, etc).

While they can purchase such IP from ARM (e.g. the PL011 UART),
most will roll their own or use e.g. synopsis synthesizable IP.

Others just purchase the core IP (e.g. Cortex-A, Cortex-M, Cortex-R)
and associated elements (DSU, ETM, CMN-700, GIC-700, SMMU) directly from
ARM and pay royalties for each product using the IP.

I'd suggest that one should consult with legal experts before attempting to
clone the ARM architecture (rather than consulting Usenet).

On Sunday, April 30, 2023 at 6:53:04 PM UTC+3, EricP wrote:
> Scott Lurndal wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >> Quadibloc wrote:
> >
> >> I do wonder just what is being licensed with an "architectural license"
> >> as any new design (microarchitecture) would be the designer's own I.P.
> >> and I don't think an ISA can be protected by copyright or patent.
> >> The license might just be a promise to not sue you by a big company
> >> with very deep pockets.
> >
> > The ARM architectural license is quite comprehensive and is
> > beneficial to the licensee in a number of ways. The agreements
> > themselves are subject, of course, to non-disclosure agreements,
> > thus you'll not be likely to find examples of the terms in public
> > forums.
> >
> No doubt it offers benefits otherwise no one would sign.
> Even if I design my own core I might not want to design everything,
> at least not from the start. So I might use someone else's modules for
> a memory controller or PCIe adapter.
>
> But such modules are available from many sources so that would be limited
> incentive to sign a license. Is there any examples of someone doing their
> own core design using an ARM ISA without an Arm license?
> To avoid royalties at the low performance, low cost end,
> in an FPGA where one has the tools to build it if so desired.
> (I haven't heard of anything but I don't track that market.)
>

I always assumed that without ARM architectural license it is illegal.
So, even if anybody is doing it, he would be unlikely to admit it.

> I would also expect that it would be a simple matter to just
> remove the license-compromised modules. As that does not seem
> to have happened, me thinks there must be other factors a-foot.

On 4/29/2023 9:55 AM, Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> I do wonder just what is being licensed with an "architectural license"
>> as any new design (microarchitecture) would be the designer's own I.P.
>> and I don't think an ISA can be protected by copyright or patent.
>
> It seems that the industry agrees that an ISA can be monopolized
> ("protected") in some way. What I imagine is that individual
> instructions are patented; ARM has some innovative ones in the A64
> instruction set, and patent law as practiced seems to set a low bar
> for making things patentable.
>
> Maybe the encoding is monopolized in some way. Could it be copyright?
> Maybe the argument is that the decoder in the CPU core is a
> derived work of the copyrighted encoding.

A suitably novel encoding method is patentable. Mill has a patent on
its bi-directional encoding.

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> Afaik, there _are_ no similar bodies anywhere in the
> (western/civilized?) world. The USPTO seems to use the classic GitHub PR
> approach: LGTM! I.e. just grant the patent, leaving it up to the lawyers
> and the court system to figure out which of them should not be valid.

I think the US relented in 2012 and allowed opposition procedures,
same as everybody else (only they call it revision, but nevermind).

What I found really funny were "dormant" patents, which were granted,
but not published (which makes nonsense of the idea of a patent).
When they were finally published, their validity started with the
time of publication.

Really weird, I once read a WWII-era patent about some encryption
which was long since obsolete.

> On top of this we have the unique idea of pure SW patents. :-(

That is, indeed, evil, especially if the inventive step is clearly
lacking, ais is often the case.

According to Thomas Koenig <tkoenig@netcologne.de>:
>Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
>> Afaik, there _are_ no similar bodies anywhere in the
>> (western/civilized?) world. The USPTO seems to use the classic GitHub PR
>> approach: LGTM! I.e. just grant the patent, leaving it up to the lawyers
>> and the court system to figure out which of them should not be valid.
>
>I think the US relented in 2012 and allowed opposition procedures,
>same as everybody else (only they call it revision, but nevermind).

US patents have always been examined to ensure that they cover
patentable subject matter, are novel, and not obvious. The first
patent examiner was Thomas Jefferson, as part of his duties as
Secretary of State.

For software patents there has been a long standing problem that the
quality of the examination was poor. A large part of that is that the
novelty check was mostly done by looking at previous patents, but the
vast majority of software techniques are not patented. The 2012 change
allowed third-party challenges in addition to examination.

>What I found really funny were "dormant" patents, which were granted,
>but not published (which makes nonsense of the idea of a patent).

Other than a handful of patents that are classified, there's no such
thing. What does exist is so-called submarine patents where the
applicant keeps amending the application to stretch out the time
until it's granted. That's been somewhat fixed by publishing most
applications after 18 months, whether or not they're granted, and
changing the term to 20 years from filing rather than 17 years from
grant.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly