> > We could not. Consider just the 8 32-bit-wide legacy x86 registers,
> > excluding the MMX and FPU registers:
> > (AX, BX, CX, DX, BP, SI, DI, SP). 32 bits x 8 = 2^256 independent
> > states to look up in the table, each state having 256 bits of
> > information. 2^264 total bits of information needed. Assume 1 GB
> > dimms (2^30 * 8 bits each = 2^33 bits of info), with a volume of 10
> > cm^3 per DIMM (including a tiny amount of space for air circulation.).
> > Need 34508731733952818937173779311385127262255544860851932776 cubic
> > kilometers of space.
> >
> > Considerably larger than the volume of the earth, although admittedly
> > smaller than the total volume of the universe.
> > --Steven Augart
>
> If this could be done, someone would have done it already.
It's certainly possible to implement most of the functionality of a
very simple processor this way, but applying the idea to an X86
compatible processor was a joke.
What interests me now is whether we could cache the results of certain
opcode strings in a separate memory area.
Say for example, you have a complicated routine that runs in to
hundreds of opcodes, which is being applied to large amounts of data,
word by word. If one calculation doesn't depend on another, you could
cache the results, and then merely fetch them from the results cache
when the input data repeats itself.
I.E. the processor dynamically makes it's own look-up tables.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:21 EST