🚀 go-pugleaf

> 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.

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.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

In article <794@sjuvax.UUCP> jss@sjuvax.UUCP (J. Shapiro) writes:
>
>	You see, I finally got a hold of samples from National - or more
>accurately, from Omega, their local tech company.  These parts came without
>the promised bug lists, were not current revisions, and were not the
>requested speeds.
>
>Each sample they order comes back rev K, and I have been told rev N is the
>thing to wait for. I have also been told that rev N is available... I will
>believe it when I hold the silicon in my hot little hands.
>
>	Perhaps some kind soul at Motorola might tell me who to get in touch
>with (and telno) for the manuals for the 68020 and 68881.

Jonathan, I am truly sorry that you've been jerked around so much, but the
truth remains that, though supplies are short, many rev N 32016s have been
shipped.  Of course, they have been shipped first to customers who have
been working with the Series 32000 for years and who have production sockets
they desperately need to fill.  Surely this is neither uncommon nor 
unreasonable, but I can well understand how frustrating it is to smaller
customers.

Having waited this long, you can, I hope, wait for our production to ramp
up to the point that your local distributor will be stocking the parts
you want.  Meanwhile, *do* read the 68020 manual.  It's extremely informative,
especially when you read between the lines.  I'm sure oakhill!davet will
be happy to send you one.
-- 
Richard Mateosian
{allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm    nsc!srm@decwrl.ARPA

The response you get seems to vary with who you deal with. I was
involved in a project using the 32016 in the UK.  We found that
you got by far the best response from dealing with Nat Semi direct.
They were always very helpful and provided us with samples and
buglists.

Obviously Nat Semi would rather you went through their distributors
but these have a vested interest in moving old stock, or just are
not as knowledgable. We repeatedly asked for G mask and got F mask
chips ( it was that long ago! ). Approaching Nat Semi direct solved
this. Distributors in the USA may be more knowledgable.

	sean

	sjl@ukc.UUCP
	..!mcvax!ukc!sjl

> 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.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,linus,decvax}!utzoo!henry

Of \course/ there's a 68020 bug list, the chip isn't even into
production release yet!  They're still sending out evaluation
samples.  You expected maybe the chip would be perfect the first
time?  Give me a break!  The 68020 has only been sampling for a
few months, how long has the 32016 (aka 16032) been out?

					Bill Shannon

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

[Aren't you hungry...?]

	I am sorry to see that Richard Mateosian, though kind in intention,
missed my point.  I can understand that the newer revisions might go to
companies with a history with National - someday I will appreciate the same
treatment (if I stick with the parts that long).  This attitude I fully
agree with, though the precedence system should damn well be explained to
the people who will be on the short end of it (as well as those for whom it
is positive).  

	Far more important is the fact that the chips were:

	a)	Not up to speed.  I have heard many things about the recent push to
get 10 Mhz Rev N parts out.  Given that, it seems absurd that I can't even
get an 8 Mhz Rev K part.

	b) FAR MORE IMPORTANT, having the piece of silicon, I can't even build
an automated toilet flusher for lack of a bug list.  This is inexcusable.
Mr. Mateosian and I have discussed in private the deplorable nature of 
National's local tech support people.  He suggested talking to pioneer,
which I did.  The problem there is that they have to deal with the same
damn bumbling incompetence that I do.

<FLAME OFF>

I am sorry, ladies and gentlemen, but it is terribly frustrating and I am
sick and tired of being patient while losing out to competitors because
some ass somewhere in the chain of command can't get his shit together.
As I said in my first posting, I am *GLAD* I do not have a large amount of
money committed to National. If things do not improve quickly I will seek
to make that commitment less than it is.

	More unfortunate is the fact that I personally feel National's
architecture to be better than Motorolla's (matter of opinion - no flames
please). Perhaps National has a spot for a marketing VP??? I would be happy
to take on the job for a few years. At least then I would get buglists and
many of you wouldn't be going bankrupt.

Jon Shapiro
Haverford College

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

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

