* Mark Burton (mark.bur...@greensocs.com) wrote: > Actually - I dont see any other option. > Playing with the ideas - it seems to me that if we were to implement > ?generic? Lock/unlock instructions which could then somehow we ?combined? > with loads/stores then we would be relying on an optimisation step to > ?notice? that this could be combined into e.g. a store EX on ARM, or > whatever. That strikes me as risky . > > But then - if we add load/store exclusive type operations - thats great for > e.g. ARM on X86, but does it really cover other architectures well? > > I am worried that if we go this path, we will soon end up with a lot of > architecturally specific TCG ops?.
I'd expect you to end up with two types; 1) the ARM/MIPS/PPC split load/store, 2) the x86/s390/ARMv8.1 compare exchange. The tricky thing is to pick a sane set of TCG ops that is a good fit into each of the two groups on different targets. Dave > > Cheers > > Mark. > > > On 17 Dec 2014, at 12:25, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > > > > > On 17/12/2014 12:18, Alexander Graf wrote: > >> > >> So I think the best way to go forward would be to add transaction_start > >> and transaction_end opcodes to TCG and implement them as mutex locks > >> today. When you get the chance to get yourself a machine that supports > >> actual TM, try to replace them with transaction start/end blocks and > >> have the normal mutex code as fallback if the transaction fails. > > > > Or implement load_locked/store_conditional TCG ops. They can be > > implemented as transactions, hardware ll/sc, or something slow that uses > > the MMU. > > > > Paolo > > > +44 (0)20 7100 3485 x 210 > +33 (0)5 33 52 01 77x 210 > > +33 (0)603762104 > mark.burton > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
