guineau@wjg.enet.dec.com (05/04/90)
>>1. Does it operate in the same way as the one in the 2000? >> That is take over from the motherboard CPU. > >Yes. There are actually several takeover and clocking options for >a Coprocessor slot card. Take Over! You mean no one will (can) design a set of CPU's for the A3000 and hack SMP into AmigaDOS? Amiga Unix? :-) Heck, even if it wasn't SMP, an 'extra' 68030 hanging around the mother board seems like an awfull waste... How about a pfork() call that sends part of the code off on another processor?!? --- W. John Guineau guineau@wjg.enet.dec.com Digital Equipment Corporation Marlboro MA. 01752
daveh@cbmvax.commodore.com (Dave Haynie) (05/04/90)
In article <11007@shlump.nac.dec.com> guineau@wjg.enet.dec.com writes: >>>1. Does it operate in the same way as the one in the 2000? >>> That is take over from the motherboard CPU. >>Yes. There are actually several takeover and clocking options for >>a Coprocessor slot card. >Take Over! [..] an 'extra' 68030 hanging around the mother board >seems like an awfull waste... Just like in the 2000, a Coprocessor slot device can take over all system operations from the motherboard processor, becoming a full fledged primary bus master and the one and only CPU active in a uniprocessor configuration. However, you will notice that I call this slot the "Coprocessor" slot. Just like on the 2000, a Coprocessor slot device can only take over the motherboard bus for short bursts, keeping the motherboard '030 active the other times. On top of this, there are actually two different mechanisms to effect either of these transfer-of-control operations; one that's very much like a normal 68030 bus arbitration, and one that's a modified 68030 bus arbitration: a bit of additional complexity, but it's very fast. So, in other words, the Coprocessor slot card can take over completely or run in parallel with the motherboard CPU. In the latter case, that coprocessor slot CPU will need some private memory so that it's not eating up all the motherboard bus bandwidth. >W. John Guineau guineau@wjg.enet.dec.com >Digital Equipment Corporation >Marlboro MA. 01752 -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
amc4919@cec1.wustl.edu (Adam Michael Costello) (05/05/90)
In article <11321@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >Just like in the 2000, a Coprocessor slot device can take over all system >operations from the motherboard processor, becoming a full fledged primary >bus master and the one and only CPU active in a uniprocessor configuration. >However, you will notice that I call this slot the "Coprocessor" slot. >Just like on the 2000, a Coprocessor slot device can only take over the >motherboard bus for short bursts, keeping the motherboard '030 active the >other times. On top of this, there are actually two different mechanisms >to effect either of these transfer-of-control operations; one that's very >much like a normal 68030 bus arbitration, and one that's a modified 68030 >bus arbitration: a bit of additional complexity, but it's very fast. > >So, in other words, the Coprocessor slot card can take over completely >or run in parallel with the motherboard CPU. In the latter case, that >coprocessor slot CPU will need some private memory so that it's not eating >up all the motherboard bus bandwidth. Will the '030 be able to access the RAM on the Coprocessor card? This sounds like true parallel processing. Will the OS be able to cope with this, or will it be up to individual programs and the user to take advantage of this? Thanks, AMC
valentin@cbmvax.commodore.com (Valentin Pepelea) (05/05/90)
In article <1990May4.195424.8119@cec1.wustl.edu> amc4919@cec2.UUCP (Adam Michael Costello) writes: > > Will the '030 be able to access the RAM on the Coprocessor card? This sounds > like true parallel processing. Will the OS be able to cope with this, or will > it be up to individual programs and the user to take advantage of this? It all depends on how the engineer decides to design his accelerator board. There is no reason why the motherboard 68030 should not be able to access the accelerator's memory, except of course real estate and complexity. That's "true multi-processing", not parallel processing, by the way. But then we already have that with the graphic coprocessors. The operating system is not written to automatically take advantage of such an independent accelerator, but it is conceivable to write one in the future. Depending on whose opninion you ask for, here at Commodore, you will either be told that is incredibly difficult, or that it's a snap. I'm part of the Snap, Crackle and Pop group. :-) Meanwhile, it should be Crackle for third party devellopers to write pragrams which take advantage of proprietary multiprocessing boards. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
kim@uts.amdahl.com (Kim E. DeVaughn) (05/06/90)
In article <11378@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > > There is no reason why the motherboard 68030 should not be able to access > the accelerator's memory, except of course real estate and complexity. That's > "true multi-processing", not parallel processing, by the way. > > The operating system is not written to automatically take advantage of such > an independent accelerator, but it is conceivable to write one in the future. > Depending on whose opninion you ask for, here at Commodore, you will either > be told that is incredibly difficult, or that it's a snap. Are you implying that Zorro3 now supports atomic read-write-update cycles now (i.e., test-and-set, and similar operations)? And what about cache coherency (I'm not up on 030 bus-snooping specs)? > I'm part of the > Snap, Crackle and Pop group. :-) Is that different than the "poof!" group? :-) /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
valentin@cbmvax.commodore.com (Valentin Pepelea) (05/08/90)
In article <72GN02gAa4MS01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim E. DeVaughn) writes: > > Are you implying that Zorro3 now supports atomic read-write-update cycles now > (i.e., test-and-set, and similar operations)? Nowhere in my article did I imply such a thing, but yes, RMC (ream-modify- cycles) are supported on the Zorro III bus. Semaphore implementations for inter-processor synchronisation is thus simplified. > And what about cache coherency (I'm not up on 030 bus-snooping specs)? There are new functions in the Exec allowing you to flush the cache when necessary. Furthermore, some regions of memory are declared as non-cacheable. This is simple to implement using either hardware cache inhibition or software translation table inhibition. >> I'm part of the Snap, Crackle and Pop group. :-) > >Is that different than the "poof!" group? :-) Never heard of the "poof!" group, but you all now Capt. Crunch, don't you? Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
kim@uts.amdahl.com (Kim E. DeVaughn) (05/08/90)
In article <11413@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > In article <72GN02gAa4MS01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (I) wrote: > > > > Are you implying that Zorro3 now supports atomic read-write-update cycles now > > (i.e., test-and-set, and similar operations)? > > Nowhere in my article did I imply such a thing, but yes, RMC (ream-modify- > cycles) are supported on the Zorro III bus. Semaphore implementations for > inter-processor synchronisation is thus simplified. Well ... you did say you thought multiprocessing would be "a snap", and I can't see how it'd be *easy* without atomic Test-and-Set capabilities. I'm pleased to see that Zorro-III is supporting this, but couldn't this pose a problem when s/w that does this is run on a Zorro-II machine, where the co- processor chips can sneak-in in the middle of the read-modify-write cycle? Or are you planning to have the OS handle this for the application, and "do the right thing" depending on what kind of machine it's running on? > > And what about cache coherency (I'm not up on 030 bus-snooping specs)? > > There are new functions in the Exec allowing you to flush the cache when > necessary. Furthermore, some regions of memory are declared as non-cacheable. > This is simple to implement using either hardware cache inhibition or > software translation table inhibition. So we'll have to depend on such applications and/or AmigaOS to be "well- behaved" and ask the "other" CPU(s) to flush, if the access is going to be made to a memory location that could be shared? Is that correct? Speaking of caches, does the A3000's SCSI-driver "do the right thing" and flush the data cache(s), so one can run with the D-cache enabled without worry now? All this foresight sounds very positive for the future. Good job y'all!!! "Amiga ... the 1st *afordable* multiprocessing machine. While other's are struggling to but implement multitasking!" ... I love it! :-) > > > I'm part of the Snap, Crackle and Pop group. :-) > > > >Is that different than the "poof!" group? :-) > > Never heard of the "poof!" group, but you all now Capt. Crunch, don't you? Hmmmmm ... "poof!" was the equivalent to "It's in there!" during the 1.2->1.3 upgrade timeframe (possibly before that). I think it was Dave Haynie, or maybe Andy Finkel who I first noticed using it. As for "Crunch" ... did he ever get his legal difficulties resolved ... anyone know ...? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
valentin@cbmvax.commodore.com (Valentin Pepelea) (05/09/90)
In article <29VY02MJa5P.01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim E. DeVaughn) writes: > >Well ... you did say you thought multiprocessing would be "a snap", and I >can't see how it'd be *easy* without atomic Test-and-Set capabilities. Semaphores can be implemented using three flags, for two communicating tasks, plus one flag for each additional task (processor). This is well explained in any good OS textbook. >I'm pleased to see that Zorro-III is supporting this, but couldn't this pose >a problem when s/w that does this is run on a Zorro-II machine, where the co- >processor chips can sneak-in in the middle of the read-modify-write cycle? Devellopers of multi-processor boards will probably choose to produce Zorro III cards only. >So we'll have to depend on such applications and/or AmigaOS to be "well- >behaved" and ask the "other" CPU(s) to flush, if the access is going to be >made to a memory location that could be shared? Is that correct? No support for multi-processing has been put in the OS yet. So data handshaking models still have to be thought out. Shared areas of memory are likely to be either non-cacheable, or special data transferring functions will take care of cache coherency. >Speaking of caches, does the A3000's SCSI-driver "do the right thing" and >flush the data cache(s), so one can run with the D-cache enabled without >worry now? To my knowledge, yes. >All this foresight sounds very positive for the future. Good job y'all!!! > >"Amiga ... the 1st *afordable* multiprocessing machine. While other's are > struggling to but implement multitasking!" ... I love it! :-) Whoa! Wait a minute! We don't have it yet. Nobody has yet made a multi- processing board. In fact, nobody has yet made a Zorro III board! >> Never heard of the "poof!" group, but you all now Capt. Crunch, don't you? > >Hmmmmm ... "poof!" was the equivalent to "It's in there!" during the 1.2->1.3 >upgrade timeframe (possibly before that). I think it was Dave Haynie, or maybe >Andy Finkel who I first noticed using it. As for "Crunch" ... did he ever >get his legal difficulties resolved ... anyone know ...? I guess we are referring to different Captain Crunches. The term was first used to my knowledge after I made an appeal for a multi cereal card, hoping Kellogs just might... But they did not. I guess they did not see how multi cereal ports can mix with 5V power lines to produce snap, crackles and pops. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
smaug@eng.umd.edu (Kurt Lidl) (05/09/90)
In article <29VY02MJa5P.01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim E. DeVaughn) writes: > >Well ... you did say you thought multiprocessing would be "a snap", and I >[...] > >I'm pleased to see that Zorro-III is supporting this, but couldn't this pose >a problem when s/w that does this is run on a Zorro-II machine, where the co- >processor chips can sneak-in in the middle of the read-modify-write cycle? > >Or are you planning to have the OS handle this for the application, and "do >the right thing" depending on what kind of machine it's running on? I can hardly wait. AmigaDOS 3.0 introduces SMP support for all you people with A3000's and a '040 card. (SMP = Symetric Multi-Processor) > >All this foresight sounds very positive for the future. Good job y'all!!! Amen. >UUCP: kim@amdahl.amdahl.com -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */
kim@uts.amdahl.com (Kim DeVaughn) (05/09/90)
In article <11447@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > In article <29VY02MJa5P.01@amdahl.uts.amdahl.com> kim@uts.amdahl.com > (Kim E. DeVaughn) writes: > > > >Well ... you did say you thought multiprocessing would be "a snap", and I > > Semaphores can be implemented using three flags, for two communicating tasks, > plus one flag for each additional task (processor). This is well explained in Sure. But then it's more of a "crackle", than a "snap" :-) > >I'm pleased to see that Zorro-III is supporting this, but couldn't this pose > >a problem when s/w that does this is run on a Zorro-II machine, where the co- > >processor chips can sneak-in in the middle of the read-modify-write cycle? > > Devellopers of multi-processor boards will probably choose to produce Zorro III > cards only. It's a moot point at this stage, but I was refering to the S/W that might be developed. Guess any such applications will have to have a special MP version, or be designated Zorro-III only, or blow-off the idea of MP'ing entirely. > >So we'll have to depend on such applications and/or AmigaOS to be "well- > >behaved" and ask the "other" CPU(s) to flush, if the access is going to be > >made to a memory location that could be shared? Is that correct? > > No support for multi-processing has been put in the OS yet. So data handshaking > models still have to be thought out. Shared areas of memory are likely to be > either non-cacheable, or special data transferring functions will take care > of cache coherency. Which is why this is a good thing to be discussing now. And at least it *is* being thought about. > >Speaking of caches, does the A3000's SCSI-driver "do the right thing" and > > To my knowledge, yes. Great! > >All this foresight sounds very positive for the future. Good job y'all!!! > > > >"Amiga ... the 1st *afordable* multiprocessing machine. While other's are > > struggling to but implement multitasking!" ... I love it! :-) > > Whoa! Wait a minute! We don't have it yet. Nobody has yet made a multi- > processing board. In fact, nobody has yet made a Zorro III board! Just thinking ahead. Make a good theme for an ad campaign, and maybe keep a few people awake late in some other vendor's shops! > >> Never heard of the "poof!" group, but you all now Capt. Crunch, don't you? > > > >Andy Finkel who I first noticed using it. As for "Crunch" ... did he ever > >get his legal difficulties resolved ... anyone know ...? > > I guess we are referring to different Captain Crunches. The term was first used > to my knowledge after I made an appeal for a multi cereal card, hoping Kellogs I must've missed that exchange. I was refering to John Draper, who went by the handle "Capt'n Crunch" back in his phone phreaking days years ago. He was also one of the early Amiga developers, and used to show up at BADGE regularly. (GadEd, on an early FishDisk was a cooperative effort, that he kicked off). He was accused in '86 or so, of duplicating BART (Bay Area Rapid Transit) tickets, and all his computer equipment confiscated. Last I heard (a couple years ago), his equipment had been returned, but I never did hear what the final outcome was. Just a bit of "lore", and totally off the subject of h/w, MP, etc ... sorry. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
swansonc@balder.acc.stolaf.edu (Chris Swanson, Systems Operator - ACC @ St. Olaf College) (05/10/90)
Alan, this is just information I received from an Amiga dealer-friend
of mine, but he has heard some interesting things from GVP of late.
1) Within the next month, expect a 50MHz 68030 card for the 2000
(Don't know if this can be used in the 3000, I would assume so.)
2) By next fall, expect a GVP 68040 CPU card. I don not know
what platform(s) it will be for.
Just rumors in the wind....
-Chris
--
Chris Swanson, Academic Computing Center, St. Olaf College, Northfield,MN 55057
INTERNET: swansonc@acc.stolaf.edu UUCP: swansonc@stolaf
AT&T: Work: (507)-645-6845 Home: (507)-663-2154
I would deny this reality, but that wouldn't pay the bills...martin@cbmvax.commodore.com (Martin Hunt) (05/10/90)
In article <SWANSONC.90May9151131@balder.acc.stolaf.edu> swansonc@balder.acc.stolaf.edu (Chris Swanson, Systems Operator - ACC @ St. Olaf College) writes: > >Alan, this is just information I received from an Amiga dealer-friend >of mine, but he has heard some interesting things from GVP of late. > >1) Within the next month, expect a 50MHz 68030 card for the 2000 > (Don't know if this can be used in the 3000, I would assume so.) The 3000 has a totally different 200 pin CPU slot. There is no way to use a 2000 CPU card in a 3000. I hope the 50MHz 030 card has a decent cache on it, or any speedup will be very modest. >Chris Swanson, Academic Computing Center, St. Olaf College, Northfield,MN 55057 -- Martin Hunt martin@cbmvax.commodore.com Commodore-Amiga Engineering {uunet|pyramid|rutgers}!cbmvax!martin