ISA vs. patent/trademark

[...]

Similar case with the NEC V20/Intel 8088

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen
Loading thread data ...

to

better

paper by

I note that the Itanium ISA is covered by a patent on its unique method of explicitly indicating parallelism. The more conventional way of indicating parallelism, by a 'parallel' bit on each instruction, was used on TI signal processing chips.

I'm sad to hear that there is a patent on the ARM Thumb instruction set that extends to the general principle, because something like it is what the PowerPC architecture desperately needs - so that people can use it the way IBM wants, without compromising the architecture.

John Savard

Reply to
jsavard

Note that this was because Intel *copyrighted* the mnemonics, rather than trademarking them, however.

John Savard

Reply to
jsavard

Yep - the V20 contained the 8080 instruction set as well.

I wrote a CP/M handler running on a PC/XT with V20.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

It always puzzled me as to how Intel could get a copyright on instruction mnemonics. This struck me as being akin to someone copyrighting the Latin alphabet. An AND, is an AND, is an AND,...

Reply to
Everett M. Greene

It's not the unaligned load/store per se that is patented; many processors have done that.

What MIPS invented and patented was the idea that instead of having the hardware deal with unaligned bus accesses, they require software to issue *two* instructions to do an unaligned access. One does the "left part" and one does the "right part" of the word.

The normal MIPS load and store instructions require alignment just as on most other RISC processors.

Reply to
Eric Smith

Are you asserting that the IBM 801 papers didn't tie it all together in a single coherent bundle?

Reply to
Eric Smith

AFAIK the validity of the copyright on the mnemonics was never tested in court. It seems unlikely that it would be upheld.

Reply to
Eric Smith

The earliest 801 paper I'm familiar with was published in 1982. While the project certainly tied things together in a coherent RISC bundle before the RISC and MIPS projects (as both Hennessy and Patterson acknowledge), Patterson and Ditzel is the first publication I'm aware of that does.

--
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
 Click to see the full signature
Reply to
Joe Pfeiffer

Thanks for clarification, thats okay then!

Perhaps it worth inventing/patenting same idea for exactly 3 & 4 & 5 instructions too:-)

johnjakson at usa dot com transputer2 at yahoo dot com

Reply to
JJ

There are Freescale (formerly Motorola) PowerPC microcontrollers with code compression (look for the MPC562 on the Freescale website, for example). The do not use an alternative instruction set like the Thumb - instead, it is a more dynamic compression. Software utilities compress your executable and generate tables which you must load into the decompressor's lookup table ram on startup. The decompressor is part of the instruction pre-fetch burst controller, which passes fully decompressed instructions on to the main cpu core. This makes it more flexibile than the Thumb technique, and you get the full power of the core rather than a subset, but it's more of a hassle to configure (and probably awkward for debugging).

Reply to
David

I didn't think it was on Thumb instructions, but on the method of switching between ARM and Thumb execution (using the LSB of the PC to indicate which mode you're in).

Forget Thumb anyway, it's rubbish. What patents there are on Thumb2 should be more interesting.

Cheers, Jon

Reply to
Jon Beniston

In article , snipped-for-privacy@beniston.com (Jon Beniston) writes: |> |> > I'm sad to hear that there is a patent on the ARM Thumb instruction set |> > that extends to the general principle, because something like it is |> > what the PowerPC architecture desperately needs - so that people can |> > use it the way IBM wants, without compromising the architecture. |> |> I didn't think it was on Thumb instructions, but on the method of |> switching between ARM and Thumb execution (using the LSB of the PC to |> indicate which mode you're in).

Totally different from using the top bit, as was done on the IBM 370 range and others, of course.

Regards, Nick Maclaren.

Reply to
Nick Maclaren

This must be a misstatement or it's a ridiculous patent. How can a patent be issued for NOT doing something? I can get a patent for an anchor that requires the addition of propulsion and lifting surfaces so that it can fly on its own?

There's also the "obvious to anyone experienced with the technology" thing.

--
----------------------------------------------------------------------
Everett M. Greene  (The Mojave Greene, crotalus scutulatus scutulatus)
 Click to see the full signature
Reply to
Everett M. Greene

perform a

or

processors

the

as

It's a poor statement; it's not a ridiculous patent, although, as I have explained before in comp.arch [search: mashey lwl], in retrospect, I'd just as soon we hadn't done it. Even though it was easy at the time [Summer 1985], but turned out to get far less use than we'd expected, at least partly because the rise of RISCs with strict alignment got many people to clean up code. As noted elsewhere, if I were doing it again, I'd probably do something different.

The patent is 4,814,976 by Hansen & Riordan.

The *point* of the patent was that if you have a straightforward RISC pipeline that supports caches and paged virtual memory, then requiring hardware to do all the work of handling arbitrarily-aligned data [i.e., crossing cache-line or worse, page boundaries] adds *greatly* to the implementation complexity, and one doesn't want to do this. [The implementation penalty for some microcoded CISCs cn be much less.]

The MIPS solution was some much simpler hardware (very minimal additions, and nothing tricky] beyond what was there, that allowed compilers to generate code to deal with unaligned accesses that sometimes came up from legacy code without burdening the base hardware design.

[This is one of those classic "It takes a bunch of hardware to make this both fast and right, and it means a lot of checking for cases that hardly ever happen, but if the hardware is wrong, the bugs are horrible to find." cases that hardware designers hate.]
Reply to
John Mashey

who

bookshop), but

