brooks@lll-crg.ARPA (Eugene D. Brooks III) (01/01/70)
> So you're gonna spend maybe 20 G's or more on a memory system, and > to "cut costs" you're gonna use an off-the-shelf microprocessor like > a 68020 or 32032? Gimme a break! I currently do memory intensive simulation work where it would be desireable to have more than 16mb of physical data memory. We now use a VAX 11/780 for this simulation work. We are purchasing of a multiprocessor to use in this simulation work (yes, using all of the cpus on the same problem) where the basic cpu node is of all things that meager little 32032. It seems that a dozen or so of them can do a good job of keeping more than 16mb busy. We sure would like to have more than 16mb of real memory available for our work and you can sure bet that National will widen the virtual address bus as soon as they get the bugs out of the current chip set. As far as using a custom processor is concerned there currently isn't a more cost effective source of cycles than that $500(wishful thinking) 32032 chip set. You just have to use more than one chip set at a time on your problem.
srm@nsc.UUCP (Richard Mateosian) (02/10/85)
In article <5025@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Don't slam National too hard until you try to get Motorola to admit >that there is a non-empty bug list for the 68020. Yes, there *is* >a 68020 bug list. I'm sorry Henry, but you're dead wrong. There is no bug list for the 68020 -- only a list of CORRIGENDA. Of course, I always thought that corrigenda included corrections. These "corrigenda" seem to consist only of errors, but then, the print is so fine I might be missing an occasional correction. There's even a helpful program included. My favorite part is BEQ NORECOVER . . . NORECOVER: WE CANNOT RECOVER FROM THIS FAULT I'm a little weak on 68k assembler syntax, and I can't seem to find those instructions in my 68020 handbook. Perhaps someone can post an explanation. :-) :-) :-) No flames, please. After all the snide remarks from Austin about our bug lists back when we were where they are now, it's nice to be out of the woods and in a position to laugh at them for a while. -- Richard Mateosian {allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!srm@decwrl.ARPA
haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) (02/13/85)
In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >No flames, please. After all the snide remarks from Austin about our bug >lists back when we were where they are now, it's nice to be out of the woods >and in a position to laugh at them for a while. *** This is not a flame *** However, I'd like to know if National has any news about the release date of their full 32-bit processor, which used to be called the 32132 but may now be called the 32532 or something. Richard? \tom haapanen watmath!watdcsu!haapanen
davet@oakhill.UUCP (Dave Trissel) (02/13/85)
In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: > >There's even a helpful program included. My favorite part is > > BEQ NORECOVER > . > >NORECOVER: WE CANNOT RECOVER FROM THIS FAULT > >I'm a little weak on 68k assembler syntax, and I can't seem to find those >instructions in my 68020 handbook. Perhaps someone can post an explanation. > >No flames, please. After all the snide remarks from Austin about our bug >lists back when we were where they are now, it's nice to be out of the woods >and in a position to laugh at them for a while. There is something Richard is not telling you. This is one of the bugs found on first silicon and has long since been corrected. (I use the word "long" poetically since the MC68020 has only been out about 7 months.) It would be of historical interest to find out how many NS16000 masks were produced before the chip could execute any instructions at all. Here is the current "bug" list for the current mask set A45J. We will number them for Richard's convenience: 1) The LINK #size,An instruction which performs frame management will not produce the exact same results as earlier M68000 family members if the stack pointer SP (A7) is specified as the frame register. Note that specifying the stack pointer is an erroneous thing to do in the first place. Well, that terminates the bug list for the current MC68020 chip. Yes, you read that correctly. We know of no other errors on the part and we could have fixed that one on this latest mask but didn't feel it necessary since we expect no program to ever do such a thing to begin with. Of course we don't think the '020 is 100 percent bug free but for us to be working on such trivial corrections should indicate just how sound the chip is. Now, Richard, your remark about Motorola's being where National "was?" Roy Druian here after reading your posting had an interesting response. He thought it odd that you would refer to Motorola being back where you were a couple of years ago when you are still there. I challenge you to post the bug list for the NS320xx family. And please, number the items for my convenience. I have a National bug list from a year ago and if you like I'll post it and you can comment on which bugs are now gone. Actually, I understand that this is a bad time to post something to you since National is forcing its employees to take a no-pay week long leave of absence. So if you don't respond right away, I'll understand. And no, we don't happen to need someone of your expertise at the moment. (I would put a smiley face here, but I am not sure just how severe the situation is at National. Hopefully this is just a temporary measure.) Responses, of course, welcome. It is probably appropriate to move this to net.flame. I just can't see letting someone badmouth the excellent work the '020 team has been doing here at Motorola. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {ihnp4,seismo,ctvax,gatech}!ut-sally!oakhill!davet
dts@gitpyr.UUCP (Danny Sharpe) (02/15/85)
In article <338@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes: >In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >> >>There's even a helpful program included. My favorite part is >> >> BEQ NORECOVER >> . >> >>NORECOVER: WE CANNOT RECOVER FROM THIS FAULT >> >>I'm a little weak on 68k assembler syntax, and I can't seem to find those >>instructions in my 68020 handbook. Perhaps someone can post an explanation. >> >>No flames, please. After all the snide remarks from Austin about our bug The original article which started this discussion was posted in net.nlang because part of it was appropriate for this newsgroup. However, most of the replies don't belong in net.nlang. Please edit the newsgroups line so the article goes to the right groups. -- Either Argle-Bargle IV or someone else. -- Danny Sharpe School of ICS Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!dts
srm@nsc.UUCP (Richard Mateosian) (02/17/85)
In article <952@watdcsu.UUCP> haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) writes: >I'd like to know if National has any news about the release >date of their full 32-bit processor, which used to be called the 32132 >but may now be called the 32532 or something. A long time ago I posted the entire story of our part numbering history. What used to be called the NS32132 is now called the NS32532. It is a future product. The NS32032 is a full 32-bit processor, as was the NS32016, except for the data bus. -- Richard Mateosian {allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!srm@decwrl.ARPA
haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) (02/19/85)
In article <2373@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >>I'd like to know if National has any news about the release >>date of their full 32-bit processor, which used to be called the 32132 >>but may now be called the 32532 or something. >A long time ago I posted the entire story of our part numbering history. >What used to be called the NS32132 is now called the NS32532. It is a >future product. The NS32032 is a full 32-bit processor, as was the >NS32016, except for the data bus. BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this is not a full 32-bit processor like the 68020 which *does* have a 32-bit address. What I really wanted to know was when the 32532 (which *has* 32-bit addresses) will be {announced, sampling, commercial release}. Any info? \tom haapanen watmath!watdcsu!haapanen Don't cry, don't do anything No lies, back in the government No tears, party time is here again President Gas is up for president (c) Psychedelic Furs, 1982
david@daisy.UUCP (David Schachter) (02/21/85)
Can we keep National 32000 stuff in net.micro.16k and Motorola 68000 stuff in
net.micro.68k, PLEASE? There are a number of items cross-put in both categories
that belong only in one or the other. THANK YOU.
(generic disclaimer) {N.F.Q.}henry@utzoo.UUCP (Henry Spencer) (02/21/85)
> Here is the current "bug" list for the current mask set A45J.... > [there follows a trivial bug list] What's customer availability like on the A45J mask set? If it exists only within Motorola, then please don't bother telling us how good it is; we don't care. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
chuqui@nsc.UUCP (The Phantom) (02/23/85)
In article <983@watdcsu.UUCP> haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) writes: > >BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this >is not a full 32-bit processor like the 68020 which *does* have a >32-bit address. What I really wanted to know was when the 32532 >(which *has* 32-bit addresses) will be {announced, sampling, >commercial release}. Any info? The important part of the proceessor is the data bus-- the 32032 does have a full 32 bit data bus. By the time you really NEED 32 bits of address (that is a huge thing, 32 bits...) it'll be there. We have a piece of silicon that is on its way out of the drawing boards that will have that. I've been told to expect first silicon by the end of the year. chuq -- From behind the eight ball: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA We'll be recording at the Paradise Friday night. Live, on the Death label.
phil@amdcad.UUCP (Phil Ngai) (02/24/85)
> >BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this > >is not a full 32-bit processor like the 68020 which *does* have a > >32-bit address. What I really wanted to know was when the 32532 > >(which *has* 32-bit addresses) will be {announced, sampling, > >commercial release}. Any info? > > The important part of the proceessor is the data bus-- the 32032 does have > a full 32 bit data bus. By the time you really NEED 32 bits of address > (that is a huge thing, 32 bits...) it'll be there. But 24 bits of address is not a huge thing, which is what the 32032 has. 24 bits is only 16 Mb or 4 4 Mb memory cards. -- This is my opinion, I guess. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
geoff@desint.UUCP (Geoff Kuenning) (02/24/85)
In article <2385@nsc.UUCP> chuqui@nsc.UUCP (The Phantom) writes: >The important part of the proceessor is the data bus-- the 32032 does have >a full 32 bit data bus. By the time you really NEED 32 bits of address >(that is a huge thing, 32 bits...) it'll be there. (a) 32 bits is a bit less than five Eagles worth of byte-addressed data. I can easily concoct a microprocessor application where direct addressing of that data space is desirable, if not necessary. It won't be UNIX, of course. (b) In any case, there are several address widths between 24 and 32. What if I need 17 megabytes of virtual space? I just saw a thing go by on unix-wizards that talked about running 60 MB processes - that takes 26 bits. -- Geoff Kuenning Unix Consultant ...!ihnp4!trwrb!desint!geoff
chuqui@nsc.UUCP (The Phantom) (02/25/85)
In article <730@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >But 24 bits of address is not a huge thing, which is what the 32032 has. >24 bits is only 16 Mb or 4 4 Mb memory cards. Only 4 4Mb cards? Sigh-- Just think of the vast numbers of Vaxes running 16 megabytes right now. Just thihk of the size of the 4 Mb cards in your 16Mb Vax Last I looked, 16Mb was a LOT of memory, and from a cost/manufacturing point of view, probably more than a 32000 based (or 68K system) will run until memory costs drop and density increases. We DO have 32bit addressing silicon on the boards and on its way to reality, and I expect it will be a purchasable commodity long before the megabit chips that will be neccessary to make those kind of address spaces truly useful. 32bit addressing makes a nice marketing tool, granted, but there really isn't much that a 32bit address gives you that a 24bit address doesn't also give you in a manufactured product EXCEPT a marketing tool. chuq -- From behind the eight ball: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA We'll be recording at the Paradise Friday night. Live, on the Death label.
kurt@fluke.UUCP (Kurt Guntheroth) (02/25/85)
I wonder just how limiting a 24 bit address space is anyway. Our vaxes got
along quite well with 2 Mb running 4.1 Although they have more now we are
running 4.2, it is only 3 or 4 Mb. 16 Mb seems like quite a lot of memory.
Now I don't want to get labelled as a person who cannot see the future (why
go to CRT's when punch cards work so well, etc.) but I don't see any strong
need for more than about 4-8 Mb in the near future. I also believe that the
current generation of processors will probably run out of steam compared to
whatever is under development before they exhaust their address space.
If there is somebody who plans now to use more than 24 bits of contiguous
RAM addresses, I'd be interested to hear his story.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtelwell@osu-eddie.UUCP (Clayton M. Elwell) (02/26/85)
A 32-bit address bus is useful even if you don't have 4Gb of physical memory. I can think of several programs I have written that while running have a virtual image greater than 16Mb. It's much nicer to work in a big virtual address space and let the OS worry about the physical memory. In case you're curious, one of the above-mentioned programs was a ray tracing package, and one was, of all things, a model of Usenet a couple of years ago. Each of these ran much faster and were much easier to write than if I had done swapping, etc. myself, and added another layer of overhead. Compilers and OS's are one thing, but there are large applications out here as well. -- Clayton Elwell Ohio State University elwell@ohio-state.CSNET elwell%ohio-state@CSNET-RELAY.ARPA ...!cbosgd!osu-eddie!elwell
david@daisy.UUCP (David Schachter) (02/26/85)
I agree with Mr. Von Rospach. 16 MB is quite a lot of memory. At Daisy
Systems, we get excellent results with a mere 4 MB on our Intel 80286-based
systems. We have put 16 MB (15 3/4, actually) on several internal test
stations, to see what happens, and the systems work happily away. To my know-
ledge, none of our customers has had need for more than 4 MB. By late 1987, I
expect they will find 16 MB limiting. But by then, Mr. Von Rospach's company
will have the 32-bit version of the NS32000 family; Motorola will, quite
possibly, be shipping the MC68020 with the real MMU; and Intel will be
shipping the 80386, its "big-boy" version of the 4004. (A spot of humor
there.) The 24 bit address bus of the NS32032 is not a problem. The
data bus, the internal register width, and the ALU width are more important
measures, currently.
[The above does not necessarily represent the views or policy of Daisy Systems
Corporation. The opinions expressed above are soley those of the author who
takes full responsibility for them. The author has a mental age equal to his
interpupillary distance measured in milli-furlongs.] {Too much of a good thing
can be wonderful. -- Mae West}yamauchi@fortune.UUCP (Alan Yamauchi) (02/26/85)
In article <2393@nsc.UUCP> chuqui@nsc.UUCP (The Phantom) writes: >In article <730@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >>But 24 bits of address is not a huge thing, which is what the 32032 has. >>24 bits is only 16 Mb or 4 4 Mb memory cards. > >Only 4 4Mb cards? Sigh-- Just think of the vast numbers of Vaxes running 16 >megabytes right now. Just thihk of the size of the 4 Mb cards in your 16Mb >Vax. ... Now wait a second here. This is not a realistic comparison. These cards use 64k DRAMs and you're right it does take up quite a bit of board space. Being from NSC, you should realize that there are such things as 256k DRAMs, even if none of the US semi houses are in full scale production. Okay, so it still takes a lot of them to make up 4 Meg, but with current packaging technology board space can be minimized to at most the size of a 1 Meg 256k DRAM card, which uses DIP packaging. Take for example the memory cards used in the ATT 3b series of micros, which use PLCC 256k DRAMs mounted on a substrate ( SIPs to be more specific ). >... 32bit addressing makes a nice marketing tool, granted, >but there really isn't much that a 32bit address gives you that >a 24bit address doesn't also give you in a manufactured product >EXCEPT a marketing tool. Sounds like "sour grapes" to me. I have to agree with Phil, 24 bits of address space just isn't enough given current semiconductor technology and system architecture. New micro designs will be taking advantage of 256k DRAMs, single/multi chip state of the art CPUs,... and you can bet many of them will be allowing for a 16 Mbyte main memory. Someone is sure to design a 16 Mbyte desktop VAX equivalent and where does that leave the 32032? By the time NSC gets a 32032 out with a 32 bit address space, someone elses CPU chip will be designed in, already prototyped and tested, and possibly they'll be shipping product by the time your chip hits full production. \ / Alan Yamauchi * \___/ UUCP: {ihnp4,ucbvax!amd,hpda,sri-unix,harpo}!fortune!yamauchi DDD: (415)594-2436 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065
chuqui@nsc.UUCP (The Phantom) (02/26/85)
In article <344@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >(a) 32 bits is a bit less than five Eagles worth of byte-addressed data. I > can easily concoct a microprocessor application where direct addressing > of that data space is desirable, if not necessary. It won't be UNIX, of > course. >(b) In any case, there are several address widths between 24 and 32. What if > I need 17 megabytes of virtual space? I just saw a thing go by on > unix-wizards that talked about running 60 MB processes - that takes 26 > bits. I think we're dropping down into nit-picking. I can easily come up with microproccessor applications where the 1802 is better than the 68020, where the 8088 is better than the 6502, where the Vax is better than an electric toaster. It is easy to come up with a refutation for any hardware setup. The reality of the situation is that it is hard to cost justify a system of the power of a 32xxx with more than about 4megabytes of memory, simply because the memory takes up board space, eats power, generates heat, and generally costs a lot. Until the 256K chips come down in price to something reasonable, megabyte memory boards are about the limit you'll see on most systems, and you won't see more than a couple. When megabit chips show up, you'll start seeing larger memory spaces available. The only systems today that cost justify more than about 2 to three megabytes of memory are in the 100K and up cost (say, a Vax) and there are few running more than about 8 Megabytes of memory at all (a few vaxen and the mainframes). The 32032 has a full 32 bit data path. All internal paths are 32 bit. The addressing is 24 bit, but it is handled as a 32 bit path internally so there won't be any suprises in the software moving up to a full 32 bit address path when it shows up, and it is on the drawing boards. The point is, in the markets the 32000 series stuff is aimed at, the only real advantage going to a 32 bit address path now would give us would be marketing. The disadvantages include a larger package with more pins, a more expensive part, using more board space, controlling logic, and power, and increasing manufacturing costs both at the chip and the board level. We'll have the addressing when we need it, but we don't really need it now. sigh. Haven't we beaten this into the ground? Anyone got a new topic they want to discuss? chuq von rospach national semiconductor, santa clara (408) 733-2600 X242 -- From behind the eight ball: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA We'll be recording at the Paradise Friday night. Live, on the Death label.
jmoore@fred.UUCP (Jim Moore) (02/27/85)
> ......... 32bit addressing makes a > nice marketing tool, granted, but there really isn't much that a 32bit > address gives you that a 24bit address doesn't also give you in a > manufactured product EXCEPT a marketing tool. > > chuq But addressing is not just for physical memory. Hardware people love extra address lines for memory-mapped IO. The software folks can avoid complex allocation algorithms by taking advantage of large virtual address spaces. Both are legitiment uses for more address lines. I am not saying that 24 bits is scimpy (sure beats 16), but there are current micro-based designs that can certainly benefit from the additional address lines above 24. Jim Moore Integrated Solutions Inc., Boulder Colorado {ucbvax|hao|amd}!nbires!jmoore
kds@intelca.UUCP (Ken Shoemaker) (02/27/85)
> In article <730@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > >But 24 bits of address is not a huge thing, which is what the 32032 has. > >24 bits is only 16 Mb or 4 4 Mb memory cards. > > Only 4 4Mb cards? Sigh-- Just think of the vast numbers of Vaxes running 16 > megabytes right now. Just thihk of the size of the 4 Mb cards in your 16Mb > Vax Last I looked, 16Mb was a LOT of memory, and from a cost/manufacturing oh well, only 16MBytes? Another point is that since the address qualification is done outside the chip, that corresponds to a 16MByte virtual space, also, regardless of the amount of physical memory you have. However, saying that the 32032 isn't a "true" 32-bit processor by virtue of its 24 of physical address pins is perhaps pressing it a bit. -- It looks so easy, but looks sometimes deceive... Ken Shoemaker, Intel, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,omovax}!intelca!kds ---the above views are personal. They may not represent those of Intel.
phil@amdcad.UUCP (Phil Ngai) (02/27/85)
This message is empty.
doug@terak.UUCP (Doug Pardee) (02/27/85)
> (a) 32 bits is a bit less than five Eagles worth of byte-addressed data. I > can easily concoct a microprocessor application where direct addressing > of that data space is desirable, if not necessary. A *microprocessor* application???? Come on now, let's get serious. I _might_ grant that for an AI application you would need that kind of high-speed random-access memory, but no sane person would *ever* choose a 68xxx/32xxx type processor for AI. You need a *lot* more MIPS than that. Let's see, using 256K DRAMs at $15 each, the cost of the RAM chips alone for each megabyte is $540. This presumes that you have parity on each byte (you do understand that in a system with more than 16 Mb of DRAM that you simply *must* have parity checking to detect soft errors from alpha particles, and that error-correcting would be highly desirable?). So your first 16 Mb is gonna cost you $8640 in DRAM chips alone, and you're concerned that you want significantly more than that. So you're gonna spend maybe 20 G's or more on a memory system, and to "cut costs" you're gonna use an off-the-shelf microprocessor like a 68020 or 32032? Gimme a break! If _you_ really want to do that, fine. But don't feel hurt if Nat'l, Motorola, et al don't rush right out and spend tens of millions of bucks designing a microprocessor chip just for you! -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug
eve@ssc-bee.UUCP (Michael Eve) (02/28/85)
Regarding how much memory is enough, consider a cpu sharing ram with a video coprocessor. Let each video frame consist of 1000x1000 pixels with 3 color planes for each pixel. Each color plane consists of 1 byte. This gives you 3 Mb per frame! At this rate, you can use memory pretty fast. I think such resolution is a realistic expectation in the near future (10 years). Whether any existing integrated processor can update the frames fast enough for useful video is another question. -- Mike Eve Boeing Aerospace, Seattle ...uw-beaver!ssc-vax!ssc-bee!eve
phil@amdcad.UUCP (Phil Ngai) (03/01/85)
> Now I don't want to get labelled as a person who cannot see the future (why > go to CRT's when punch cards work so well, etc.) but I don't see any strong > need for more than about 4-8 Mb in the near future. I also believe that the Need is only part of it. Affordability is also important. As 256Kb RAMs and 1Mb RAMs go down in price, you will see more and more 16 Mbyte and bigger systems. You don't think people will drop in 16 1Mb chips and say "I'm happy with 2 Mbytes", do you? Nah, they'll put in 64 or 128. People buy as much memory as they can afford. Then they figure out what to do with it. -- Why, that's more useless than the left thumb of a touch typist! Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
phil@osiris.UUCP (Philip Kos) (03/01/85)
> .... These cards use > 64k DRAMs and you're right it does take up quite a bit of board space.... And to think that when I started reading BYTE magazine, back in 1977, there were several companies selling 4K (!) memory boards for IMSAIs and ALTAIRs, and one company even had an "Elephant" S-100 memory board expandable to (gasp) 32K... Advances in IC technology sure can make a guy feel old. :-) Phil Kos Johns Hopkins Hospital
jeff@alberta.UUCP (C. J. Sampson) (03/03/85)
In article <298@ssc-bee.UUCP> eve@ssc-bee.UUCP (Michael Eve) writes: > > Regarding how much memory is enough, consider a cpu sharing > ram with a video coprocessor. Let each video frame consist of > 1000x1000 pixels with 3 color planes for each pixel. Each color > plane consists of 1 byte. This gives you 3 Mb per frame! At this > rate, you can use memory pretty fast. I think such resolution is > a realistic expectation in the near future (10 years). Whether > any existing integrated processor can update the frames fast > enough for useful video is another question. > This sounds great. However, consider the fact that it takes five to twenty hours to generate each picture of this resoloution on a VAX 11/780 that has no other processes running. Now, who is going to be dumb enough to use a 32032 to do something like this? If it's the occasional frame once a month, I can see it. But nobody's going to do a large number of frames like this on a regualar basis. Keep in mind that the 32032 is a MICROprocesser. It's not made for huge jobs. However, if you insist on doing fifty or sixty frames, I'm sure that the time it takes to dump a frame to disk (a few seconds, at most) will be negligible compared to the CPU time (measured in *days*) that it will take to generate the image. ===================================================================== Curt Sampson ihnp4!alberta!jeff --------------------------------------------------------------------- "It looked like something resembling white marble, which was probably what is was: something resembling white marble."
jeff@alberta.UUCP (C. J. Sampson) (03/04/85)
In article <103@fred.UUCP> jmoore@fred.UUCP (Jim Moore) writes: >But addressing is not just for physical memory. Hardware people love >extra address lines for memory-mapped IO. Oh, sure. Let's add an extra address line for the I/O. We really need over sixteen million I/O ports... Let's be reasonable here. For a single or small multi-user ( < 10 users) system, you don't really need piles and piles of memory. If you have an application that needs more than 16 megabytes of memory, you probably don't have the processing power to run it in any reasonable time, anyway. Can we get off this argument now? If 16 megabytes isn't enough for you, simply shut up and go buy a Cray. ===================================================================== Curt Sampson ihnp4!alberta!jeff --------------------------------------------------------------------- "It looked like something resembling white marble, which was probably what is was: something resembling white marble."
doug@terak.UUCP (Doug Pardee) (03/04/85)
Just being picky: > Someone is sure to design a 16 Mbyte > desktop VAX equivalent and where does that leave the 32032? Seems to me the 32032 can already address 16Mbytes. And with the 32082 MMU, it can address 32Mbytes real, 16Mbytes virtual. -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug
shebs@utah-cs.UUCP (Stanley Shebs) (03/04/85)
In article <400@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: > >A *microprocessor* application???? Come on now, let's get serious. >I _might_ grant that for an AI application you would need that kind >of high-speed random-access memory, but no sane person would *ever* >choose a 68xxx/32xxx type processor for AI. You need a *lot* more >MIPS than that. An HP9836 (a vanilla 68000 machine) running Portable Standard Lisp outperforms a Symbolics and a 780 on some several of the AI-oriented Gabriel benchmarks (theorem-provers, game players, and other things). The key factor seems to be that the 9836s have *no* virtual memory, using about 5-10 Mb of real memory instead. Reduces garbage collection time and also thrashing due to Lisp's generally random addressing behavior... stan shebs PS I do have some ideas for AI applications to run on a Cray, but Cray PSL isn't finished yet!
brooks@lll-crg.ARPA (Eugene D. Brooks III) (03/06/85)
> In article <103@fred.UUCP> jmoore@fred.UUCP (Jim Moore) writes: > >But addressing is not just for physical memory. Hardware people love > >extra address lines for memory-mapped IO. > > Oh, sure. Let's add an extra address line for the I/O. We really need > over sixteen million I/O ports... > Let's be reasonable here. For a single or small multi-user ( < 10 users) > system, you don't really need piles and piles of memory. If you have an > application that needs more than 16 megabytes of memory, you probably don't > have the processing power to run it in any reasonable time, anyway. Can > we get off this argument now? If 16 megabytes isn't enough for you, simply > shut up and go buy a Cray. > > ===================================================================== > Curt Sampson ihnp4!alberta!jeff > --------------------------------------------------------------------- > "It looked like something resembling white marble, which was probably > what is was: something resembling white marble." If it looks like a TURKEY, walks like a TURKEY and gobbles like a TURKEY then it must be a TURKEY!
jack@boring.UUCP (03/06/85)
>People buy as much memory as they can afford. Then they figure out what >to do with it. Nono. *UCB* buys as much memory as they can afford, then make sure that 4.7BSD uses 80% of it, and then starts distributing that:-) -- Jack Jansen, {decvax|philabs|seismo}!mcvax!jack Notice new, improved, faster address ^^^^^
davet@oakhill.UUCP (Dave Trissel) (03/07/85)
> This sounds great. However, consider the fact that it takes five to twenty >hours to generate each picture of this resoloution on a VAX 11/780 that has >no other processes running. Now, who is going to be dumb enough to use a >32032 to do something like this? If it's the occasional frame once a month, >I can see it. But nobody's going to do a large number of frames like this on >a regualar basis. Keep in mind that the 32032 is a MICROprocesser. It's not >made for huge jobs. ... > Curt Sampson ihnp4!alberta!jeff Hmmm. I detect some minicomputer elitism here. Just for arguments sake lets say the NS32032 is only one-fourth the power of a 780 VAX. (In reality I'm sure its greater than that for non-floating-point tasks.) Now, if you had a room with four NS32032 systems processing video frames how much would these systems cost versus a room with one 780 VAX? I think its obvious that the micros would win here. [And since I happen to work at Motorola ;-) ] It appears that the MC68020 in a "realistic" system (i.e. memory management and cache) runs at 780 speeds or better for non-floating-point problems such as this one. Now I am not going to project what the costs of '020 systems will be but you can bet your bottom dollar they will not come anywhere near the cost of a VAX 780. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!davet
jss@sjuvax.UUCP (J. Shapiro) (03/08/85)
Curt Sampson ihnp4!alberta!jeff writes:
-----------------------------------------------------------------------------
This sounds great. However, consider the fact that it takes five to twenty
hours to generate each picture of this resoloution on a VAX 11/780 that has
no other processes running. Now, who is going to be dumb enough to use a
32032 to do something like this?
-----------------------------------------------------------------------------
1) The VAX memory access speed relies on write back cache - the bus cycles
are 400 ns. With a 10 Mhz 32032 *or* 32016 one can get real memory
response times of 200ns. This saves time.
2) it is not clear that the 32016 doesn't compare to a VAX. With the right
kind of paging algorithms and hardware, one might very well outperform an
11/750 WITH FPA. I haven't tried it, but it looks possible.
3) now that I have finally got my hands on Rev N chips I can go build one
;-)))) <- note new convention - insipid grin.
On a serious note, it seems clear to me that things like picture processing
require dedicated hardware to do well *anywhere.* One might get fine
performance out of something like the NCR/32 by microcoding dedicated
instructions, but I am a firm believer in overpowering hardware - no one is
forcing anyone to use that power.
The question is this: Has anyone on the net come up with an application
suitable for microprocessors that the 32016 can't handle when fully
debugged? Lots of people have come up with the exceptional cases, and I
personally would love to see 32 bits of address, but it seems to me that
the 32016 as is will satisfy the bulk of the demands which will be made of
microcomputers in the next decade.
Besides, if you are doing picture processing in a real way, money can't be
an issue.
Jon Shapirogeoff@desint.UUCP (Geoff Kuenning) (03/09/85)
In article <400@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: >> (a) 32 bits is a bit less than five Eagles worth of byte-addressed data. I >> can easily concoct a microprocessor application where direct addressing >> of that data space is desirable, if not necessary. > >A *microprocessor* application???? Come on now, let's get serious. >I _might_ grant that for an AI application you would need that kind >of high-speed random-access memory, but no sane person would *ever* >choose a 68xxx/32xxx type processor for AI. You need a *lot* more >MIPS than that. > >Let's see, using 256K DRAMs at $15 each, the cost of the RAM chips >alone... [there follows a complicated analysis of costs that concludes one would have to expend $20 billion on RAM chips to get 4 Gbytes] >So you're gonna spend maybe 20 G's or more on a memory system, and >to "cut costs" you're gonna use an off-the-shelf microprocessor like >a 68020 or 32032? Gimme a break! Give me a break yourself. The part you quoted *explicitly* mentions the Fujitsu Eagle, which is a disk drive. Like I said before, I can easily concoct a MICROPROCESSOR application that needs to address 32 bits worth of MASS-STORAGE-RESIDENT data. Surprise, surprise, it isn't going to be a CPU-bound application. It's going to be some sort of database-intensive application. It is true that there are other ways to handle disk-resident databases (or other media; trillion-bit memories on obscure slow media date back to the late 60's) than as virtual memories. Having done so, I can testify that you will *always* wind up writing code that, in effect, simulates the virtual memory hardware in software. Sometimes you are lucky and you can hide it pretty well. But sometimes you have truly random reference patterns that really do exhibit locality in short time spans, and then you have to do it in software. I know; I've done it in software myself on more than one occasion. No thanks. I might add that, even in a system that does not have virtual memory, a wide address/data path makes writing software-virtual code much easier. National got this part right, at least. The funny thing is that you hear pretty much the same noises from Intel as from National -- just replace all occurrences of "24" by "16". -- Geoff Kuenning Unix Consultant (213) 545-4413 ...!ihnp4!trwrb!desint!geoff
david@daisy.UUCP (David Schachter) (03/10/85)
Mr. Trissel points out that Motorola's benchmarks show the 68020 to have equal or better performance than the (how old?) VAX 11/780. Gee, I wonder how the microvax II will perform? Last rumors I heard were that DEC is projecting better performance for the II than for the venerable 780. And to think I'm about to shell out a thousand dollars for a PDP-8m with 8 kW of core (real core), two DECTAPE drives, a 300 cpm card reader, and two LA-36s. Hmmm...
henry@utzoo.UUCP (Henry Spencer) (03/11/85)
> ... Now I am not > going to project what the costs of '020 systems will be but you can bet your > bottom dollar they will not come anywhere near the cost of a VAX 780. This is actually a slightly-unfair comparison, since the VAX line is notoriously overpriced for the computing power it provides. Still, the man's got a point there. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
brooks@lll-crg.ARPA (Eugene D. Brooks III) (03/16/85)
> out well ahead. You can build a 10+ MIPS bit-slice engine for about > the same cost as a single 32032-based engine. It'll be harder to > program than a single-32032 system, but I'd guess that it wouldn't > be any harder than programming your 12-CPU system. Besides, we were > talking raw CPU cycles versus price. > -- > Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug In any discussion about cost of a computer system the programmer cost, the BIGGEST cost, can't be ignored. You take your slicer and I'll take the 12 cpu 32032 system, for which I already have parallel programs ready to go, and we will see whos work gets done first! No more mister nice guy!
henry@utzoo.UUCP (Henry Spencer) (03/27/85)
> ... You take your slicer and I'll take > the 12 cpu 32032 system, for which I already have parallel programs ready > to go, and we will see whos work gets done first! This could be an interesting battle, considering that interrupts and DMA -- the sort of thing that gets a lot of work in a multiprocessor system -- were and are major trouble spots in the not-yet-fully-debugged 32032 processor chip. He may well have the results from his slicer by the time you get your hardware MTBF up to where you can run on it... :-) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry