Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26244
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Speaking of Multiprocessing... |
| Date | 2017-03-25 15:25 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <ob5uft$ueq$1@dont-email.me> (permalink) |
| References | (6 earlier) <ob3la6$hgb$1@dont-email.me> <ob3n13$nhe$1@dont-email.me> <ob3nd5$ot2$1@dont-email.me> <ob4ek3$8v4$1@dont-email.me> <ob4jdu$k87$1@dont-email.me> |
On 25/03/17 03:10, rickman wrote: > On 3/24/2017 8:48 PM, David Brown wrote: >> On 24/03/17 19:12, rickman wrote: >>> On 3/24/2017 2:06 PM, David Brown wrote: >>>> On 24/03/17 18:36, rickman wrote: >>>>> On 3/24/2017 3:07 AM, Robert Wessel wrote: >>>>>> On Fri, 24 Mar 2017 01:58:26 -0400, rickman <gnuarm@gmail.com> wrote: >>>>>> >>>>>>> On 3/24/2017 1:37 AM, Robert Wessel wrote: >>>>>>>> On Fri, 24 Mar 2017 01:05:02 -0400, rickman <gnuarm@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 3/23/2017 11:43 PM, Robert Wessel wrote: >>>>>>>>>> On Thu, 23 Mar 2017 18:38:13 -0400, rickman <gnuarm@gmail.com> >>>>>>>>>> wrote: >>>> >>>> <snip> >>>> >>>>> >>>>>>> There certainly is no reason for memory to be multiple cycle. I >>>>>>> think >>>>>>> you are picturing various implementations where memory is slow >>>>>>> compared >>>>>>> to the CPU. That's not a given. >>>>>> >>>>>> >>>>>> No, but such a situation is sufficiently uncommon that you'd really >>>>>> want to spec it up front. Most cores these days don't even have >>>>>> single cycle L1 caches. >>>>> >>>>> Again, assuming an architecture and requirements. This >>>>> conversation is >>>>> not about designing the next generation of ARM CPU. >>>> >>>> It would be making architecture assumptions to require single-cycle >>>> memory - saying that memory may be multiple cycle is the general case. >>>> >>>> (You might /want/ to make architecture assumptions here - I gave some >>>> other suggestions of specific hardware for locking in another post. >>>> The >>>> solutions discussed here are for general memory.) >>> >>> We are having two different conversations here. I am designing a CPU, >>> you are talking about the theory of CPU design. >> >> Aha! That is some useful information to bring to the table. You told >> us earlier about some things that you are /not/ doing, but not what you >> /are/ doing. (Or if you did, I missed it.) >> >> In that case, I would recommend making some dedicated hardware for your >> synchronisation primitives. A simple method is one I described earlier >> - have a set of memory locations where you the upper half of each 32-bit >> entry is for a "thread id". You can only write to the entry if the >> current upper half is 0, or it matches the thread id you are writing to >> it. It should be straightforward to implement in an FPGA. >> >> The disadvantage of this sort of solution is scaling - if your hardware >> supports 64 such semaphores, then that's all you've got. A solution >> utilizing normal memory (such as TAS, CAS, LL/SC) lets user code make as >> many semaphores as it wants. But you can always use the hardware ones >> to implement more software semaphores indirectly. > > I guess I didn't explain the full context. But as I mentioned, it is > simpler I think to include the swap memory instruction that will allow a > test and set operation to be implemented atomically without disrupting > any other functions. It will use up an opcode, but it would be a simple > one with the only difference from a normal memory write being the use of > the read path. > Well, you are the one implementing this - so you have to figure out what solution makes most sense for you. Here's another idea you could consider. If you are dealing with just one CPU here, I have always thought a "disable interrupts for the next X instructions then restore interrupt status" instruction would be handy - with X being something like 4. That would let you do atomic reads, writes or read-modify-write instructions covering at least two memory addresses, without need for special memory or read-write-modify opcodes.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-23 18:38 -0400
Re: Speaking of Multiprocessing... Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:19 -0500
Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-23 16:26 -0700
Re: Speaking of Multiprocessing... Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:47 -0500
Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-23 17:49 -0700
Re: Speaking of Multiprocessing... upsidedown@downunder.com - 2017-03-24 09:48 +0200
Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-24 01:22 -0700
Re: Speaking of Multiprocessing... Clifford Heath <no.spam@please.net> - 2017-03-24 21:04 +1100
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:01 -0500
Re: Speaking of Multiprocessing... Clifford Heath <no.spam@please.net> - 2017-03-25 18:49 +1100
Re: Speaking of Multiprocessing... Grant Edwards <invalid@invalid.invalid> - 2017-03-24 14:36 +0000
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-23 22:43 -0500
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 01:05 -0400
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 00:37 -0500
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 01:58 -0400
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 02:07 -0500
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 13:36 -0400
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 19:06 +0100
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 14:12 -0400
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-25 01:48 +0100
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 22:10 -0400
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-25 15:25 +0100
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-25 15:27 -0400
Re: Speaking of Multiprocessing... upsidedown@downunder.com - 2017-03-25 22:43 +0200
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-25 17:06 -0400
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-26 17:28 +0200
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-26 13:27 -0400
Re: Speaking of Multiprocessing... Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-25 00:42 +0200
Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 19:22 -0400
Re: Speaking of Multiprocessing... Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-03-24 16:33 -0700
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:47 -0500
Re: Speaking of Multiprocessing... Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-25 12:40 +0200
Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 00:42 -0500
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 09:17 +0100
Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 09:28 +0000
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 11:19 +0100
Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 11:06 +0000
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 12:21 +0100
Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 16:09 +0000
Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 17:33 +0100
Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 17:52 +0000
csiph-web