|
| Authored by: Anonymous on Wednesday, October 10 2012 @ 12:47 AM EDT |
Note that for anyone that wants to chime in that software written
for x86 won't work on a motorola chip.
But software written for an
x86 will work on a Motorola chip. All you need is to have an instruction
cycle program written in native Motorola machine code that takes x86 machine
code as its input data and from it produces the same output as would the
Motorola chip.
The converse is also true. All modern computer
instruction sets are Turing complete and, barring limitations of finite amount
of memory (and time), are able to simulate each other.[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, October 10 2012 @ 04:43 AM EDT |
Note that for anyone that wants to chime in that software written
for x86 won't work on a motorola chip.
The source code approach
to the portability issue is to have a cross-compiler that accepts one vendor's
assembly language (e.g. x86) and produces object code for a different processor
family (e.g. PPC). The main barrier lies in the different register maps and
status flags. But the problems were (mostly) solved years ago for various
embedded systems.
Another thing that seems to have been forgotten is
the existence of bridge systems. These are machines that can run two (2 !)
different kinds of machine code. In the 1960's IBM had mainframes with
this capability (see link #1). At the start of the 1980's there were CPU
cards for S-100 systems that had both an i8085 (8-bit) and an i8086 (16-bit) on
the same card. Only one would be live but one could use 8-bit tools on the i8085
to develop software for the i8086 and then shutdown and switch over to the i8086
for testing. Later, NEC came up with their V20 (see link #2) which was an
i8088-compatible MPU that could also run i8080 code (reportedly also Z80
code).
Dual machine code systems are commonplace these days thanks to
high-performance video cards (GPU's) and ASIC-style CPU's that integrate one (or
more) x86 or ARM cores with a GPU core (e.g. iPad / iPhone).
"IBM
System/360 - Backward compatibility" (Wikipedia article)
"NEC V20" (Wikipedia
article)
MB94128 [ Reply to This | Parent | # ]
|
|
|
| Authored by: soronlin on Wednesday, October 10 2012 @ 06:46 AM EDT |
I think you have a good theoretical point. However it is abstract and complex
enough that it could never be applied. Lawyers would always argue that their
particular software did have such a limitation. It's a good basis for arguing
for a blanket ban, but not a good test for that ban. (IMHO, IANAL, IANPoIR)[ Reply to This | Parent | # ]
|
|
|
| Authored by: hAckz0r on Wednesday, October 10 2012 @ 10:11 AM EDT |
| I can see from this another statement that can be made with respect to what PoIR
had written.
If a computer only manipulates numbers, and the computer has
no conception of what those numbers actually mean, then by extension the
computer is not producing anything with respect to the "end use" specified in
that statement above. The computer is merely producing numbers or manipulations
that have no real world relationship to the problem at hand, rather it is the
user of the computer that puts "meaning" to those numbers. The user is in effect
interpreting those numbers or patterns and solving the stated problem, not the
computer. The computer is merely an aid in computing those numbers faster than
the user could otherwise.
---
The Investors IP Law: The future health
of a Corporation is measured as the inverse of the number of IP lawsuits they
are currently litigating. [ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Wednesday, October 10 2012 @ 02:46 PM EDT |
> software written for x86 won't work on a motorola chip.
Some here have quoted industry standard practice to use portable
languages, but you said "written -for- x86", and I've seen
too much of that while running motorola chipped hardware.
Use of translators or portable code abstracts the software.
Sufficiently to make it non-patentable? I don't know.
ISTM that software written in Assembler for a particular chipset
might be patentable, while running on that chipset. Translation,
or use of a higher level language would be a transformation.
The transformation itself would be patentable were we talking of
a material substance. Is that the ghost of Diehr I see?
So your question to PolR
> "not limited to any particular art or technology etc,
> to any particular apparatus or machinery,
> or to any particular end use."
fails the FC test on the third point. They see the vulcanized rubber
and they "know" the software has transformed a material substance.
Our mission is to disabuse them of this error.
[ Reply to This | Parent | # ]
|
|
