Re: [Gems-users] LogTM Transactions Hanging (Gems 2.1)

["Fuad Tabba" <fuad@xxxxxxxxxxxxxxxxx>]

Thanks for the binary Jayaram.

deque_TM is working fine with BASE and TIMESTAMP conflict resolution.
So I guess this means that the problem is in my binaries/benchmarks
and not in my simulation environment.

I'm using sun c compiler (5.9) with the flags -xO3 -m32
-xarch=sparcvis among others.

I also had to rewrite some of the __asm__ macros since the sun c
compiler doesn't seem to handle them well if they have parameters (I
did this for the old gems 1.2 as well). This is what I did:-

//-------------------------------------------------
#define NEW_RUBY_MAGIC_CALL(id)                                                \
    do                                                                         \
    {                                                                          \
        asm (".volatile\n sethi " #id ", %g0 \n .nonvolatile \n ");            \
    }                                                                          \
    while (0);

#define BEGIN_CLOSED_TRANSACTION(id)  NEW_RUBY_MAGIC_CALL(1024)
#define COMMIT_CLOSED_TRANSACTION(id) NEW_RUBY_MAGIC_CALL(2048)
#define BEGIN_OPEN_TRANSACTION(id)    NEW_RUBY_MAGIC_CALL(3072)
#define COMMIT_OPEN_TRANSACTION(id)   NEW_RUBY_MAGIC_CALL(4096)

#define SYSTEM_CALL(id)               NEW_RUBY_MAGIC_CALL(5120)
#define ABORT_TRANSACTION(id)         NEW_RUBY_MAGIC_CALL(6144)
//-------------------------------------------------

As for set_transaction_registers and init_transaction_state, I haven't
changed them (or the functions that they call).

To run a transaction; I just call:-
BEGIN_CLOSED_TRANSACTION(0);
// do stuff
COMMIT_CLOSED_TRANSACTION(0);

I don't have any nested transactions or anything like that. I did this
with the old gems (1.2) and it used to work. Maybe some of these
changes don't transfer all that nicely to the new gems?

Thanks again for bearing with me :)

Cheers,
/Fuad


On Thu, Jun 19, 2008 at 10:13 AM, Fuad Tabba <fuad@xxxxxxxxxxxxxxxxx> wrote:
> Thanks Javier and Jayaram.
>
> Now I'm going to ask what might seem obvious; what do I do about it?
> How do I use instruction-cache-access-trace with a line size equal to
> the instruction size, or how do I _not_ use
> instruction-cache-access-trace to begin with?
>
> Also, why am I using instruction-cache-access-trace? All I did was
> install simics and gems by following the documentation on the gems
> website, so how come it's different from what you (I'm assuming) are
> using?
>
> Thanks again.
>
> Cheers,
> /Fuad
>
>
> On Thu, Jun 19, 2008 at 10:08 AM, Jayaram Bobba <bobba@xxxxxxxxxxx> wrote:
>> Thanks Javier for the clarification. I believe that instruction-fetch-mode
>> could influence the correctness of the simulation. Some conflict resolution
>> policies (like Timestamp) require the simulator to see every instruction
>> fetch.
>> Typically, once a transaction is marked as 'to be aborted' by the
>> conflict resolution policy,
>> the simulator generates a trap on the next memory request it receives
>> from SIMICS. Now if
>> the next instruction happens to be COMMIT_TRANSACTION and SIMICS does not
>> report every instruction fetch then the transaction could be incorrectly
>> committed.
>>
>> So if you need to use instruction-cache-access-trace, then you should
>> use it with a line
>> size equal to the instruction size.
>>
>>
>> Javier Merino wrote:
>>> Fuad Tabba wrote:
>>>
>>>>> I am not sure what instruction-cache-access-trace is and how it differs
>>>>> from instruction-fetch-trace. The difference
>>>>> if any could also affect trap handling.
>>>>>
>>>> Not really sure how why it is instruction-cache-access-trace as
>>>> opposed to instruction-fetch-trace. Is there a parameter I could
>>>> change?
>>>>
>>>>
>>>
>>> From the serengeti reference manual:
>>> "If [instruction-fetch-mode is] set to instruction-cache-access-trace,
>>> the memory hierarchy will receive one (and only one) instruction fetch
>>> every time a new cache line is accessed. [...] If set to
>>> instruction-fetch-trace, all instruction fetches will be visible. Note
>>> that on x86 target, instruction-cache-trace-access is not available. On
>>> some other, instruction-fetch-trace is actually
>>> instruction-cache-trace-access with a line size equal to
>>> the instruction size (sparc-v9)."
>>>
>>> Simics warns you that instruction-fetch-mode is using
>>> instruction-cache-access-trace. It is ok, I don't think that's the
>>> source of your problem.
>>>
>>> Regards,
>>> Javier Merino
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Gems-users mailing list
>>> Gems-users@xxxxxxxxxxx
>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>>
>>>
>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>
>>
>