By all means I don't really understand the whole issues surrounding this
but this approach looks better to me as well. It seems more generic and
future proof and at least I can understand the patch series.
But did I say I don't understand all of this? Would be nice to hear from
more people :)
Qais
On 12/04/2014 10:16 AM, Paul Burton wrote:
Nice work David, I like this approach. It's so much simpler than hacking
atop the current dsemul code. I also imagine this could be reused for
emulation of instructions removed in r6, when running pre-r6 userland
binaries on r6 systems.
On Wed, Dec 03, 2014 at 06:21:36PM -0800, David Daney wrote:
On 12/03/2014 05:56 PM, Leonid Yegoshin wrote:
I see only two technical issues here which differs:
1. You believe your GCC experts, I trust HW Architecture manual and
don't trust toolchain people too much ==> we see a different value in
fact that your approach has a subset of emulated ISAs (and it can't, of
course, emulate anything because some custom opcodes are reused).
Yes, I agree that the emulation approach cannot handle some of the cases you
mention (most would have to be the result of hand coded assembly
specifically trying to break it).
I'm not sure I'd agree even with that - ASEs & vendor-specific
instructions could easily be added if necessary.
On Thu, Dec 04, 2014 at 05:56:51PM -0800, Leonid Yehoshin wrote:
2. My approach is ready to use and is used right now, you still have a
framework which passed an initial boot.
Subjective.
Thanks,
Paul
