By: TREZA (no.delete@this.ema.il), August 21, 2013 6:06 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 20, 2013 4:05 pm wrote:
> Ricardo B (ricardo.b.delete@this.xxxxxx.xx) on August 20, 2013 3:27 pm wrote:
> >
> > Incurring the risk of your wrath, I think it would have been a good time to drop
> > BCD, x87, MMX, 3d!now, ah/bh/ch/dh and probably some more stuff like that.
>
> The thing you don't seem to understand is that AMD *couldn't* drop those things.
>
> Why? Because you still need the hardware and logic for them for legacy mode.
> You can't get rid of the high-byte logic, since it's still needed.
>
> So at most, AMD could drop these features from the x86-64 instruction decoding map. But the hardware would
> have to be there anyway, and the instruction decoders would still have to be there. Remember: x86 long more
> is sharing all of that with the legacy mode, and it needed to do that for good reasons (that I outlined).
>
> Now, AMD did that opcode map cleanup for the inc/dec instructions, but there the
> upside was that those took up a lot of opcode space that could be used better
> for other things. The same just wasn't true of random individual instructions.
>
x86 never handled properly the "trap and emulate" method. It would have helped get rid of some odd legacy instructions. For example, crazy MC68881 instructions like the hyperbolic arctangent were dropped when the FPU was integrated into the MC68040 and a software library was provided by Motorola for emulation.
Unless BCD instructions are used somewhere in performance critical code...
> Ricardo B (ricardo.b.delete@this.xxxxxx.xx) on August 20, 2013 3:27 pm wrote:
> >
> > Incurring the risk of your wrath, I think it would have been a good time to drop
> > BCD, x87, MMX, 3d!now, ah/bh/ch/dh and probably some more stuff like that.
>
> The thing you don't seem to understand is that AMD *couldn't* drop those things.
>
> Why? Because you still need the hardware and logic for them for legacy mode.
> You can't get rid of the high-byte logic, since it's still needed.
>
> So at most, AMD could drop these features from the x86-64 instruction decoding map. But the hardware would
> have to be there anyway, and the instruction decoders would still have to be there. Remember: x86 long more
> is sharing all of that with the legacy mode, and it needed to do that for good reasons (that I outlined).
>
> Now, AMD did that opcode map cleanup for the inc/dec instructions, but there the
> upside was that those took up a lot of opcode space that could be used better
> for other things. The same just wasn't true of random individual instructions.
>
x86 never handled properly the "trap and emulate" method. It would have helped get rid of some odd legacy instructions. For example, crazy MC68881 instructions like the hyperbolic arctangent were dropped when the FPU was integrated into the MC68040 and a software library was provided by Motorola for emulation.
Unless BCD instructions are used somewhere in performance critical code...