[Novalug] [OT] The "real low level" of computers (it's not what you think)-- WAS: Packages v. ports v. source

Bryan J. Smith b.j.smith@ieee.org
Mon Mar 29 12:19:14 EDT 2010


Again, analness applied.  Although "Data Architecture" is very acceptable, and
actually preferable.  However, computer != data, in my analness.  ;)

And yes, I have used books entitled "Computer Organization," "Data Architecture"
(and even "Data Organization").  The term "Computer Organization" is used to
differentiate from "Computer Architecture," at least from an engineering standpoint.
Again, I'm clearly in a minority of people on this regard (and we accept such).

As far as on 2G v. 3G, I'll stipulate we largely agree.  I guess it hits the wrong
nerve when people mention assembler.  Although learning to properly write
threaded code in the language is a best step for a 4G coder.  And I don't see
how 2G languages actually, directly contribute in some ways to this understanding.

But understanding "Computer Organization" / "Data Architecture" does, and I
will agree to that.


----- Original Message ----
From: Peter Larsen <plarsen@famlarsen.homelinux.com>

So describing how you put a building together is called "building
organization"? I'm not sure I follow your logic here. What annotations
does the word architecture have that doesn't fit describing how/what
technology pieces fit together in the hardware? I fully understand that
there are overlaps into other engineering specialities but that doesn't
mean they have no barring on hardware architecture (yeah, I use the word
on purpose).

I've done data-architecture for a looong looong time - never have I ever
meet anyone who described it as "data organization".

Bryan, I think we actually agree but phrase things a bit differently.
I'm not arguing that a programmer needs to know how to create all his
functions in assembler - symbolic or otherwise. But understanding
registers, memory layout, paging and the difference between bytes,
unsigned, integers, longs, floats etc. - to understand the implications
when you use the "basic" types in languages like C.

I wouldn't argue that languages like C exposes you to pretty much every
aspect of the "architecture" (there we go again) but it doesn't explain
why. For instance, try to explain why there's no native string type
without talking how characters are encoded. Yes, C can do it - but it
doesn't tell you why you're bound by those limitations. Knowing basic
CPU and memory structure helps. So does understanding how the CPU
"talks" to devices on the bus.

The fact that CPUs have come a long long way since the day of a single
core and linaer memory shouldn't prevent anyone for learning the basic
concepts. But how would you expect a programmer to be good at making
thread-safe code without understanding how the cores interact and
coordinate? The deeper you dive into the OS with programming, the more
you need to know about the hardware that creates your "universe". I
think we agree, that only when you understand this can you create
optimal code.  

Since I started with 3G languages I'm basically saying the same thing.
To understand 3G you must start with a basic understanding of 2G. Not
enough to be productive, but enough to understand the ramifications on
the 3G level. Just as well as a 4GL programmer must understand enough on
the 3G level to see why things work as they do.

For instance, to understand the advantage of SQL you need to have tried
to manage data in files first. See what issues/complications come from
multi-processor access, random read/write, indexes etc.

I don't agree that C teach you the computer ARCHITECTURE (hehe) as well
as assembler does. C doesn't tell me why there isn't a "string"
function. Nor does it tell me why "int" is interpreted differently on a
32bit processor vs. a 64bit - or even how endianns are different.
Otherwise, how would you explain why a binary file read on one platform
(ie. intel) can't be read on an Alpha or Motorolla processor?
Understanding how things work in the processor and why there are
different constructs of processors gives you enough to understand those
challenges. That doesn't mean you become a system-level programmer,
assembler or otherwise.  

For actual programming, yes. But I'm not arguing that people need to
know how to actually program in assembler. Just understand the
constructs of assembler (op codes, registers, memory addressing schemes,
io ports etc). 

That's really old news. Fortran and Cobol was made to do that for "all
development" back when I was just a glitter in my mother's eyes. We've
always made strides to layer and hide the complexities of the computer
technology in order to open it up for more use and features. Few people
understand how characters are actually rendered on your screen, let
alone how the pixel maps are calculated. That doesn't mean they can't
program the computer to do so, because it's already done for them.
However, if they want to do 3D coding or create an embedded system,
understanding how the hardware and drivers do this becomes imperative. 

I don't think this is a matter of outsmarting anyone. I'm in awe of what
the engineers at Intel can make a chip do today. I don't need to be at
their level to benefit from their excellent and complicated work. But I
know enough about what components they're working with. Just as I know
what the parts of an engine is but I'm absolutely UNABLE to figure out
what's wrong if the car makes weird noises.

This may be a generational question. I learned 3G and therefore
understanding 2G was important. I also learned 4G which I based on my 3G
understanding. If I had to teach computer science I would still start
with the hardware, and, nand and xor gates. Your prior writeup surprised
me a bit. A clock to me is essential to how a CPU works just as the
logical operators are put together to perform algorithms binary. I
wouldn't exactly call that boolean - that's introduced a bit higher up
except for JMP statements. If you have materials/links that would point
me to an update of my understanding of this, I would be very grateful.




More information about the Novalug mailing list