Bugs are legendary in the micro business.  How many people remember
bugs like the 6800 not being able to do certain instructions if the
parity (parity for god's sake) of the preceeding instruction was odd.
The 6502 doing strange memory accesses during certain instructions.
The iAPX 188 bugs that prevented the 8087 from working with it (which
was fixed I believe).  The list is endless.  Needless to say, all
processors have bugs the manufacturers consider too inconsequential to
repair.  The bug list usually finds its way out by word of mouth and
many designers just remember the bugs and design around them.  There was a
disgusting and extensive list of 68000 bugs circulated around this newsgroup
last year that had been found by designers, not reported by Motorola, I
believe.

(flame warning)

There is no point in complaining if you can't get a sample part in
full speed with no bugs.  The 32000 is new enough, and production is low
enough, and demand is high enough, that NSC doesn't find it in their best
interest to give you one.  I'd do the same if I was them.  They know the
bugs aren't very serious, and if you find one you will probably be able to
work around it.  They know you can check out your design with a slower
part.  By the time you go into production there will be faster parts with
fewer bugs.  (You are going to make more than one of whatever-it-is aren't
you?)  Why don't you try to use the part you have and post the results of
your attempt.  I am sure we would all be glad to see how serious the bugs
you encountered were.  More interested than we are in your complaint.

PS: My National Rep didn't have any trouble coming up with a bug list.
    That was a year ago so it probably isn't interesting now.  I am not
    connected in any way with National Semiconductor, except as a fan
    of the 32000.
-- 
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt

I've been doing some checking around, and we are trying to make sure that
the updated information gets to the interested parties. Solves this case,
mostly, but in some ways it doesn't solve the problem.

A good part of the problem is simply that a distributor like Omega works on
commission and doesn't have the time or resources to really deal with very
low volume accounts such as teachers and grad students (three sets of
chips, a set of manuals, and you never hear from them again). It tends to
get very expensive for them to do this handholding, so they try to minimize
it, justifiably so. But we don't want to cut the schools out from our
product, so what we've done here at National is set up a University support
program to help get the information and materials needed out to the people
in the school. If you're working with National parts, and are having
trouble getting the information you need, drop me a line and I'll do what I
can do get you hooked into the program. 

chuq
-- 
From left field, near the warning track:          Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc!chuqui@decwrl.ARPA

Even though a poem be a thousand words, but made up of senseless words, one word
of a poem is better, which if a man hears, he becomes quiet. --The Dhammapada

In article <338@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes:
>I just can't see letting someone badmouth the excellent work
>the '020 team has been doing here at Motorola.
>
I've taken a couple good-natured jabs at Motorola from time to time in
this space, but since you can't always see the smile on my face or hear the
tone of my voice, let me say someting just for the record. (Watch closely,
Dave.  I'm only going to do this once.)

Motorola has a fine company with many fine products, including the 68000
family.  They have a right to be proud of their products and the fine
engineering work behind them.  At National, we have fine products, excellent
engineering, and a great deal of pride as well.

I know a lot of people at Motorola.  We've been on many technical panels and 
in standardization efforts together.  We visit each other's booths at shows.
I've always enjoyed working with them.

In all of these situations, there has always been a little friendly sparring,
and it will probably continue to be that way.  There seems to be something
about the net, however, that exaggerates negative communication, so I for
one have decided to refrain from taking any more jabs, however good-natured,
at anyone in this medium.

-- 
Richard Mateosian
{allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm    nsc!srm@decwrl.ARPA

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

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

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

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.}

> Of \course/ there's a 68020 bug list, the chip isn't even into
> production release yet!  They're still sending out evaluation
> samples.  You expected maybe the chip would be perfect the first
> time?  Give me a break!  The 68020 has only been sampling for a
> few months, how long has the 32016 (aka 16032) been out?

Bill, you have my complaint precisely backwards.  Of course there's
a bug list.  But for a while, trying to get Motorola to *admit* it
was a little difficult...  They were quite definitely trying to give
the impression that the chips were perfect on the first shot.  Ho ho.

By contrast, National has been very cooperative about supplying bug
lists.  It's the content of said lists that I could live without...
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

> 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

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.

> >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

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

> (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

	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

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."

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!

> 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.

Not "another" question.  "THE" question.  Nobody designing such a
system is going to choose a 32000 or 68000 to drive it, because it
would be so *slowwwww* as to be laughable.

Which illustrates the central point here:

The "large memory" applications are totally different from "single-chip
CPU" applications, so why on earth should the single-chip CPUs have to
support such huge memories?

Now some minor points...

1)  I don't see how a video memory that takes 3 Mbytes shows that CPUs
that address "only" 16 Mbytes would be inadequate.

2)  It seems to me that when your application shows up in 10 years that
the 32000 and 68000 will be as obsolete as the 8008 is today, so there's
no point in worrying about whether they'd be able to do the job.
-- 
Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug

>  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

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 Shapiro

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

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...

> ...  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

> 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!

> ... 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