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

["Fuad Tabba" <fuad@xxxxxxxxxxxxxxxxx>]

Note, I mentioned in my previous email that the sun c compiler doesn't
handle inline assembly (__asm__) all that well if it has parameters. I
should be more specific and note that it doesn't handle *variables* as
parameters. It's fine with constants that it can embed as part of
parsing the macro itself.

Otherwise you'd have to use the compiler's own inline assembly files.

/Fuad


On Thu, Jun 19, 2008 at 10:43 AM, Fuad Tabba <fuad@xxxxxxxxxxxxxxxxx> wrote:
> 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.
>>>
>>>
>>
>