I'm with Tyler on this one -- as long as you simulate at the granularity of a single cycle (which marss does), then all behavior is well-defined in that you can make the software follow the same rules as hardware would.
On Wed, Sep 18, 2013 at 6:00 PM, <[email protected]> wrote: > Everything is simulated concurrently, just on the granularity of a > cycle... in the event two cores both make the same request concurrently, > some arbitration logic would be responsible for dictating which one of the > cores should proceed with the request first. The hardware would have the > same limitations here, would it not? > > Tyler > > > Tyler > > > > there is at least one difference between simulating the processors > > sequentially and concurrently. by simulating them sequentially, the > > simulator can not simulate the interaction of instructions in each core > at > > the simulated cycle. > > > > imagine there are 2 cores, both executing a cmp_xchg instruction that > > takes > > one cycle on a memory location, if simulated concurrently, core 0 could > do > > the cmp and set the read flag before doing the exchange and core 1 could > > invalidate that flag and force core 0 to do the cmp again. However, this > > will not happen if the 2 instructions from the cores are simulated > > sequentially. > > > > I am not sure this is a realistic example, but it is one case in which > > simulating the cores simultaneously provides more realism. > > > > with this being said, would this have an effect on the behavior of TSX ? > > yes, a little. consider core 1 is about to commit a transaction, at the > > same time core 0 writes to a location in core 1 read set. if these 2 > cores > > are simulated in parallel, the txn could end up committing or aborting, > > depending on whether the write from core 0 comes before or after the > > committing. but if core 1 instructions are always simulated before core > 0, > > the txn will always commit. > > > > To sum up, i think simulating the cores sequentially in a per-instruction > > lockstep would be mostly accurate, except if there are subtle > interactions > > among the instructions or microcodes in case of x86 simulated in this > > cycle. > > > > Please correct me if i am wrong. > > > > Xin > > > > > > On Wed, Sep 18, 2013 at 10:11 PM, <[email protected]> wrote: > > > >> How does it make any difference as to whether or not the simulator > >> itself > >> is multithreaded? MARSS itself is single-threaded, yet fully capable of > >> simulating SMT/SMP-based systems, even with features such as TSX. > >> > >> Tyler > >> > >> > - I'm pretty sure this can run multithreaded just like any other marss > >> > simulations. > >> > > >> > this is a difference between being able to simulate multiple cores and > >> > being able run the simulated cores simultaneously. i do not see any > >> option > >> > to have multiple simulated cpus and i see the smp option in QEMU > >> commented > >> > out. any hint to simulate multiple cores simultaneously is greatly > >> > appreciated. > >> > > >> > - In our features branch we have code for Intel's TSX as well. > >> > > >> > does it simulate all the intel TSX instructions ? > >> > > >> > Xin > >> > > >> > > >> > > >> > On Wed, Sep 18, 2013 at 1:21 AM, Brendan Fitzgerald > >> > <[email protected] > >> >> wrote: > >> > > >> >> In our features branch we have code for Intel's TSX as well. > >> >> > >> >> > >> >> On Tue, Sep 17, 2013 at 12:02 PM, Paul Rosenfeld > >> >> <[email protected]>wrote: > >> >> > >> >>> I'm pretty sure this can run multithreaded just like any other marss > >> >>> simulations. > >> >>> > >> >>> > >> >>> On Tue, Sep 17, 2013 at 4:19 AM, Xin Tong > >> >>> <[email protected]>wrote: > >> >>> > >> >>>> Nice work. is this version of marssx86 multithreaded. the benefits > >> of > >> >>>> ASF can not be fully evaluated without running the multiple > >> simulated > >> >>>> cores > >> >>>> simultaneously imho. > >> >>>> > >> >>>> Xin > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Tue, Sep 17, 2013 at 2:14 PM, Paul Rosenfeld > >> >>>> <[email protected]>wrote: > >> >>>> > >> >>>>> See this post from Stephan Diestelhorst: > >> >>>>> > >> > http://www.mail-archive.com/[email protected]/msg01781.html > >> >>>>> > >> >>>>> > >> >>>>> On Tue, Sep 17, 2013 at 12:37 AM, Xin Tong > >> >>>>> <[email protected]>wrote: > >> >>>>> > >> >>>>>> I am thinking about using marssx86 to simulate some workloads > >> using > >> >>>>>> transactional memory. > >> >>>>>> > >> >>>>>> 1. does marssx86h ave support for hardware transactional memory ? > >> >>>>>> 2. does marssx86 run multiple simulated processors > >> simultanouesly, > >> >>>>>> i.e. in different OS threads ? how mature is it ? > >> >>>>>> > >> >>>>>> thank you, > >> >>>>>> Xin > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> http://www.marss86.org > >> >>>>>> Marss86-Devel mailing list > >> >>>>>> [email protected] > >> >>>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>> > >> >>> > >> >>> _______________________________________________ > >> >>> http://www.marss86.org > >> >>> Marss86-Devel mailing list > >> >>> [email protected] > >> >>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >> >>> > >> >>> > >> >> > >> > _______________________________________________ > >> > http://www.marss86.org > >> > Marss86-Devel mailing list > >> > [email protected] > >> > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >> > > >> > >> > >> > > > > > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
