> > > > Why are 64-bit atomic load and stores required? To take an example. ARM6 > > > > cores have have load stores for a very long time[1]. But being a 32-bit core > > > > that's usually attached to a 32 bit memory bus, the instructions are 32-bit. > > > > So is it just that an atomic pair of load and store operations are required? > > > > I am of course assuming that gcc or clang on these platforms can make use of > > these instructions. > > Yes, it needs just atomic loads and stores.
Good, so in theory almost any modern processor architecture can be supported. > > > If all that is needed are atomic loads and stores then that leads to the second question. Why hasn't a 32-bit port (with a reduced memory map) of the thread sanitizer already appeared? There are lots of other 32 bit cores with atomic load sores - MIPS32, PPC, SPARC etc... At the minute I feel I am missing something _very_ important. Otherwise this looks like it should be a solved problem. A 32-bit version would be quite restrictive wrt the amount of memory an app can use. Tsan can have up to 10x overhead, with Go's GC overhead this goes to up to 20x. But I think the real reason is that nobody was interested enough in it to implement it. There can also be some hidden problems that I don't see (we never seriously considered porting tsan to 32-bits). So next dumb question. How did you work out the memory mappings for 64-bit systems and do you want to take a stab at what the mappings might be for a 32 bit system? I know the memory map will be smaller and it will restrict things but it might be enough for what I need (and possibly others working on small embedded hardware). But this seems to be heading towards a conclusion of. "Somebody just needs to try it, and see what happens." So in that case: a) What do I need to do to rebuild the lib? So I need clang or will gcc do? b) Is the library difficult to rebuild? Is there anything special I need to know? c) The memory maps are laid out using "unsigned long long!" types (as would be expected). I am assuming that in a 32 bit world I can just leave these alone- rather than convert them to unsigned long, and take the overhead or both size and performance? d) Can you think of anything else I might have to change in the code? Owen -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
