Re: What does '64 bit' mean? Lame question, but hear me out :)
From: Robert Myers (rmyers1400_at_comcast.net)
Date: 02/02/05
- Next message: Willy Denoyette [MVP]: "Re: Passing structures between C# and C?"
- Previous message: Cor Ligthert: "Re: Binding DataGrid"
- Maybe in reply to: Peter Wone: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Next in thread: assaarpa: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Reply: assaarpa: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 02 Feb 2005 11:11:36 -0500
On Fri, 28 Jan 2005 21:26:18 -0500, keith <krw@att.bizzzz> wrote:
>On Tue, 25 Jan 2005 08:20:28 -0500, Robert Myers wrote:
>
<snip>
>>
>> Microcode makes the machine state independent of the physical
>> hardware? Nah.
>
>That depends on your view of the "soul of the machine". To me, a hardware
>type, this is indirection at least, and thus virtualization of the
>hardware. To a soft-weenie, the ISA (indeed the language) is king, so
>perhaps you have a different opinion. ;-)
>
The difference in viewpoint is important, and I have a hard time
adopting your point of view. Hardware decisions are hard-coded. If
no user with any level of privilege can see the virtualization or
manipulate it, it might as well not exist. I'd be just as concerned
about the details of circuitry. It might be interesting to talk
about, but, like the weather, there wouldn't be much that I, or any
user, with or without screwdriver, could do about it. In the end,
though, an argument about language is just that--an argument about
language.
<snip>
.
>>
>> I expect the entire programming model to change. Stream processors,
>> GPU's, network processors, packet processors in the place of
>> conventional microprocessors.
>
>You love them "stream processors"!
Well, yes I do. I like paradigm shifts.
The history of computing is thickly sown with competing realities.
One reality is that every idea that could be thought of was thought of
in the first two decades if not the first decade of automatic
computation.
The other, apparently contradictory, reality is that nothing is
forever, including something so basic as the register and execution
unit model of computation.
The idea of having some central unit fetching instructions and data
and operating upon them is so etched into the minds of the community
that it is hard to visualize a future in which that is not the
dominant reality, but it is coming. The new reality will be that
packet processors operate upon packets and send them along. Already
there, of course, in terms of some network processing.
A packet processor can be stateless. Then you just need to be able to
intercept packets to introduce any level of indirection you care to.
Firewalls like IPTABLES, which can also be the soul of a router,
already do that.
>You really ought to get into
>programming DSPs, though that would take you into the world of real
>problems. ;-)
I should probably take a harder look at what _is_ going on with DSP
right now. Thanks for the suggestion. ;-).
>> x86, s/360 forever? Of course. That huge pile of software would cost
>> alot of money to recreate. It may not even be possible without causing
>> the world economy to collapse.
>
>Exactly the point I've been making here for *years*. I learned this
>lesson 30 years ago with FS. I wonder if Intel has learned this
>lesson yet! Good ideas are quite often found to be not so wonderful.
Oh, believe me Intel has taken the idea to heart. Their goal is to
get software written to a proprietary ISA. They _they_ will own a
piece of the world economy forever.
RM
- Next message: Willy Denoyette [MVP]: "Re: Passing structures between C# and C?"
- Previous message: Cor Ligthert: "Re: Binding DataGrid"
- Maybe in reply to: Peter Wone: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Next in thread: assaarpa: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Reply: assaarpa: "Re: What does '64 bit' mean? Lame question, but hear me out :)"
- Messages sorted by: [ date ] [ thread ]