RISC

NIOS

dedicated

lot

similar" at

See

formatting link

NIOS II is clearly different from MIPS I, but I'd guess that whoever designed NIOS II was quite familiar with MIPS, as a lot of nomenclature (register names, many of the register allocations, some opcode names) are rather MIPS-reminiscent. Of course, lots of ISAs have borrowed from each other, and and ADD is an ADD :-). However, of 32 registers, at least 25 [0-23, 31] are allocated exactly as in MIPS, and generally have same names, even when those aren't obvious.

People may recall my comments in the WIZ discussion about wishing not to have done MUL and DIV the way we did in MIPS, but to have done it more like the way Alpha did it later, and NIOS II does that. NIOS II has no (MIPS) LUI instruction, but has ANDHI, ORHI, XORHI. We almost did ANDHI or ORHI (as they subsume LUI, but have other uses), but thought about it a little too late [Summer 1985] to get in.

In general, NIOS II feels like a sensible design for a small embedded core, a bit more like MIPS than like any other RISC, but in general, doing things different that in fact match with things that in retrospect, we might well ahve done different.

Reply to
John Mashey

And the Nick Maclaren comment is that most of those codes are so horrible that they probably aren't getting right answers anyway. I strongly disapprove of fixing up alignment in software - it is much better to diagnose the failure and get the programmer to fix the broken code.

Notice that this requires the hardware to do even less :-)

Regards, Nick Maclaren.

Reply to
Nick Maclaren

John Mashey wrote: [re. misaligned load patent]

I have never seen either the patent or the relevant MIPS asm code generated, but it seems to me that the hw I'd want would look like this:

a)

LoadAligned r1=[r0]

where any low-order bits in r0 would be ignored.

b)

either

LoadAligned r2=[r0+regsize]

or

LoadAlignedRight r2=[r0]

Both of these would load the next aligned word

c) (The somewhat tricky one!)

ShiftToAlign r3=r1,r2,r0

which is defined to merge r1 & r2, using the loworder bits from r0 to determine the number of bytes to shift.

Since this opcode takes four register operands, I'd suggest forcing the destination to be the same as the low-order source register, i.e.:

ShiftToAlign r1=r2,r0

defined as

r1 = (r1 >> (r0 & 7)*8) | (r2

Reply to
Terje Mathisen

I don't buy this argument, at least some of the time.

I can think of atleast 1 application in mind which guarantees most accesses not aligned and for which a SW aligned version would be ugly either by doing the align in SW or by accessing sequential bytes.

Example parser performing lexing of string matches straight from the lcc compiler by Hanson-Fraser..

In lcc each pattern match is something like this, mostly auto generated for a given dictionary, so for matching "while"

if (cp[0]=="while"[0] && cp[1]=="while"[1] && cp[2]=="while"[2] && cp[3]=="while"[3] && cp[4]=="while"[4]) xxxx

This obviously requires 5 possible byte matches and 5 conditional branches, and most matches will fail until the right production rule is reached and all matches pass.

VC6 compiler produces good code without trying, lots of byte cmp and bxx.pairs

In a rewrite I'd would (and do) use if (same5(cp,"while")) xxxx

where same5 is an inlined match of 2 longs, at byte offset 0, then 1. Now thats 2 long matches and 2 branches.

Now C might have a tiny dictionary of mostly small words but the Verilog language has 200 plus words and many can be as long as 20chars with many words giving false initial matches.

So there is an inline sameN as fn() from 1 to 20chars which takes upto

5matches ie 4x less work. Again VC6 produces good asm, nearly 4x less than using byte serial checking.

Ofcourse I know this is a problem for RISCs that don't do nonaligned accesses, but I really hate to see code 4x slower even if its probably

Reply to
JJ

All of this was fairly well-covered in a *1988* comp.arch thread called "RISC data alignment", including the reasons why computer *vendors* were forced to deal with these alignment issues, i.e., IBM (& then DEC VAX) FORTRAN (interaction of EQUIVALENCE & COMMON, INTEGER*2, and sometimes call-by-reference) .

Reply to
John Mashey

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.