Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this >repeats until a word without this bit is found. At least that's how I >understand the descriptions of this feature.
The major question I have is why these architectures have this
feature.
The only use I can come up with for the arbitrarily repeated
indirection is the implementation of logic variables in Prolog.
Were there any other usage patterns? What happened to them when the
indirect bit went out of fashion?
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this >repeats until a word without this bit is found. At least that's how I >understand the descriptions of this feature.
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
The major question I have is why these architectures have this
feature.
Were there any other usage patterns? What happened to them when the
indirect bit went out of fashion?
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this repeats until a word without this bit is found. At least that's how I understand the descriptions of this feature.
The major question I have is why these architectures have this
feature.
The only use I can come up with for the arbitrarily repeated
indirection is the implementation of logic variables in Prolog.
However, Prolog was first implemented in 1970, and it did not become a
big thing until the 1980s (if then), so I doubt that this feature was implemented for Prolog.
A use for a single indirection is the implementation of the memory
management in the original MacOS: Each dynamically allocated memory
block was referenced only from a single place (its handle), so that
the block could be easily relocated. Only the address of the handle
was freely passed around, and accessing the block then always required
double indirection. MacOS was implemented on the 68000, which did not
have the indirect bit; this demonstrates that the indirect bit is not necessary for that. Nevertheless, such a usage pattern might be seen
as a reason to add the indirect bit. But is it enough?
Were there any other usage patterns? What happened to them when the
indirect bit went out of fashion?
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
- anton
Some of the indirection machines had indirection-bit located in the
container at the address generated, others had the indirection in
the address calculation. In the case of the PDP-10 there was a time-
out counter and there were applications that worked fine up to a
particular size, and then simply failed when the indirection watch
dog counter kept "going off".
Two things: 1) the indirect bit is insufficient, 2) optimizing compilers
got to the point they were better at dereferencing linked lists than
the indirection machines were. {Reuse and all that rot.}
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
In the machines where the indirection is at the instruction level, this
was simple, in the machines where the indirection was at the target, it
was more difficult.
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this repeats until a word without this bit is found. At least that's how I understand the descriptions of this feature.
The major question I have is why these architectures have this
feature.
I'll hazard a guess that once you've got the indirect bit out in memory,
it's easier to just use the same logic on all memory reads than to only
let it happen once.
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the word
is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found. At least that's how I understand the descriptions of this feature.
The major question I have is why these architectures have this feature.
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
and I
can't recall using it other than as a gimmick on the PDP-10.
Quadibloc wrote:
On Fri, 29 Dec 2023 17:20:43 +0000, Anton Ertl wrote:
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the word >>> is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found. At least that's how I
understand the descriptions of this feature.
The major question I have is why these architectures have this feature.
No doubt this answer has already been given.
The reason these architectures had that feature was because of a feature
they _didn't_ have: an index register.
This is a better explanation than above. Instead of paying the high price needed for index registers, they use main memory as their index registers. {{A lot like building linked lists in FORTRAN 66}}.
On Fri, 29 Dec 2023 17:20:43 +0000, Anton Ertl wrote:
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the word
is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found. At least that's how I
understand the descriptions of this feature.
The major question I have is why these architectures have this feature.
No doubt this answer has already been given.
The reason these architectures had that feature was because of a feature
they _didn't_ have: an index register.
So in order to access arrays and stuff like that, instead of doing surgery
on the short address inside an instruction, you can simply store a full address in a word somewhere that points anywhere you would like.
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
Let's assume we do have an architecture that supports multi-level indirection. So an instruction word looks like this:
(i)(x)(opcode)(p)(address)
and an address constant looks like this:
(i)(x)(address)
So in an address constant (some architectures that had index registers
kept indirection) you could specify indexing too, but now the address was longer by the length of the opcode field.
If the address inside an instruction is too short to handle all of memory (i.e. the word length is less than 24 bits) then you need a "page" bit in
the instruction: 0 means page zero, shared by the whole program, 1 means
the current page - the one the instruction is on.
Let's now say the instruction is a _store_ instruction. Then what? Well,
if the indirect bit is set, it acts like a *load* instruction, to fetch and load the effective address. It only stores at the point where indirection ends - where the address is now of the actual location to do the storing
in, rather than the location of the effective address, which must be read, not written.
John Savard
According to Joe Pfeiffer <pfeiffer@cs.nmsu.edu>:
I'll hazard a guess that once you've got the indirect bit out in memory, >>it's easier to just use the same logic on all memory reads than to only
let it happen once.
That's not how indirect addressing worked.
There was always a bit in the instruction to say to do indirection.
On Fri, 29 Dec 2023 17:20:43 +0000, Anton Ertl wrote:
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the word
is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found. At least that's how I
understand the descriptions of this feature.
The major question I have is why these architectures have this feature.
No doubt this answer has already been given.
The reason these architectures had that feature was because of a feature
they _didn't_ have: an index register.
On 12/29/23 2:36 PM, John Levine wrote:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:[snip]
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found.
[snip]Were there any other usage patterns? What happened to them when the
indirect bit went out of fashion?
As you suggested, a lot of uses boiled down to providing a fixed
address for something that can move, so instructions could indirect
through that fixed address without having to load it into a register.
Paged virtual memory as commonly implemented introduces one level
of indirection at page (rather than word) granularity.
Virtualization systems using nested page tables introduce a second
direction.
Hierarchical/multi-level page tables have multiple layers of
indirection where instead of a page table base pointer pointing to
a complete page table it points to a typically-page-sized array of
address and metadata entries where each entry points to a similar
array eventually reaching the PTE.
Even with page table caching (and workloads that play well with
this kind of virtual memory), this is not free but it can be
"cheap enough". Using large pages for virtual-physical to physical translation can help a lot. Presumably having an OS bias placement
of its translation table pages into large quasi-pages would help
caching for VPA-to-PA, i.e., many VPAs used by the OS for paging
would be in the same large page (e.g., 2MiB for x86).
(Andy Glew had suggested using larger pages for intermediate nodes
rather than limiting such to the last node in a hierarchical page
table.
This has the same level-reducing effect of huge pages that short-circuit the translation indirection at the end but allows
eviction and permission control at base-page size, with the
consequent larger number of PTEs active if there is spatial
locality at huge page granularity. Such merely assumes that
locality potentially exists at the intermediate nodes rather than
exclusively at the last node. Interestingly, with such a page
table design one might consider having rather small pages; e.g., a
perhaps insane 64-byte base page size (at least for the tables)
would only provide 3 bits per level but each level could be
flattened to provide 6, 9, 12, etc. bits. Such extreme flexibility
may well not make sense, but it seems interesting to me.)
For most purposes, index registers do indirection better, and now that
everything has a lot of registers, you can use some of them for the
fixed->movable stuff like the GOT in Unix/linux shared libraries.
For x86-64 some of the segments can have non-zero bases, so these
provide an additional index register ("indirection").
MitchAlsup <mitchalsup@aol.com> schrieb:
Quadibloc wrote:
On Fri, 29 Dec 2023 17:20:43 +0000, Anton Ertl wrote:
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the word >>>> is set, the CPU uses that word as the address to access, and this
repeats until a word without this bit is found. At least that's how I >>>> understand the descriptions of this feature.
The major question I have is why these architectures have this feature.
No doubt this answer has already been given.
The reason these architectures had that feature was because of a feature >>> they _didn't_ have: an index register.
This is a better explanation than above. Instead of paying the high price
needed for index registers, they use main memory as their index registers. >> {{A lot like building linked lists in FORTRAN 66}}.
The PDP-10 had both a recursive indirect bit and index registers (aka
memory locations 1 to 15), if I remember the manuals correctly
(I did a bit of reading, but I've never even come close to one of
these machines).
The PDP-10 had both a recursive indirect bit and index registers (aka
memory locations 1 to 15), if I remember the manuals correctly
(I did a bit of reading, but I've never even come close to one of
these machines).
According to Thomas Koenig <tkoenig@netcologne.de>:
The PDP-10 had both a recursive indirect bit and index registers (aka >>memory locations 1 to 15), if I remember the manuals correctly
(I did a bit of reading, but I've never even come close to one of
these machines).
Yup. Each instruction had an 18 bit address, a four bit index register, and an indirect bit.
It took the address, and added the contents of the right half of the index register if non-zero.
If the indirect bit was off, that was the operand address. If the indirect bit was set, it
fetched the word at that location and did the whole thing over again, including the indexing.
You could in principle create extremely complicated address chanis but
it was so confusing that nobody did.
John Levine <johnl@taugh.com> wrote:
: More importantly, index registers are a lot faster than indirect
: addressing and at least since the IBM 801, we have good algorithms to
: do register scheduling.
Once upon a time saving an instruction was a big deal; the 801, and
RISC in general, was possible because memory got much cheaper.
Using index registers costs an extra instrucion for loading the index register.
Index registers were a scarce resource too (except for the Atlas) so
keeping all your pointers in index registers wasn't a good option
either.
sarr`
Some (many?) architectures of the 1960s (earlier? later?) have the
feature that, when loading from an address, if a certain bit in the
word is set, the CPU uses that word as the address to access, and this repeats until a word without this bit is found. At least that's how I understand the descriptions of this feature.
The major question I have is why these architectures have this
feature.
The only use I can come up with for the arbitrarily repeated
indirection is the implementation of logic variables in Prolog.
However, Prolog was first implemented in 1970, and it did not become a
big thing until the 1980s (if then), so I doubt that this feature was implemented for Prolog.
A use for a single indirection is the implementation of the memory
management in the original MacOS: Each dynamically allocated memory
block was referenced only from a single place (its handle), so that
the block could be easily relocated. Only the address of the handle
was freely passed around, and accessing the block then always required
double indirection. MacOS was implemented on the 68000, which did not
have the indirect bit; this demonstrates that the indirect bit is not necessary for that. Nevertheless, such a usage pattern might be seen
as a reason to add the indirect bit. But is it enough?
Were there any other usage patterns? What happened to them when the
indirect bit went out of fashion?
One other question is how the indirect bit works with stores. How do
you change the first word in the chain, the last one, or any word in
between?
- anton
PDP-11 and VAX had multiple address modes with a single level of indirection. >The VAX usage stats from 1984 show about 3% use on SPEC.
DG Nova had infinite indirection - if the Indirect bits was set in the >instruction then in the address register if the msb of the address was zero >then it was the address of the 16-bit data, if the msb of the address was 1 >then it was the address of another address, looping until msb = 0.
I don't know how DG used it but, just guessing, because Nova only had
4 registers might be to create a kind of virtual register set in memory.
According to EricP <ThatWouldBeTelling@thevillage.com>:
PDP-11 and VAX had multiple address modes with a single level of indirection. >>The VAX usage stats from 1984 show about 3% use on SPEC.
The main place the PDP-11 used indirect addressing was in @(PC)+ which
was the idiom for absolute addressing. It fetched the next word in the instruction stream as an immediate via (PC)+ and then used it as an
address via indirection. The assembler let you write @#123 to geerate
that address mode and put the 123 in line.
It was also useful for threaded code, where you had a register,
typically R4, pointing at a list of routine addresses and dispatched
with JMP @(R4)+
If you were feeling clever you could do this coroutine switch JSR PC,@(SP)+
That popped the top word off the stack, then pushed the current PC, then jumped
to the address it had popped.
DG Nova had infinite indirection - if the Indirect bits was set in the >>instruction then in the address register if the msb of the address was zero >>then it was the address of the 16-bit data, if the msb of the address was 1 >>then it was the address of another address, looping until msb = 0.
I don't know how DG used it but, just guessing, because Nova only had
4 registers might be to create a kind of virtual register set in memory.
My guess is that it was cheap to implement and let them say look, here
is a cool thing that we do and DEC doesn't. I would be surprised if
there were many long indirect chains.
The [Burroughs] system ran mostly COBOL code (with some BPL;
assemblers weren't generally provided to customers).
On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:
Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
VAX and at 6× the frequency for a 4× improvement in performance.
Mmm, maybe you got the last two multipliers the wrong way round?
... but I've never even come close to one of these
machines).
Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
VAX and at 6× the frequency for a 4× improvement in performance.
On Fri, 29 Dec 2023 19:04:56 GMT, Scott Lurndal wrote:
The [Burroughs] system ran mostly COBOL code (with some BPL;
assemblers weren't generally provided to customers).
For an interesting reason: privilege protection was enforced in software,
not hardware.
On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:
Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
VAX and at 6× the frequency for a 4× improvement in performance.
Mmm, maybe you got the last two multipliers the wrong way round?
On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:
Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
VAX and at 6× the frequency for a 4× improvement in performance.
Mmm, maybe you got the last two multipliers the wrong way round?
VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
machine and advertised it as such.
When they finally did and found it was 0.5 MIPS they just changed to
calling that "1 VUP" or "VAX-780 Units of Processing".
It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
machine and advertised it as such.
No, they knew how fast it was. It was about as fast as an IBM 370/158
which IBM rated at 1 MIPS.
A Vax instruction could do a lot more than
a 370 instruction so it wasn't implausible that the performance was
similar even though the instruction rate was about half.
When they finally did and found it was 0.5 MIPS they just changed to
calling that "1 VUP" or "VAX-780 Units of Processing".
Yeah, they got grief for the MIPS stuff.
John Levine wrote:
It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
machine and advertised it as such.
No, they knew how fast it was. It was about as fast as an IBM 370/158
which IBM rated at 1 MIPS.
So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.
A Vax instruction could do a lot more than
a 370 instruction so it wasn't implausible that the performance was
similar even though the instruction rate was about half.
And they define 1 VUP = 1 TOUP
According to EricP <ThatWouldBeTelling@thevillage.com>:
John Levine wrote:
It appears that EricP <ThatWouldBeTelling@thevillage.com> said:So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.
VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction >>>> giving 0.5 MIPS. When it first came out they thought it was a 1 MIPSNo, they knew how fast it was. It was about as fast as an IBM 370/158
machine and advertised it as such.
which IBM rated at 1 MIPS.
If you want. IBM mainframe MIPS was a well understood performance
measure at the time. In the mid 1970s, there were a few IBM clones
like Amdahl, but the other mainframe makers were already sinking into obscurity. I can't think of anyone else making a 32 bit byte
addressable mainframe at the time that wasn't an IBM clone. I suppose
there were the Interdata machines but they were minis and sold mostly
for embedded realtime.
A Vax instruction could do a lot more thanAnd they define 1 VUP = 1 TOUP
a 370 instruction so it wasn't implausible that the performance was
similar even though the instruction rate was about half.
Yes, but a TOUP really was an IBM MIPS.
If you want. IBM mainframe MIPS was a well understood performanceNo, they knew how fast it was. It was about as fast as an IBM 370/158 >>>> which IBM rated at 1 MIPS.So those were TOUPS or Three-seventy One-fifty-eight Units of Performance. >>
measure at the time. In the mid 1970s, there were a few IBM clones
like Amdahl, but the other mainframe makers were already sinking into
obscurity. I can't think of anyone else making a 32 bit byte
addressable mainframe at the time that wasn't an IBM clone. I suppose
there were the Interdata machines but they were minis and sold mostly
for embedded realtime.
A Vax instruction could do a lot more thanAnd they define 1 VUP = 1 TOUP
a 370 instruction so it wasn't implausible that the performance was
similar even though the instruction rate was about half.
Yes, but a TOUP really was an IBM MIPS.
Ok, but VAX-780 really was measured by DEC at 0.5 MIPS.
So either the assumption that a VUP = TOUP was wrong
or the assumption that a TOUP = MIPS was.
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Thomas Koenig wrote:
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)
I was thinking the same thing. VAX address modes like auto-increment
would be equivalent to 2 instructions for each operand and likely used
in benchmarks.
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)
MOVC3 and MOVC5, perhaps?
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)
ADDF3 B,C,A
The VAX may not be faster, but that's one instruction rather than 3.
On Wed, 17 Jan 2024 23:56:24 GMT, Scott Lurndal wrote:
MOVC3 and MOVC5, perhaps?
Interruptible instructions ... wot fun ...
On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:
ADDF3 B,C,A
The VAX may not be faster, but that's one instruction rather than 3.
If those were register operands, that instruction would be 4 bytes.
I think worst case, each operand could have an index register and a 4-byte offset (in addition to the operand specifier byte), for a maximum
instruction length of 19 bytes.
So, saying “just one instruction” may not sound as good as you think.
Here’s an old example, from the VMS kernel itself. This instruction
PUSHR #^M<R0,R1,R2,R3,R4,R5>
pushes the first 6 registers onto the stack, and occupies just 2 bytes. Whereas this sequence
PUSHL R5
PUSHL R4
PUSHL R3
PUSHL R2
PUSHL R1
PUSHL R0
does the equivalent thing, but takes up 2 × 6 = 12 bytes.
Guess which is faster?
It appears that Thomas Koenig <tkoenig@netcologne.de> said:
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as muchWhy the big difference? Were fancy addressing modes really used so
work as half a million VAX instructions.
much? Or did the code for the VAX mostly run POLY instructions? :-)
I don't think anyone used the fancy addressing modes or complex
instructions much. But here's an example. Let's say A, B, and C are
floats in addressable memory and you want to do A = B + C
370 code
LE R0,B
AE R0,C
STE R0,A
VAX code
ADDF3 B,C,A
The VAX may not be faster, but that's one instruction rather than 3.
Or that old Fortran favorite I = I + 1
370 code
L R1,I
LA R2,1
AR R1,R2
ST R1,I
VAX code
INCL I
or if you have a lousy optimizer
ADDL2 #1,I
or if you have a really lousy optimizer
ADDL3 #1,I,I
It's still one instruction rather than four.
In 370 code you often also needed extra instructions to make data
addressable since it had no direct addressing and address offsets in instructions were only 12 bits.
The MIPS R2000 with 32 registers launched in 1986 at 8.3, 12.5 and 15 MHz.
It supposedly could sustain 1 reg-reg ALU operation per clock.
On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:
ADDF3 B,C,A
The VAX may not be faster, but that's one instruction rather than 3.
If those were register operands, that instruction would be 4 bytes.
I think worst case, each operand could have an index register and a 4-byte >offset (in addition to the operand specifier byte), for a maximum
instruction length of 19 bytes.
So, saying “just one instruction” may not sound as good as you think.
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions.
Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)
Thomas Koenig <tkoenig@netcologne.de> writes:
John Levine <johnl@taugh.com> schrieb:
As I think I said above. a million IBM instructions did about as muchWhy the big difference? Were fancy addressing modes really used so
work as half a million VAX instructions.
much? Or did the code for the VAX mostly run POLY instructions? :-)
It's interesting that these are the features you are thinking of,
especially because the IBM 801 research and the RISC research showed
that fancy addressing modes are rarely used. Table 4 of <https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf> shows that addressing modes that the S/360 or even MIPS does not
support are quite rare:
%
Auto-inc. (R)+ 2.1
Disp. Deferred @D(R) 2.7
Absolute @(PC) 0.6
Auto-inc.def. @(R)+ 0.3
Auto-dec. -(R) 0.9
for a total of 6.6% of the operand specifiers; there are about 1.5
operand specifiers per instruction (Table 3), so that's ~0.1 operand specifier with a fancy addressing mode per instruction.
Back to why S/360 has more instructions than VAX, John Levine gave a
good answer.
One aspect (partially addressed by John Levine, but not discussed
explicitly) is that the VAX is a three-address machine, while S/360 is
a two-address machine, so the S/360 occasionally needs reg-reg moves
where VAX does not. Plus, S/360 usually requires one of its two
operands to be a register, so in some cases an additional load is
necessary on the S/360 that is not needed on the VAX.
Among the complex VAX instructions CALL/RET and multi-register push
and pop constiture 3.22% of the instructions according to Table 1 of <https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
I expect that these correspond to multiple instructions on the S/360.
- anton
support are quite rare:
%
Auto-inc. (R)+ 2.1
Disp. Deferred @D(R) 2.7
Absolute @(PC) 0.6
Auto-inc.def. @(R)+ 0.3
Auto-dec. -(R) 0.9
Among the complex VAX instructions CALL/RET and multi-register push
and pop constiture 3.22% of the instructions according to Table 1 of ><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
I expect that these correspond to multiple instructions on the S/360.
[MIPS] could do at most one instruction per clock, and it certainly
needed to branch at some point, so no sustained 1/clock ALU
instructions.
The 370 had sort of a split personality, a shotgun marriage of a
register scientific machine and a memory-to-memory commercial machine.
do i = 1, N
A(i) = A(i) + B(i)
end do
ADDD (rB)+, (rA)+
On Thu, 18 Jan 2024 19:08:47 -0000 (UTC), John Levine wrote:
The 370 had sort of a split personality, a shotgun marriage of a
register scientific machine and a memory-to-memory commercial machine.
That pins things down quite narrowly as to when it came into being,
doesn’t it? Up to about that point, “scientific” and “business” computing
were considered to be separate worlds, needing their own hardware and >software, and never the twain shall meet.
On Thu, 18 Jan 2024 09:19:44 -0500, EricP wrote:
do i = 1, N
A(i) = A(i) + B(i)
end do
ADDD (rB)+, (rA)+
... set up rA, rB, rI ...
BRB $9000
$1000:
ADDD (rB)+, (rA)+
$9000:
SOBGEQ rI, $1000
Why use SOBGEQ with the branch intead of SOBGTR? So that this way, if N =
0, the loop body never executes at all.
On Thu, 18 Jan 2024 09:19:44 -0500, EricP wrote:
do i = 1, N
A(i) = A(i) + B(i)
end do
ADDD (rB)+, (rA)+
... set up rA, rB, rI ...
BRB $9000
$1000:
ADDD (rB)+, (rA)+
$9000:
SOBGEQ rI, $1000
Why use SOBGEQ with the branch intead of SOBGTR? So that this way, if N =
0, the loop body never executes at all.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf> >>shows that addressing modes that the S/360 or even MIPS does not
support are quite rare:
%
Auto-inc. (R)+ 2.1
Disp. Deferred @D(R) 2.7
Absolute @(PC) 0.6
Auto-inc.def. @(R)+ 0.3
Auto-dec. -(R) 0.9
That's not entirely fair. The VAX has an immediate address mode that
could encode constant values from 0 to 63. Both papers said it was
about 15% so it was definitely a success. The 370 had sort of a split >personality, a shotgun marriage of a register scientific machine
and a memory-to-memory commercial machine. There were a bunch of >instructions with immediate operands but they all were a one byte
immediate and a memory location. Hence the extra LA instructions to
get immediates into registers.
Among the complex VAX instructions CALL/RET and multi-register push
and pop constiture 3.22% of the instructions according to Table 1 of >><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf> >>I expect that these correspond to multiple instructions on the S/360.
The VAX had an all singing and dancing CALLS/RET that saved registers
and set up a stack frame. and a simple JSB/RSB that just pushed the
return address and jumped. CALLS was extremely slow and did far
more than was usually needed so for the most part it was only used
for inter-module calls that had to use the official calling sequence,
and JSB for everything else.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:
ADDF3 B,C,A
The VAX may not be faster, but that's one instruction rather than
3.
If those were register operands, that instruction would be 4 bytes.
I think worst case, each operand could have an index register and a
4-byte offset (in addition to the operand specifier byte), for a
maximum instruction length of 19 bytes.
So, saying “just one instructionâ€_ may not sound as good as you >think.
I wasn't saying they were always better, just pointing out that there
were straightforward reasons that 500K VAX instructions could do the
same work as 1M 370 instructions.
Considering that the 370 is still alive and the VAX died decades ago,
it should be evident that instruction count isn't a very useful
metric across architectures.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Thu, 18 Jan 2024 19:08:47 -0000 (UTC), John Levine wrote:
The 370 had sort of a split personality, a shotgun marriage of a
register scientific machine and a memory-to-memory commercial
machine.
That pins things down quite narrowly as to when it came into being, >doesn’t it? Up to about that point, “scientificâ€_ and >“businessâ€_ computing were considered to be separate worlds, >needing their own hardware and software, and never the twain shall
meet.
Yes, the whole point of S/360 was to produce a unified architecture
that IBM could sell to all of their customers.
It may have been a shotgun marriage, but it's been a very long
lasting one.
You can still run most S/360 application code unmodified on the
latest zSeries.
So this advantage of the VAX over S/360 was not a "fancy" addressing
mode, but the immediate addressing mode that S/360 does not have, but
that all RISCs have, even MIPS, Alpha and RISC-V (except that these >architectures define addi/addiu as separate instructions). VAX has
"short literal", as you explain (15.8% of the operands) as well as >"immediate" (2.4% of the operands). With 1.5 operands per
instruction, that alone is a factor 1.27 more instructions for S/360
than for VAX.
That probably depends on the compiler. Table 2 of ><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf> >lists 4.5% "subroutine call and return", and 2.4% "procedure call and >return"; I assume the latter is the all-singing all-dancing CALL and
RET instruction; the missing 0.82% to the 3.22% mentioned in Table 1
is probably the multi-register push and pop instructions.
Being younger observer from the outside, my impression is that in the
1st World people stopped using S/360 descendents for "heavy" scientific >calculations around 1980. In other parts of the World it lasted few
years longer, but still no longer than 1990.
S/360 permanently reinvents itself. VAX could have done the same, but >voluntarily refused.
It may have been a shotgun marriage, but it's been a very long
lasting one.
Was it?
Being younger observer from the outside, my impression is that in the
1st World people stopped using S/360 descendents for "heavy" scientific >calculations around 1980. ...
Being younger observer from the outside, my impression is that in
the 1st world people stopped using S/360 descendents for "heavy"
scientific calculations around 1980.
Use of IBM manframes for CAD continued well into 90s and may be
even into this century, but CAD is not what people called
"scientific computing" back when S/360 was conceived.
Voluntarily? The VAX 9000 project cost DEC billions. Ok, one can
imagine an alternative history where DEC has decided to avoid
switching to MIPS and Alpha, and where they would have followed up
the NVAX (which seems to be pipelined, but not superscalar, i.e., like
the 486) with eventually an OoO implementation, and from then on might
have had an easier time competing with RISCs.
In article <20240119164019.0000374e@yahoo.com>, already5chosen@yahoo.com >(Michael S) wrote:
Being younger observer from the outside, my impression is that in
the 1st world people stopped using S/360 descendents for "heavy"
scientific calculations around 1980.
Yup. VAXes and other superminis got you a lot more CPU per dollar.
Use of IBM manframes for CAD continued well into 90s and may be
even into this century, but CAD is not what people called
"scientific computing" back when S/360 was conceived.
Some aspects of it are, but many are not. CAD has very uneven processor >usage: vast demands for brief periods when regenerating views or models,
then very little while the designer thinks and adds to the model. Running >this on a time-shared machine is frustrating, because when a few
designers need a lot of CPU at the same time, it gets very slow.
Individual machines keep the designers happier.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
So this advantage of the VAX over S/360 was not a "fancy" addressing
mode, but the immediate addressing mode that S/360 does not have, but
that all RISCs have, even MIPS, Alpha and RISC-V (except that these
architectures define addi/addiu as separate instructions). VAX has
"short literal", as you explain (15.8% of the operands) as well as
"immediate" (2.4% of the operands). With 1.5 operands per
instruction, that alone is a factor 1.27 more instructions for S/360
than for VAX.
Looks that way. IBM apparently noticed it too since S/390 added 16 bit immediate load, compare, add, subtract, and multiply, and zSeries
added immediate everything, such as add immediate to memory.
That probably depends on the compiler. Table 2 of
<https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf> >> lists 4.5% "subroutine call and return", and 2.4% "procedure call and
return"; I assume the latter is the all-singing all-dancing CALL and
RET instruction; the missing 0.82% to the 3.22% mentioned in Table 1
is probably the multi-register push and pop instructions.
Sounds right. I'm surprised the procedure call numbers were so high.
Considering that the 370 is still alive and the VAX died decades ago,
it should be evident that instruction count isn't a very useful metric
across architectures.
The point of a mainframe is that it has a balance between CPU and I/O.
Mainframes are also designed to be very reliable and maintainable.
For single precision the 780 is slightly faster for "coded BLAS"
and the 158 is about 50% faster for compiled code.
On Fri, 19 Jan 2024 18:28:18 -0000 (UTC), John Levine wrote:
The point of a mainframe is that it has a balance between CPU and I/O.
The point of a mainframe was that the CPU was expensive. So a lot of
effort went into complex I/O controllers that could perform chains of >multiple transfers before having to come back to the CPU to ask for more >work.
Such an architecture tends to prioritize high throughput over low latency.
Which made it unsuitable for this newfangled “interactive timesharing” >that began to be popular with the new hardware and software coming from >companies like DEC, DG etc.
In article <2024Jan19.174330@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Voluntarily? The VAX 9000 project cost DEC billions. Ok, one can
imagine an alternative history where DEC has decided to avoid
switching to MIPS and Alpha, and where they would have followed up
the NVAX (which seems to be pipelined, but not superscalar, i.e., like
the 486) with eventually an OoO implementation, and from then on might
have had an easier time competing with RISCs.
The timeline doesn't work. DEC decided to adopt MIPS in 1989, because
they were loosing market share worryingly quickly. NVAX was released in
1991, and they'd have had real trouble developing it without the cash
from MIPS-based systems.
That is less
obvious now, but that's because of the huge amounts of money that have
gone into x86 development over the last thirty years. DEC's market for
VAX systems was much smaller than the market for x86 in 1995-2010.
jgd@cix.co.uk (John Dallman) writes:
The timeline doesn't work. DEC decided to adopt MIPS in 1989,
because they were loosing market share worryingly quickly.
NVAX was released in 1991, and they'd have had real trouble
developing it without the cash from MIPS-based systems.
I forgot that in this alternative reality DEC would have killed the
VAX 9000 project early, leaving them lots of cash for developping
NVAX. Still, it could easily have been that they would have lost
customers to the RISC competition until they finally managed to do
the OoO-VAX.
For developing an OoO-VAX the relevant time is 1985-1995 (HPS wrote
their papers on OoO (with VAX as example) starting in 1985, the
Pentium Pro appeared in 1995). Of course, for OoO-VAXes to succeed
in the market, the relevant timespan was 1995-2005. Intel dropped
the 64-bit IA-32 successor ball and AMD picked it up with the 2003
releases of Opteron and Athlon64.
Would they have gotten those customers back, or would they have lost
to IA-32/AMD64 anyway? Probably the latter, unless they found a
business model that allowed them to milk the customer base that was
tied to VAX while at the same time being cheap enough to compete
with Intel.
They tried to go for that on the Alpha: they used firmware for
market segmentation between VMS/Digital OSF/1 on the one hand and Linux/Windows on the other; and they also offered some relatively
cheap boards, e.g. with the 21164PC, but those were probably too
limited to be successful.
VAX would have been extended to 64 bits some times in the early
1990s in the alternative timeline, and DEC would have been tempted
to use the 64-bit extension for market segmentation, which again
could have resulted into DEC painting itself into a niche.
In article <2024Jan20.101000@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:...
For developing an OoO-VAX the relevant time is 1985-1995 (HPS wrote
their papers on OoO (with VAX as example) starting in 1985, the
Pentium Pro appeared in 1995). Of course, for OoO-VAXes to succeed
in the market, the relevant timespan was 1995-2005. Intel dropped
the 64-bit IA-32 successor ball and AMD picked it up with the 2003
releases of Opteron and Athlon64.
This requires DEC to take notice of those papers and start developing OoO >quite quickly.
If DEC go OoO and build an OoO Micro-VAX CPU by about 1988, they can get >somewhere. The MicroVAX 78032 of 1985 was 125K transistors; the 80386 was >275K transistors the same year, the 40486 was 1.2M transistors in 1989,
so the transistor budget could be there.
Yup. Really, you have to get the traditional DEC management to all retire >before 1990, and the new management need to be brave /and/ lucky.
Yup. Really, you have to get the traditional DEC management to all retire >before 1990, and the new management need to be brave /and/ lucky.
You story about your experiences with DEC remind me of one statement I
once read: DEC buy X, and the result is DEC. Compaq buys DEC, and the
result is DEC (as in, the DEC attitude won over the Compaq attitude).
- anton
In article <2024Jan20.101000@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
... Dave Cutler probably doesn't move to Microsoft, and then Windows NT doesn't happen, at least not in the same way.
Being younger observer from the outside, my impression is that in the
1st World people stopped using S/360 descendents for "heavy" scientific calculations around 1980.
DEC never really understood what business they were in.
EricP <ThatWouldBeTelling@thevillage.com> writes:
For single precision the 780 is slightly faster for "coded BLAS"
and the 158 is about 50% faster for compiled code.
trivia: jan1979, I was asked to run cdc6600 rain benchmark on
(engineering) 4341 (before shipping to customers, the engineering 4341
was clocked about 10% slower than what shipped to customers) for
national lab that was looking at getting 70 for a compute farm (sort
of the leading edge of the coming cluster supercomputing tsunami). I
also ran it on 158-3 and 3031. A 370/158 ran both the 370 microcode
and the integrated channel microcode; a 3031 was two 158 engines, one
with just the 370 microcode and a 2nd with just the integrated
channel microcode.
cdc6600: 35.77secs
158: 45.64secs
3031: 37.03secs
4341: 36.21secs
... 158 integrated channel microcode was using lots of processing
cycles, even when no i/o was going on.
On Sat, 20 Jan 2024 16:25 +0000 (GMT Standard Time), John Dallman
wrote:
In article <2024Jan20.101000@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
... Dave Cutler probably doesn't move to Microsoft, and then
Windows NT doesn't happen, at least not in the same way.
Imagine if it hadn’t been created by a Unix-hater. But then,
Microsoft had already divested themselves of Xenix by then, hadn’t
they? So they probably didn’t have anyone left who understood the
value of Unix.
In article <2024Jan20.101000@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
jgd@cix.co.uk (John Dallman) writes:
The timeline doesn't work. DEC decided to adopt MIPS in 1989,I forgot that in this alternative reality DEC would have killed the
because they were loosing market share worryingly quickly.
NVAX was released in 1991, and they'd have had real trouble
developing it without the cash from MIPS-based systems.
VAX 9000 project early, leaving them lots of cash for developping
NVAX. Still, it could easily have been that they would have lost
customers to the RISC competition until they finally managed to do
the OoO-VAX.
For developing an OoO-VAX the relevant time is 1985-1995 (HPS wrote
their papers on OoO (with VAX as example) starting in 1985, the
Pentium Pro appeared in 1995). Of course, for OoO-VAXes to succeed
in the market, the relevant timespan was 1995-2005. Intel dropped
the 64-bit IA-32 successor ball and AMD picked it up with the 2003
releases of Opteron and Athlon64.
This requires DEC to take notice of those papers and start developing OoO quite quickly. They did not do that historically, and they seem to have
been confident that their way of working would carry on being effective, until RISC demonstrated otherwise. This is the timeframe where IBM gave
up on building mainframes with competitive compute power, and settled for them being capable data-movers.
If DEC go OoO and build an OoO Micro-VAX CPU by about 1988, they can get somewhere. The MicroVAX 78032 of 1985 was 125K transistors; the 80386 was 275K transistors the same year, the 40486 was 1.2M transistors in 1989,
so the transistor budget could be there.
On Fri, 19 Jan 2024 16:17:32 -1000...
Lynn Wheeler <lynn@garlic.com> wrote:
cdc6600: 35.77secs
158: 45.64secs
3031: 37.03secs
4341: 36.21secs
Did I read it right? Brand new mid-range IBM mainframe barely matched
15 y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
Did I read it right? Brand new mid-range IBM mainframe barely matched 15
y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
On Sat, 20 Jan 2024 21:33:11 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 20 Jan 2024 16:25 +0000 (GMT Standard Time), John Dallman
wrote:
In article <2024Jan20.101000@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
... Dave Cutler probably doesn't move to Microsoft, and then Windows
NT doesn't happen, at least not in the same way.
Imagine if it hadn’t been created by a Unix-hater. But then, Microsoft
had already divested themselves of Xenix by then, hadn’t they? So they
probably didn’t have anyone left who understood the value of Unix.
I see nothing wrong in DC being Unix hater.
On Fri, 19 Jan 2024 16:17:32 -1000
Lynn Wheeler <lynn@garlic.com> wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
For single precision the 780 is slightly faster for "coded BLAS"
and the 158 is about 50% faster for compiled code.
trivia: jan1979, I was asked to run cdc6600 rain benchmark on
(engineering) 4341 (before shipping to customers, the engineering 4341
was clocked about 10% slower than what shipped to customers) for
national lab that was looking at getting 70 for a compute farm (sort
of the leading edge of the coming cluster supercomputing tsunami). I
also ran it on 158-3 and 3031. A 370/158 ran both the 370 microcode
and the integrated channel microcode; a 3031 was two 158 engines, one
with just the 370 microcode and a 2nd with just the integrated
channel microcode.
cdc6600: 35.77secs
158: 45.64secs
3031: 37.03secs
4341: 36.21secs
... 158 integrated channel microcode was using lots of processing
cycles, even when no i/o was going on.
Did I read it right? Brand new mid-range IBM mainframe barely matched
15 y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
Michael S wrote:
On Fri, 19 Jan 2024 16:17:32 -1000
Lynn Wheeler <lynn@garlic.com> wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
For single precision the 780 is slightly faster for "coded BLAS"
and the 158 is about 50% faster for compiled code.
trivia: jan1979, I was asked to run cdc6600 rain benchmark on
(engineering) 4341 (before shipping to customers, the engineering 4341
was clocked about 10% slower than what shipped to customers) for
national lab that was looking at getting 70 for a compute farm (sort
of the leading edge of the coming cluster supercomputing tsunami). I
also ran it on 158-3 and 3031. A 370/158 ran both the 370 microcode
and the integrated channel microcode; a 3031 was two 158 engines, one
with just the 370 microcode and a 2nd with just the integrated
channel microcode.
cdc6600: 35.77secs
158: 45.64secs
3031: 37.03secs
4341: 36.21secs
... 158 integrated channel microcode was using lots of processing
cycles, even when no i/o was going on.
Did I read it right? Brand new mid-range IBM mainframe barely matched
15 y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
Target market for 4341 was not scientific computing, either.
On Sun, 21 Jan 2024 15:06:43 +0200, Michael S wrote:
Did I read it right? Brand new mid-range IBM mainframe barely matched 15
y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
A minute’s silence for the hardware legend that was Seymour Cray.
Not sure why they went to IBM with it, maybe DEC would have been a
better choice. Then again, the people at the computer center in
Karlsruhe were very mainframe-oriented...
Did I read it right? Brand new mid-range IBM mainframe barely matched
15 y.o. CDC machine that was 10 years out of production ?
That sounds quite embarrassing.
On Sun, 21 Jan 2024 21:51:56 -0000 (UTC), Thomas Koenig wrote:
Not sure why they went to IBM with it, maybe DEC would have been a
better choice. Then again, the people at the computer center in
Karlsruhe were very mainframe-oriented...
There seemed to be a lot of people like that, who only knew IBM and saw
the whole world through IBM lenses. ...
IBM has a big development lab in Boeblingen which is about an hour from Karlsruhe.
On Mon, 22 Jan 2024 02:46:05 -0000 (UTC), John Levine wrote:
IBM has a big development lab in Boeblingen which is about an hour from
Karlsruhe.
At one time, IBM were the world’s biggest holder of patents. Their researchers came up with many clever ideas. But my impression was, very
few of those ideas actually made it into their products.
According to EricP <ThatWouldBeTelling@thevillage.com>:
DG Nova had infinite indirection - if the Indirect bits was set in the
instruction then in the address register if the msb of the address was zero >> then it was the address of the 16-bit data, if the msb of the address was 1 >> then it was the address of another address, looping until msb = 0.
I don't know how DG used it but, just guessing, because Nova only had
4 registers might be to create a kind of virtual register set in memory.
My guess is that it was cheap to implement and let them say look, here
is a cool thing that we do and DEC doesn't. I would be surprised if
there were many long indirect chains.
On Mon, 22 Jan 2024 02:46:05 -0000 (UTC), John Levine wrote:
IBM has a big development lab in Boeblingen which is about an hour from
Karlsruhe.
At one time, IBM were the world’s biggest holder of patents. Their >researchers came up with many clever ideas. But my impression was, very
few of those ideas actually made it into their products.
My guess is that it was cheap to implement and let them say look, hereAs has been mentioned elsewhere recently DEC did exactly this on the PDP-10.
is a cool thing that we do and DEC doesn't. I would be surprised if
there were many long indirect chains.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Mon, 22 Jan 2024 02:46:05 -0000 (UTC), John Levine wrote:
IBM has a big development lab in Boeblingen which is about an hour from
Karlsruhe.
At one time, IBM were the world’s biggest holder of patents. Their >>researchers came up with many clever ideas. But my impression was, very
few of those ideas actually made it into their products.
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
It was more complicated than that on the PDP-6/10. At each stage it not
only did indirection, it could also add in an index register. I can sort
of imagine how one might use all that for dynamically allocated array
rows but I never saw more than two levels in practice and never saw
indexing in indirect words.
On Sun, 21 Jan 2024 21:51:56 -0000 (UTC), Thomas Koenig wrote:
Not sure why they went to IBM with it, maybe DEC would have been a
better choice. Then again, the people at the computer center in
Karlsruhe were very mainframe-oriented...
There seemed to be a lot of people like that, who only knew IBM and saw
the whole world through IBM lenses. To the rest of us, IBM’s way of doing things just seemed overcomplicated, unwieldy, inflexible ... and
expensive.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Mon, 22 Jan 2024 02:46:05 -0000 (UTC), John Levine wrote:
IBM has a big development lab in Boeblingen which is about an hour from
Karlsruhe.
At one time, IBM were the world’s biggest holder of patents. Their >>researchers came up with many clever ideas. But my impression was, very
few of those ideas actually made it into their products.
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
See, you cannot sue me for patent infringement, I am only doing what MY >patent on that mater allows.
John Levine wrote:
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
On Mon, 22 Jan 2024 02:46:05 -0000 (UTC), John Levine wrote:
IBM has a big development lab in Boeblingen which is about an hour from >>>> Karlsruhe.
At one time, IBM were the world’s biggest holder of patents. Their >>>researchers came up with many clever ideas. But my impression was, very >>>few of those ideas actually made it into their products.
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
See, you cannot sue me for patent infringement, I am only doing what MY patent on that mater allows.
According to MitchAlsup1 <mitchalsup@aol.com>:
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
See, you cannot sue me for patent infringement, I am only doing what MY >>patent on that mater allows.
It's more than that. If someone threatens IBM with a patent suit, IBM's usual response is that they have 100,000 patents in their portfolio, so they're pretty sure that if they look, they will find something that
the other party is doing that looks like one of those patents and
will countersue. Patent suits are very expensive and IBM has
deep pockets.
Big companies often avoid this by cross-licensing, I won't sue you for anything in our pile of patents if you won't sue me for anything in
your pile.
According to Lawrence D'Oliveiro <ldo@nz.invalid>:
At one time, IBM were the world’s biggest holder of patents. Their >>researchers came up with many clever ideas. But my impression was, very
few of those ideas actually made it into their products.
A lot of patents are defensive, you don't necessarily plan to use them
but you don't want anyone else to own them.
A patent gives its owner the right to keep others from using the
invention as described in the claims. It does _not_ give the owner any rights to use the invention that he would not have otherwise.
And more than that, you don’t actually need to prove your idea works
before you can get a patent on it. I think the legal term is “reduce to >practice”, which basically means “write up a plausible-sounding >description of how it *might* work”.
This is why there was nothing to stop people patenting an endless variety
of ideas for perpetual-motion machines; it needed explicit rules brought
in specifically to prohibit them.
On Mon, 22 Jan 2024 20:32:10 -0000 (UTC), Thomas Koenig wrote:
A patent gives its owner the right to keep others from using the
invention as described in the claims. It does _not_ give the owner any
rights to use the invention that he would not have otherwise.
And more than that, you don’t actually need to prove your idea works
before you can get a patent on it. I think the legal term is “reduce to practice”, which basically means “write up a plausible-sounding description of how it *might* work”.
This is why there was nothing to stop people patenting an endless variety
of ideas for perpetual-motion machines; it needed explicit rules brought
in specifically to prohibit them.
Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
On Mon, 22 Jan 2024 20:32:10 -0000 (UTC), Thomas Koenig wrote:
A patent gives its owner the right to keep others from using the
invention as described in the claims. It does _not_ give the owner any
rights to use the invention that he would not have otherwise.
And more than that, you don’t actually need to prove your idea works
before you can get a patent on it. I think the legal term is “reduce to
practice”, which basically means “write up a plausible-sounding
description of how it *might* work”.
§ 21 of the German Patent Law states (deepl-assisted translation,
IANAL)
(1) The patent shall be revoked (§ 61) if it is found that
[...]
2. the patent does not disclose the invention so clearly and completely
that a person skilled in the art can carry it out,
To avoid insufficient disclosure, people (including myself, I have to
admit) now put a _lot_ of details into patents, which makes the patents
much longer than previously, and more painful to write and to read.
This is why there was nothing to stop people patenting an endless variety
of ideas for perpetual-motion machines; it needed explicit rules brought
in specifically to prohibit them.
A patent has to be industrially applicable (§1), and (§5)
An invention is considered to be industrially applicable if
its subject matter can be made or used in any industrial field,
including agriculture.
Something that does not work can clearly not be used in an
industrial field.
When multiple patents arrive at the patent office contemporaneously, and
they all describe essentially the same mechanism or algorithm:: they
should ALL be denied as something "obvious to one skilled in the art".
Yet, the opposite happens.
On Tue, 23 Jan 2024 21:13:29 +0000, MitchAlsup1 wrote:
When multiple patents arrive at the patent office contemporaneously, and
they all describe essentially the same mechanism or algorithm:: they
should ALL be denied as something "obvious to one skilled in the art".
Yet, the opposite happens.
Worse than that, if evidence comes to light of “prior art”, that is, use/ disclosure of the patented techniques prior to the patent registration,
that should invalidate the patent. Yet, in the US at least, this turns out
to be very hard.
Case in point: the NewEgg patent, which was just an application of Diffie- Helmann key exchange. Whitfield Diffie himself took the stand to testify
that he had come up with the idea decades before. Yet the jury were unconvinced, and let the patent stand.
Case in point: the NewEgg patent, which was just an application of Diffie- >> Helmann key exchange. Whitfield Diffie himself took the stand to testify
that he had come up with the idea decades before. Yet the jury were
unconvinced, and let the patent stand.
Was this before or after the US followed the rest of the world by
allowing opposition proceedings? Having such a case go straight
to a jury is somewhat problematic...
According to Thomas Koenig <tkoenig@netcologne.de>:
Case in point: the NewEgg patent, which was just an application of Diffie- >>> Helmann key exchange. Whitfield Diffie himself took the stand to testify >>> that he had come up with the idea decades before. Yet the jury were
unconvinced, and let the patent stand.
Was this before or after the US followed the rest of the world by
allowing opposition proceedings? Having such a case go straight
to a jury is somewhat problematic...
It was in 2013. Since 2012 the US has had inter partes review, where
you can have the Patent Trial and Appeal Board review a patent to see
if it's not novel. That case was filed under the old rules, and was in >Marshall TX, a rural corner of Texas with a judge notoriously friendly
to patent trolls.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 69:46:30 |
| Calls: | 6,915 |
| Files: | 12,380 |
| Messages: | 5,431,960 |