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

["Cong Wang" <jameswang99@xxxxxxxxx>]

Hi Fuad:
    One possible thing about your problem is that the new version of
GEMS uses a different set of numbers in the magic instructions to
denote to the BEGIN_XACT and END_XACT than the last version we were
playing with. It could be possible that your benchmarks are sending
out out set of numbers with the magic instruction and the new version
of the GEMS doesn't understand. Please check the file
$GEMS/ruby/simics/command.C to verify that the magic instructions are
using the same number to mean BEGIN_XACT and other additional new
instructions as you might have in your benchmarks. I could help more
with an account to login to Uni servers but I don't have anymore. :)

Regards
James Wang

On Thu, Jun 19, 2008 at 1:42 PM, Fuad Tabba <fuad@xxxxxxxxxxxxxxxxx> wrote:
> Sorry again, I realized that I spoke too soon about deque_TM working at all.
> The version I compiled without -DNDEBUG, which I thought was working isn't
> working if I run 3 threads on 4 processors, while the binary Jayaram sent me
> does work under those conditions.
>
> I am using the source code for that microbenchmark that comes with GEMS, and
> I've made the minor changes to transaction.h that I mentioned in my previous
> email, and compiled it as follows:-
>
> -----------------
> ~/transactional/deque$ make clean && make
> rm -f deque_TM deque_Lock   *.o
> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
> -I../common -c -o deque_TM.o deque.c
> "deque.c", line 134: warning: implicit function declaration:
> tm_bind_to_cabinet
> "deque.c", line 135: warning: implicit function declaration:
> Barrier_breaking
> "deque.c", line 136: warning: implicit function declaration:
> set_transaction_registers
> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
> -I../common -c -o transaction.o ../common/transaction.c
> "../common/transaction.c", line 103: warning: implicit function declaration:
> printf
> "../common/transaction.c", line 105: warning: implicit function declaration:
> perror
> "../common/transaction.c", line 128: warning: assignment type mismatch:
>         pointer to void "=" pointer to function() returning void
> "../common/transaction.c", line 138: warning: assignment type mismatch:
>         pointer to void "=" pointer to function() returning void
> "../common/transaction.c", line 305: warning: no explicit type given for
> parameter: threadID
> "../common/transaction.c", line 405: warning: parameter in inline asm
> statement unused: %0
> "../common/transaction.c", line 413: warning: parameter in inline asm
> statement unused: %0
> "../common/transaction.c", line 421: warning: parameter in inline asm
> statement unused: %0
> "../common/transaction.c", line 429: warning: parameter in inline asm
> statement unused: %0
> "../common/transaction.c", line 436: warning: parameter in inline asm
> statement unused: %0
> "../common/transaction.c", line 511: warning: argument #2 is incompatible
> with prototype:
>         prototype: pointer to function(int) returning void :
> "/usr/include/iso/signal_iso.h", line 48
>         argument : pointer to function() returning void
> "../common/transaction.c", line 536: warning: pointer to void or function
> used in arithmetic
> "../common/transaction.c", line 543: warning: pointer to void or function
> used in arithmetic
> "../common/transaction.c", line 543: warning: assignment type mismatch:
>         pointer to void "=" pointer to function(int) returning void
> "../common/transaction.c", line 556: warning: pointer to void or function
> used in arithmetic
> "../common/transaction.c", line 556: warning: assignment type mismatch:
>         pointer to void "=" pointer to function(int) returning void
> /u/ftabba/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
> -I../common -lpthread -o deque_TM deque_TM.o transaction.o
> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
> -I../common -DGLOBAL_LOCK -c -o deque_Lock.o deque.c
> "deque.c", line 134: warning: implicit function declaration:
> tm_bind_to_cabinet
> "deque.c", line 135: warning: implicit function declaration:
> Barrier_breaking
> "deque.c", line 136: warning: implicit function declaration:
> set_transaction_registers
> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
> -I../common -lpthread -o deque_Lock   deque_Lock.o transaction.o
> -----------------
>
> I get similar symptoms at 3 than I do for the following dump file:-
>
> http://www.cs.auckland.ac.nz/~fuad/dq.TIMESTAMP
>
> Cheers,
> /Fuad
>
> On Thu, Jun 19, 2008 at 4:49 PM, Fuad Tabba <fuad@xxxxxxxxxxxxxxxxx> wrote:
>>
>> Sorry, the link I provided point to the wrong file. Here are the corrected
>> links:-
>>
>> http://www.cs.auckland.ac.nz/~fuad/dq.TIMESTAMP
>> http://www.cs.auckland.ac.nz/~fuad/dq.BASE
>>
>> Cheers,
>> /Fuad
>>
>> On Thu, Jun 19, 2008 at 4:44 PM, Fuad Tabba <fuad@xxxxxxxxxxxxxxxxx>
>> wrote:
>>>
>>> Thanks Dann.
>>>
>>> I think I'm making progress. I modified the file transaction.h that comes
>>> with GEMS 2.1 as follows (everything else is the same):-
>>>
>>> -------------------------
>>> // #define NEW_RUBY_MAGIC_CALL( service ) \
>>> // __asm__ __volatile__ \
>>> // ( "sethi %1, %%g0 !magic service %2\n\t" \
>>> // : /* no outputs */ \
>>> // : "r" (0), "i" (service), "i" (service) \
>>> // : "l0", "memory" /* clobber register */ \
>>> // );
>>>
>>> #define __MAGIC_CASSERT(p) do
>>> {                                                \
>>>         typedef int __check_magic_argument[(p) ? 1 :
>>> -1];                      \
>>>     } while (0)
>>>
>>> #define MAGIC(n) do
>>> {                                                          \
>>>         __MAGIC_CASSERT((n) > 0 && (n) < (1U <<
>>> 22));                          \
>>>         asm ("sethi " #n ",
>>> %g0");                                             \
>>>     } while (0)
>>>
>>> #define NEW_RUBY_MAGIC_CALL( service ) MAGIC((service));
>>> -------------------------
>>>
>>> I compiled deque with sun c and here's the weird thing; it seems to be
>>> working fine if I use the flags:-
>>>
>>> -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>>
>>> However, just by adding -DNDEBUG it acts up. This is the output of
>>> compiling/building it:-
>>>
>>> -------------------------
>>> ~/transactional/deque$ ~/SUNWspro/bin/cc -V
>>> cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
>>> usage: cc [ options] files.  Use 'cc -flags' for details
>>> ~/transactional/deque$ make clean && make
>>> rm -f deque_TM deque_Lock   *.o
>>> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>> -DNDEBUG  -I../common -c -o deque_TM.o deque.c
>>> "deque.c", line 134: warning: implicit function declaration:
>>> tm_bind_to_cabinet
>>> "deque.c", line 135: warning: implicit function declaration:
>>> Barrier_breaking
>>> "deque.c", line 136: warning: implicit function declaration:
>>> set_transaction_registers
>>> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>> -DNDEBUG  -I../common -c -o transaction.o ../common/transaction.c
>>> "../common/transaction.c", line 103: warning: implicit function
>>> declaration: printf
>>> "../common/transaction.c", line 105: warning: implicit function
>>> declaration: perror
>>> "../common/transaction.c", line 128: warning: assignment type mismatch:
>>>         pointer to void "=" pointer to function() returning void
>>> "../common/transaction.c", line 138: warning: assignment type mismatch:
>>>         pointer to void "=" pointer to function() returning void
>>> "../common/transaction.c", line 305: warning: no explicit type given for
>>> parameter: threadID
>>> "../common/transaction.c", line 405: warning: parameter in inline asm
>>> statement unused: %0
>>> "../common/transaction.c", line 413: warning: parameter in inline asm
>>> statement unused: %0
>>> "../common/transaction.c", line 421: warning: parameter in inline asm
>>> statement unused: %0
>>> "../common/transaction.c", line 429: warning: parameter in inline asm
>>> statement unused: %0
>>> "../common/transaction.c", line 436: warning: parameter in inline asm
>>> statement unused: %0
>>> "../common/transaction.c", line 511: warning: argument #2 is incompatible
>>> with prototype:
>>>         prototype: pointer to function(int) returning void :
>>> "/usr/include/iso/signal_iso.h", line 48
>>>         argument : pointer to function() returning void
>>> "../common/transaction.c", line 536: warning: pointer to void or function
>>> used in arithmetic
>>> "../common/transaction.c", line 543: warning: pointer to void or function
>>> used in arithmetic
>>> "../common/transaction.c", line 543: warning: assignment type mismatch:
>>>         pointer to void "=" pointer to function(int) returning void
>>> "../common/transaction.c", line 556: warning: pointer to void or function
>>> used in arithmetic
>>> "../common/transaction.c", line 556: warning: assignment type mismatch:
>>>         pointer to void "=" pointer to function(int) returning void
>>> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>> -DNDEBUG  -I../common -lpthread -o deque_TM deque_TM.o transaction.o
>>> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>> -DNDEBUG  -I../common -DGLOBAL_LOCK -c -o deque_Lock.o deque.c
>>> "deque.c", line 134: warning: implicit function declaration:
>>> tm_bind_to_cabinet
>>> "deque.c", line 135: warning: implicit function declaration:
>>> Barrier_breaking
>>> "deque.c", line 136: warning: implicit function declaration:
>>> set_transaction_registers
>>> ~/SUNWspro/bin/cc -xO3 -m32 -xarch=sparcvis -DSIMICS -xregs=no%appl
>>> -DNDEBUG  -I../common -lpthread -o deque_Lock   deque_Lock.o transaction.o
>>> -------------------------
>>>
>>> With -NDEBUG, running two threads on four processors, if I use TIMESTAMP,
>>> then thread #0 just dissappear somewhere which thread #1 finishes. If I use
>>> BASE then I get stuck with thread #0 getting nacks all the time and thread
>>> #1 dissappearing.
>>>
>>> http://www.cs.auckland.ac.nz/~fuad/dq.TIMESTAMP
>>> http://www.cs.auckland.ac.nz/~fuad/dq.BASE
>>>
>>> The funny thing is, it works just fine _without_ -DNDEBUG.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> /Fuad
>>>
>>> On Thu, Jun 19, 2008 at 2:01 PM, Daniel Nussbaum - Sun Microsystems -
>>> Burlington United States <dan.nussbaum@xxxxxxx> wrote:
>>>>
>>>> >
>>>> > Date: Thu, 19 Jun 2008 10:43:44 +1200
>>>> > From: 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:-
>>>> >
>>>>
>>>> Our version of magic-instruction.h (included below) shows how we
>>>> generate magic instructions.  It's easy enough to add versions for the
>>>> other various magic instructions you'll want.
>>>>
>>>> I suspect you'll want to inline this way, since at least with older
>>>> versions of some compilers, using asm() inlining causes most other
>>>> optimizations to be turned off in the entire enclosing function.
>>>>
>>>> dann
>>>>
>>>> ----------------------
>>>> [magic-instruction.h]
>>>> -----------
>>>> /*
>>>>  * magic-instruction.h
>>>>  */
>>>>
>>>> #ifndef   _SIMICS_SIMICS_MAGIC_INSTRUCTION_H
>>>>
>>>> #define   _SIMICS_SIMICS_MAGIC_INSTRUCTION_H
>>>>
>>>>
>>>> #define __MAGIC_CASSERT(p) do {                     \
>>>>  typedef int __check_magic_argument[(p) ? 1 : -1]; \
>>>> } while (0)
>>>>
>>>> #define MAGIC(n) do {                               \
>>>>  __MAGIC_CASSERT((n) > 0 && (n) < (1U << 22));     \
>>>>  asm ("sethi " #n ", %g0");                        \
>>>> } while (0)
>>>>
>>>> #define MAGIC_BREAKPOINT MAGIC(0x40000)
>>>>
>>>>
>>>> //
>>>> //  Signal a breakpoint.
>>>> //
>>>> inline void
>>>> ruby_breakpoint()
>>>> {
>>>>  // With Ruby/LogTM, this is how you get a breakpoint.
>>>>  //
>>>>  MAGIC(0x40000);
>>>> }
>>>>
>>>> //
>>>> // Tell simics we've started a unit of work.
>>>> //
>>>> inline void
>>>> ruby_begin_unit()
>>>> {
>>>>  // With Ruby/LogTM, this is how you signify completion of a "unit of
>>>>  // work".
>>>>  //
>>>>  MAGIC(0x30000);
>>>> }
>>>>
>>>> //
>>>> // Tell simics we've finished a unit of work.
>>>> //
>>>> inline void
>>>> ruby_finish_unit()
>>>> {
>>>>  // With Ruby/LogTM, this is how you signify completion of a "unit of
>>>>  // work".
>>>>  //
>>>>  MAGIC(0x50000);
>>>> }
>>>>
>>>> //
>>>> // Dump registers to simulator console.
>>>> //
>>>> inline void
>>>> ruby_dump_registers()
>>>> {
>>>>  MAGIC(100);
>>>> }
>>>>
>>>>
>>>> #endif /* _SIMICS_SIMICS_MAGIC_INSTRUCTION_H */
>>>> _______________________________________________
>>>> 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.
>
>
>



-- 
Regards
James Wang