Re: [OT] Re: What's the name for this?
From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 04/22/04
- Next message: Corey Murtagh: "Re: Java2 - jpeg has poor quality when written back to disk"
- Previous message: gswork: "Re: ASM Assembler"
- In reply to: Corey Murtagh: "Re: [OT] Re: What's the name for this?"
- Next in thread: gswork: "Re: [OT] Re: What's the name for this?"
- Reply: gswork: "Re: [OT] Re: What's the name for this?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 22 Apr 2004 04:32:00 -0700
Corey Murtagh <emonk@slingshot.no.uce> wrote in message news:<1082612999.429542@radsrv1.tranzpeer.net>...
> Edward G. Nilges wrote:
>
> > Corey Murtagh <emonk@slingshot.no.uce> wrote in message news:<1082542201.529916@radsrv1.tranzpeer.net>...
> >
> >>Chris Sonnack wrote:
> >>
> >>>Nick Landsberg wrote:
> >>>
> >>>>Kicking this up a notch (and back to the area of programming),
> >>>>many programmers have no idea of the basics of how a database
> >>>>works.
> >>>
> >>>Or down a notch, how many of us could design a modern CPU.
> >>
> >>At a stretch I could MAYBE design a seriously old-fashioned CPU. But
> >>modern? Nuh-uh, not me :>
> >
> > Same here. However, I need to point out that the older CPUs
> > represented a genuine scientific advance because of Turing's result
> > while newer CPUs are more evolutionary.
>
> I think CPUs, and general-purpose computers, are more of an evolutionary
> step from the earlier dedicated computing devices. The biggest advance
> to my mind was the advent of semiconductors, which enabled us to create
> vastly more capable computing devices. There was only so far we could
> go when valves were all we had available.
>
> > RISC (Reduced Instruction Set Computing) was presented by its
> > founders, for the obvious reasons of self-promotion, as a scientific
> > as well as an engineering advance. It wasn't because its truth content
> > depended on social factors including the specific ways assembler
> > language programmers mastered complexity on the CISC VAX.
>
> RISC is an advance in some ways, but in others it's a return to simpler
> times. With a small instruction set the CPU can be designed to run
> those instructions very efficiently, since the CPU is vastly simpler at
> the level of the silicon than CPUs with more comprehensive instruction sets.
The original vision, which I encountered at the ACM ASPLOS conference
in 1987 was indeed a greater simplicity. I also sensed at this
conference that RISC was an American, Reagan-era reaction against
European computing culture: for the RISC troops at the conference
really seemed to hate stacks.
That's because RISC is mostly about enabling speed advances through
pipelining and stacks, at least in the minds of the RISC people, tend
to serialize operations. For example, the simplest stack evaluation of
A And B will evaluate B when A is False.
But more generally, the conference broke with 1970s and VAXlike ideas
about Pascal, computing safety and CISC in a sort of bad-boy way.
>
> However the original claims that a RISC architecture would produce vast
> speed improvements have failed to come true for the simple reason that
> although it is /possible/ to do everything you need with those few
> instructions, it is seldom /simple/ to do so. This is especially true
> in cases where the programmers themselves are more comfortable in a CISC
> environment, since those programmers often end up implementing what
> amounts to a CISC emulation.
>
Oops. As often is the case, the rhetoric diverges from the actual
logic.
> Mind you, the TransMeta Crusoe chips are fairly impressive.
>
> > Therefore, while you should not break your arm patting yourself on the
> > back, the fact that you can design the architectural face a CPU
> > presents to the machine and assembler language programmer is
> > important, and it is very bad that outside of formal computer science
> > classes, and, sometimes not even there, this skill is not taught.
>
> It's not something I'm proud of, just something I figure I could do if I
> had good reason. I guess I'm happy - content? - that I reached this
> point with no formal instruction. Plenty of /informal/ instruction
> though :)
>
> >>>Now there's some serious (smoke-powered) magic! (-:
> >>
> >>The fundamentals aren't all that scary. Once you get your head around
> >>how depletion layers work, and know the configuration of doped materials
> >>in all the common simple semiconductor devices (diodes, transistors,
> >>FETs, etc), you've got a good foundation. Then you move on to logic
> >>devices - not quite the silicon level, but it's not a bad idea to know
> >>HOW and WHY they work. After that it's just a complexity issue :)
> >
> > To me, and I may be wrong, the most important is the architecture
> > discussed in such a way that the architecture could be implemented
> > using any hardware whatsoever. But it well may be a defect of mine
> > that I have never seriously studied semiconductor electronics etc. I
> > just imagine that I have the ability to create op codes. By my own
> > argument that it is better to know what goes on under the hood I am
> > therefore hoist, petard-wise...unless the IMPORTANT fact is the
> > "execution of instructions by a machine".
>
> This part of my response was largely directed at the "(smoke-powered)
> magic" comment. Semiconductors are very elegant devices that operate
> because of some simple principles, but for some reason a number of
> people who work with semiconductors (ie: at the design and
> implementation level, NOT the end-user level) seem to not understand
> these simple principles. Instead they understand how and when to use
> the various semi-conductor devices. The programming analogy is a person
> who programs with no knowledge of how a compiler works.
>
I never could understand why you'd even bloody want to program if you
had to "program" the slippery unknown and I have always found it
preferable to at least in principle know "how" the instructions are
translated.
However, in modern industry, the employee is indoctrinated to believe
that he cannot or should not have this understanding, and, in cases
where he thinks he does, the tendency is to declare that this
understanding has nothing to do with the contemporary reality.
I'll probably get in a whole bunch of trouble for "pretending" in my
book that a simple Basic compiler is "like" a modern commercial
compiler, and in many ways a modern commercial compiler is vastly more
complex. However, the underlying science is the same and part of
systematic mystification is indeed the pretense that engineering
advances are equivalent to scientific advances.
> The main question is whether "design a modern CPU" involves working at
> the level of the silicon. Most of the time I imagine that task is
> relegated to engineers who have to solve problems like quantum
> interference. If you don't have to go that low, then knowledge of the
> fundamentals of how and why depletion layers work is probably superfluous.
>
> A reasonably good analogy is language design. At the top of the design
> process you have a language specification. Below that is compiler
> specification, although this stretches the analogy since the compiler
> spec is largely inherent in the language spec. And finally the messy
> details of compiler implementation, which strikes me as a very good analogy.
>
> On more than one occasion in the past I've done the above in regard to
> languages - ie: created a language spec, then built a compiler for it.
> I wouldn't ever call the product a /modern/ compiler since it lacks all
> but the simplest optimisation.
Nor would I call the published compiler a "real" compiler. However, we
are dazzled by large-scale systems, produced by teams rather than
individuals, to the extent that we don't think that we can compete.
Then along comes Linux, which proves you can.
>
> Translated to CPU design... I'm sure I could make it most of the way,
> given enough time, and maybe even turn out a finished product. The
> result would be extremely primitive in comparison to 'modern' CPUs. No
> pipelining, etc. since I have no idea right now how that is supposed to
> be done :)
I'd close by pointing out something that's obvious to me but nobody
else, I guess.
Up until the middle of the Reagan era, Radio Shack purveyed kits and
hardware for hobbyists who were building computers and other
electronic gear in their basement.
Today, it pushes finished, consumer goods.
In part, this may be because tech people no longer have time for
"hobbies" anymore. It may also be because we're dazzled by the
industrial products to the extent that the idea of "reinventing the
wheel" by building a computer or a compiler in the basement seems
bogus and sad.
In this connection, the Dilbert cartoon has done a lot of damage.
That's because there is no law of nature that engineers are funny and
don't get laid much.
- Next message: Corey Murtagh: "Re: Java2 - jpeg has poor quality when written back to disk"
- Previous message: gswork: "Re: ASM Assembler"
- In reply to: Corey Murtagh: "Re: [OT] Re: What's the name for this?"
- Next in thread: gswork: "Re: [OT] Re: What's the name for this?"
- Reply: gswork: "Re: [OT] Re: What's the name for this?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
