Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!microsoft.UUCP!davewh
From: davewh@microsoft.UUCP
Newsgroups: comp.sys.apple2
Subject: HLLs vs Assembly
Message-ID: <9104181707.AA29942@beaver.cs.washington.edu>
Date: 17 Apr 91 12:43:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 69


My two cents:

I found that even though I had plugged on an Apple // for years, my
BEST source of serious knowledge on how a computer works came from 2
classes at MIT: one in which we built a predesigned computer (very
simple little thing, 800KHz clock, 64k RAM. CPU was built out of
little parts); the other one a compiler class.

The first class gave me a very good understanding of how the hardware
works in computers: why this instruction takes n cycles and so on.
The other gave me a good idea on how the compiler translates my C
into assembler. I had had plenty of assembler experience before these
classes, but the real insight doesn't come from programming in
assembler or programming in some HLL - but rather in knowing how the
compiler translates one into the other. Once you know how a compiler
works, it's much easier to locate obscure bugs in some HLL code. One
also can employ many tricks and know to avoid certain things. ie:

struct foo * NewFoo(void)
{
	struct foo TheNewFoo;

	TheNewFoo.member1 = value1;
	TheNewFoo.member2 = value2;

	return &TheNewFoo;
}

Do you know why this will FAIL? Do you know the RIGHT way to do it?
Sure, it compiles. It'll even run. I wouldn't write any code like
this though because it's dangerous. The quick and obvious fix is to
take out the '*' and the '&'. I still wouldn't do it that way
though... Anyone know why?

People here are arguing that Assembler should be a required course,
while others say it should only be touched upon or ignored. I
disagree with everyone: first, take a simple HLL course (like C).
Then a compiler class (we didn't have to write a C compiler, but the
language we did invent gave us a good idea of the complexity of
compilers and how they generally work). Then a more esoteric
language, like LISP. By then, students will have generic algorithm
experience and have a good idea on how to construct a program. Next
they get experience in how the compiler does the translation (and
what it gets translated into). They learn the pitfalls of doing
things the wrong way in some HLL. They learn WHY they have to use
'scanf("%d",&intvar)'. Then they learn the language of choice for CS
majors. The one where the compiler is much more friendly than a C
compiler but the students still know the pitfalls (why the thing has
to freeze up every now and then and garbage collect, etc).

The "you build it" computer class teaches people how the OS interacts
with the program. How the hardware handles memory cacheing, virtual
memory, context switching. Students learn why the computer will crash
if too many processes are running. Just what 'load" is. They learn
and appreciate what sort of work is going on. Why they should access
a 2-d array of numbers in row major order and not column major order
(one way causes the virtual memory system to spend all it's time
swapping - I sped a program up by a factor of 10 by simply changing
the order of the loops!). They appreciate the work involved in using
floating point numbers over integers. I could go on and on...

Ok, what do you all think?

Dave Whitney	Microsoft Corp, Work Group Apps  dcw@goldilocks.lcs.mit.edu or
I wrote Z-Link and BinSCII - send me bug reports. {...}!uunet!microsoft!davewh
I only work here. All opinions herein aren't Bill's, they're mine.
"We're samplin' - Yeah we're doin' it. We take good music an' we ruin it."
   -- "Rap Isn't Music"