> goes, sure, this is a great idea, and can be real fast...But I think in
> the future what we want is a CPU that is 'intelligent' and actually morphs
> its machine code dependant on what instructions it will use on a per
> program basis. Although this would take one HELL of an operating system to
> pull off, it _would_ be possible. Think about it... At the assembly level,
> you can count the unique instructions used, and any decent overoptimizing
> compiler could reduce large multiple-cycle instructions into many smaller
> single-cycle instructions, build an assembler header of the instructions
> that are to be used by that program, have the kernel send that header to a
> protected region in on-cpu memory, and have a small instructionset
> tailored to the program being run at the moment, (minimizing lookup time).
> basically it would mean having the hardware adapt to the code, and not the
> code adapt to the hardware. As far as plauseability of this idea, I really
> couldn't say... it seems pretty far-fetched but I think that it would be
> possible if a few decent cpu designers put their heads together...
Sounds interesting...
But how much can you optimize the instructions in microcode (or whatever this
CPU calls its internal control code) over the microcode of a *decent*
processor that does not have this feature? Branch prediction and modern
scheduling on the CPU should already optimize the use of the processor's
functional units as much as possible with the help of compilers.
Another point might be to customize the functional units to perform modified
calculations. But I really can not think of applications that would benefit
from customized functions? -- If the processor's ALU or FPU is not designed to
do an "ADD, MUL" in one cycle, you can not teach it to do so with new
microcode. On the other hand, if it does have such a functional unit, any
CISC or RISC processor will make it available via an opcode.
Any obvious benefits?
Olaf.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:21 EST