Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!vsi1!daver!mips!earl@wright.mips.com From: earl@wright.mips.com (Earl Killian) Newsgroups: comp.arch Subject: Re: MIPS Architechture Question Keywords: read-modify-write? What's that? Message-ID: <11197@wright.mips.COM> Date: 14 Jan 89 18:20:56 GMT References: <557@oracle.UUCP> Sender: earl@mips.COM Reply-To: earl@wright (Earl Killian) Organization: MIPS Computer Systems, Sunnyvale CA Lines: 49 In-reply-to: csimmons@hqpyr1.oracle.UUCP (Charles Simmons) In article <557@oracle.UUCP>, csimmons@hqpyr1 (Charles Simmons) writes: <> The MIPS R2000 and R3000 do not have special instructions for multiprocessor synchronization. When the R2000 was being designed, anything that wasn't going to be used, or wasn't fully understood was left out, to be added later, when it could be developed in tandem with the system and software. The classical "test-and-set" or equivalent was explicitly omitted, especially after consultation with various people who had serious MP experience: a) No one (or even two or three) of the classic synchronization operations made all MP designers happy. Many of them expected to add substantial synchronization hardware in any case. It was thus clear that we did not have a solution available at the time that was sufficient, and as usual, we don't put things in there that we're not sure are the right things. b) A traditional test-and-set complexifies the design, which would be OK if you thought it was THE solution. However, especially for serious high-performance MP's, any construct that really wants to lock the bus is a no-no anyway. To do read-modify-write operation on the VME bus, MIPS cpu boards support locations that can be set that cause the next VME reference to hold the bus, so you can do: store to magic location VME load update VME store reset magic location This service is available only to the Kernel. Some of multiprocessor systems based on the R2000/R3000 implement memory mapped locations that can be used by user programs for synchronization. In the future when MIPS does multiprocessing (which means chips, systems, os, and compilers), we might do it by adding instructions. Or we might not. I'm not sure what the multiply/divide instructions have to do with mp. After executing a MULT or DIV instruction, the hardware churns away while you execute new instructions. If you execute a MFLO or MFHI to read the multiply/divide result, the hardware interlocks and waits. If you take an exception, the hardware churns away as usual (the multiply/divide has committed after all). It the exception handler executes a MFLO or MFHI, it interlocks as usual. -- UUCP: {ames,decwrl,prls,pyramid}!mips!earl USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086