Re: not OT : fear

R

rbowman 4 years ago

It's nice to see my education was prescient and not obsolete the day the > degree

> was awarded! (pity the folks taught about *today's* technology and > wonder how
> they'll forever be playing catch-up)

One of my senior projects was a thought experiment to design an automated library retrieval system. We were thinking in terms of microfiche in concrete terms but the media was TBD. About 40 years later when the library installed their new system to spit out your desired DVD it was somehow familiar.

Like aircraft designers waiting for lightweight IC engines the seeds were there waiting for the technology to develop. There were dead-ends like bit slice processors or bubble memory but eventually we got there.

The art of thinking was the important takeaway. Otherwise you're looking at a glorified trade school turning out Maytag repairmen. That's not to say we don't need repairmen.

Vote

D

Don Y 4 years ago

Bubble was a foregone conclusion -- too many advances in semiconductor memory already appearing on the market by that time (core being the established medium).

Bit slice imposed too much of a structure on the processor you were implementing. I used many of those concepts in my designs (Mick&Brick) but so many application specific instructions that didn't lend themselves easily to that sort of architecture (e.g., serial multipliers, etc.)

What I most lament is the loss of variety in processor designs of that era. In 6.3, you studied different processor architectures and implementations with an eye towards the advantages they afforded to the hosted code. You'd need to understand the role of a TLB in order to write code to *use* it!

"With VMM we can offer these features to the runtime..." "With CoW we can offer these features..." "With DSM we can offer..." "Instruction pipelining gives us..." "I/D caches give us..." "Tagged memory gives us..." "Segments give us..." "Protection domains give us..." "Capabilities gives us..."

The B5000 line would have been exciting to watch flourish (instead of flounder)

And, I would have thought that the *variety* would have TAUGHT developers the value of writing portable code (in HLLs), *sooner*. MULTICS certainly learned that lesson painfully -- IIRC the estimate was 30 man years to port the code from the 36bit architecture to a more commodity-oriented 32b platform (no wonder it exists no longer!)

The same can be said about early MPUs. Now we've got just a handful of offerings to address a variety of applications, markets and preferences. But, with the "coder mentality" that's now commonplace, this is probably a "business win" (finding people that can fluidly move from architecture to architecture poses a bit of a hiring hassle).

OTOH, now I can *easily* have the power and capability of a hundred VAXen for a couple of dollars and a couple of watts! (someday, folks will actually start using these capabilities)

Yes. An early employer once commented that he hired Northeastern (Univ) grads if he was looking for someone to address a TODAY need; an MIT grad for TOMORROW! (there were several of us on staff).

Vote

J

John Larkin 4 years ago

I had a 64 Kword fixed-head swapping drive on my PDP-11.

And later an 8" floppy drive that cost $4K. Neither was reliable.

Vote

R

rbowman 4 years ago

That has amused me at times. I'm not particularly good at math but like to think I have passable programming skills. I should say logic skills. I've worked with relay logic, fluidics, TTL/CMOS, and processors. The logic stays the same. I know about Boolean algebra, DeMorgan's theorems, and so forth but I've seldom made use of formal logic. It's intuitive.

Vote

L

Les Cargill 4 years ago

CS math isn't particularly "math" math. It's a few theorems and then complexity analysis ( big O ).

It's all but disjoint from programming, which is really mainly avoiding the nasty sharp edges.

Vote

D

Don Y 4 years ago

People are easily confused by faulty logic. Exercises like nonsense syllogisms are a great way to refine how you see logical deduction without the "assumptions" that you may have baked into certain "truths".

Likewise, understanding how you can "mechanically" transform between implication, converse, inverse, contrapositive, etc. and what those transforms do to the logic represented.

If you are pregnant, then you are a female. (implication) If you are a female, then you are pregnant. (converse) If you are not pregnant, then you are not a female. (inverse) If you are not female, then you are not pregnant. (contrapositive)

Clearly, the contrapositive and implication are logically equivalent. Knowing this can help you express ideas in better forms.

[One of my TA's was working on "smart DB queries"; rewriting them in ways that exploited knowledge that the data embodied but that the querant hadn't leveraged (e.g., if looking for pregnant people in the data, then don't bother looking at the non-females!)]

When you teach software engineering alongside a traditionally hardware curriculum ("classic EE"), it's a lot easier to see the parallels (duality) between the two. And, understand their root causes, etc.

E.g., implication tables need not be the sole use of hardware design. Ditto Karnaugh maps, DFA, etc. Hazards, deadlock, metastability, etc. all have software equivalents. The same design techniques can be applied in each application domain.

[VHDL/Verilog make this painfully obvious!]

Once you start seeing things in this way, a lot of the things that happen "under the hood" become intuitive. E.g., write a logical expression in the form that is most easy for a human to understand; don't try to "optimize" it -- because a compiler can apply the above techniques to MECHANICALLY and RELIABLY optimize it for you! Why are you wasting your time HOPING to do it "better" and obscuring the intent in the process?

You wouldn't ALWAYS draw a NAND gate as an AND with inverted output, would you?

Vote