On Thu, 6 Jan 2000, David Schwartz wrote:
>
> > > You are making his point, not refuting it. All these
> > > things have moved to
> > > 32-bits where they would previously have been done with 8-bit
> > > or 16-bit
> > > processors. They will likewise move to 64-bits.
> > >
> >
> > you are missing the point.
>
> No, you are missing my point.
>
> > as stated before: embedded systems use the smallest, most efficient, most
> > inexpensive chip that is up to the job.
>
> I realize that this is common sense, but it's just not true. The defintion
> of "the job" is depedent upon what chips are available. When the scope of
> the embedded system is defined, it's based upon the current level of
> technology.
>
> Why did the Hubble, and embedded system, just get upgraded to a 486-50?
> Obviously the system that was there before did the job, right?
>
> No, what happened was the availability of more powerful embedded processors
> changed the _scope_ of what the job was. This is what has _always_ happened.
>
> And the amazing thing is that the fast chip will be less expensive. The
> reason is simple -- the only significant difference in price between a chip
> one generation back and a chip three generations back would be due to a
> difference in pin count. And the chip one generation back will be suitable
> for more tasks than the one three generations back. This higher volume will
> often result in _lower_ cost.
>
> In fact, it's hard to find non-specialized '286s in wide distribution now.
> This is for an obvious reason -- it doesn't cost that much more to make a
> '486, and the potential market is larger.
>
> > 8bit chips are still used all over the place. And even in 38 years time,
> > there will be plenty of tasks that can be done with a 32bit chip and a
> > lightweight unix-like OS.
>
> Yes, but you will find that they won't be.
>
> > Why would you use a 64 bit chip if a 32bit would do the job?
> >
> > The 64 bit chip is bigger, so your device has to be bigger.
>
> Why is that? The 64-bit chip can have an 8-bit external bus. And the 64-bit
> will be made with leading edge technology, producing smaller dies.
>
> > It will need a lot more power, so your device has to be bigger, needs more
> > expensive batteries, needs (a larger quantity of) and/or (more expensive)
> > ancillary components.. etc..
>
> Not so. The 64-bit chip can run with a lower clock rate and still get the
> same amount of work done, reducing EMI. Why will it need more or more
> exensive ancillary compents? No law says the external bus implementation has
> to be 64-bits.
>
> > And finally, the 64 bit chip will itself cost a lot more than the 32 bit
> > one.
>
> Bull. The volume of the 64-bit chip will be much higher since it can do a
> larger range of tasks. This volume increase may actually result in the
> 64-bit chip being cheaper.
>
> > It's extra cost on top of extra cost on top of extra cost.
>
> I don't believe it. Let me put it this way -- what's the current cost
> difference between a '286 desktop and a '486 desktop? One is 16-bit, the
> other is 32-bit. It's zero, basically. Why is that? Doesn't the '486 need a
> more expensive bus architecture? Doesn't it need a more expensive processor?
>
> > Granted there will be plenty of uses for 64bit chips in the future, but
> > there will also be plenty of tasks suitable for 32bit chips...
>
> Sure, but those tasks will be done by 64-bit chips even though they're
> suitable for 32-bit chips. Everything will. It's the same reason I'm using a
> P3-500 to write this email even though a '386 would suffice for the task. We
> redefine the tasks to fit the available hardware.
>
Predicting the hardware environment of 2038 is rather silly.
38 years ago, we were still using magnetic core memory, the few hard disks
around had a couple of megabytes at most and cost a couple hundred
thousand dollars, COBOL and Fortan were just a few years old. The most
powerful computers were .1 MIPS or so. A lot of processing was still done
on punch card hardware.
Direct projection probably doesn't work because atomic quantum limitations
are on the horizon. But the 32/64 distinction will be history long since.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:07 EST