LogTM Bug Discovered

I found two bugs in the slicc files.
One is specific to my SLE implementation and another is for both my SLE and the existing LogTM implementation.

The bug that relates SLE specific implementation is to do with how abort of an transaction is handled by my slicc file. In my current implementation, I divide the abort procedure into two parts. 1) abort the transaction and restrore only the log 2) when hit another store/load, restore register state. That sounds good, right? The devil comes into to play when the first part is done, but before you hit a another load/store, you hit a commit instruction, now you are busted because the register state will not be restored but instead it will be wiped out by the transaction commit and that would lead you an inconsistent state of the world!!!

The other bug that affects both SLE and LogTM is to do with how LogTM specify a Fwd_GETS request. Currently, it only checks if the address requested is in the cache and if so, is it written by a transaction. If not written transactionally, it is a normal get Fwd_GETS. But, there is a trick, if you read it transactionally, you are not catching it. If this address is modified before the transaction started, then TM 1 read it, and TM2 send a GETS request, this request will not generate a Fwd_GETS_X request but a Fwd_GETS request instead.