The "!(*this == opc)" is interesting. If you do it that way, it's definitely more programmable for the long term since one change to the equals operator definition will propagate. But, is that way adding two extra operations there? 1 to dereference the this pointer and then another to do the NOT operation? The "==" operator is the more used operator but if for some reason the "!=" operator become popular within gem5 wouldnt it be slightly slower?

I think defining != in terms of == is much preferred for the reasons you said.  The compiler should inline the == definition into != where appropriate, so the performance difference for optimized code should be somewhere between non-existent and negligible, and certainly worthwhile given how much simpler and more robust the code will be.  You should just be able to define it once on the base class too which will simplify things even more.

Be really careful just defining it in the base class. It's not virtual as far as I remember, and generally speaking the subclasses add extra things to check. You could end up using the base class version and not checking everything, but it would frequently be right and could slip by pretty easily. I'm not saying it won't work, just be very careful and verify it's doing exactly what you think it is in all the ISAs one by one.

You're right, it doesn't work to just define it in the base class since the other functions are not virtual.  So forget my comment on that one, you will have to define it in each class where == is defined.  Defining != in terms of == is still the way to go though.