Re: Thinking assembly?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/21/04 

Date: Wed, 21 Jan 2004 05:47:26 -0000

Thomas L. Christensen wrote:
> I hoped for some examples of things to avoid in my code, things that
> are typically HLL-thinking, but I can see it is more complicated
than
> that. I simply needs to understand the CPU and how it works,
> understand the instructions, be a good and experienced programmer,
> etc., to be able to "think assembly". Correct?

Essentially, yes; The way to see it is perhaps something like this:
assembly language is the machine's language (or, at least,
human-readable version thereof :) and, therefore, to "think assembly"
is to be able to think - like a machine does - in assembly / machine
terms...

Though the analogy is very loose, as machines are considerably
different to humans in many respects, you could also see this from the
point of view of an English speaker learning Russian...and, often,
something similiar is mentioned as the measure of how fluent and well
they speak Russian and can interact with Russian culture: "you're
'fluent' once you can think in Russian, just like a Russian does"...

Well, you can kind of think of it along the same lines, except that,
of course, one extra element machines bring into the equation, unlike
Russians (or any other human beings), is that they "think" in often
very "inhuman" ways...the machine's "culture", if we can call it that
from the analogy, is something totally "alien" in comparison to
learning an yhuman language or culture...

But, in the end, these are still both "languages" and some of the same
kinds of things apply...if you tried to simply convert an English
idiom, like "he's taking that student under his wing", then (though I
don't actually know Russian to know if there is a direct equivalent in
this case...sometimes there is, like German shares this particular
one...but, most often, idiomatic sayings just simply DON'T translate
to other languages _at all_ because they often come from "cultural"
stories and biases and traditions which aren't shared...in fact, the
only reason this particular English saying works in German - and a
number of other ones do too - is almost certainly because it was
directly "imported" by Anglo-Saxons, who originate where Germany
roughly is now, as they came to Britain and, thus, it ended up getting
mixed into the English language that emerged later...it's, in fact, a
Germanic "idiom" that, like most of the English language actually
really comes from "somewhere else", got "borrowed" :), chances are,
that this sentence converted into Russian would be a complete nonsense
to them...spotting "idioms" from your own natural language in your own
speech can, in fact, be difficult to do at times - because you're so
used to your own language - that it's very easy to just "literally
translate" them and cause terrible confusions: "What do you mean?
Human beings don't have wings and I did not see him physically attempt
to shelter the student with any part of his body, wings or
otherwise...what on Earth are you talking about?"...

Again, the analogies are all "rough" here because human and machine
languages are very different in many ways (machine language, for
example, would be - in human language terms - always in the
"imperative case" because they are all "orders" or, of course, as we
do call them: "instructions" ;)...but you can kind of see that a
similar "translation problem" can arise if you still "think" in human
or even HLL terms (which are very abstract from what actually goes on
in the machine itself) and then just try to merely "literally
translate" what you're thinking in HLL terms (or in _human_ terms,
which is more the original problem _everyone_ gets simply learning to
program: "What you mean I actually have to tell it exactly everything
it's got to do? And it won't remember it, so we have to keep giving it
the same program? I thought computers were meant to be 'smart' but
that really sounds like 'dumb' to me!" :) can lead to a "lost in the
translation" problem...

Once you've learnt and understood the machine in its own terms, then,
of course, you can actually approach the problem in _machine_ terms
right from the start...you don't need to "translate" and you don't get
any "translation problems"...that's because you're "machine thinking"
(or "assembly thinking" :) and are not just talking to the machine in
its own language but have become "fluent" and _understand_ that
language and what it means in terms of how the machine works, so that
you are then, basically, using the machine as well as possible...

The analogies to natural language, I stress again, are _LOOSE_ (some
things that would apply to humans and natural language have no meaning
in computer languages and some things in computer languages have no
natural language equivalent...so, in fact, there's even a potential
"translation problem" in making this analogy itself ;)...but,
otherwise, they do give a rough impression that's pretty accurate
because, well, calling them both "languages" is only _partly_
"flippant humanising for the sake of it"...

Actually, on that last comment, there's a touch of "assembly / machine
thinking" inherent there, I suppose, in that the more you do, the more
you can "intuitively" tell if a particular something is "machine" or
"human"...for example, many people find my "floating point shouldn't
really be on the CPU itself, as it's an abstraction to suit human
needs and not really a machine thing at all" comments distinctly
strange: "it's part of the CPU these days and catered for by _direct_
machine instructions, so surely that makes it "machine" and "not
abstract"?? Plus, why on Earth should something abstract, desgined to
meet human needs, be considered "inappropriate" for putting on a CPU,
anyway? I mean, are you trying to "defend CPU rights" or is there
something else behind you saying what should and shouldn't really be
part of a CPU? Do you just mean you don't like it there because it
doesn't 'seem right' or do you really mean it's 'wrong' to be included
and should be removed? That's all a bit weird, isn't it?" (yes, I can
"human think" still, I grant you - mind you, some "geeks" really do
hang around machines too long and start forgetting to behave like
humans socially (hence the stereotype of the "geek" who has no idea
how to "relate" to fellow humans at parties and who "doesn't have a
girlfriend"...obviously, always a "pinch of salt" with any stereotype
because being around machines doesn't "automatically" make you like
that at all and there can be some right "characters" who also program
computers...plus, women programmers like me act as a "case in point"
that the stereotype couldn't be 100% accurate in any way...but, though
that "pinch of salt" must always be applied, stereotypes _do_ get
their origins from _somewhere_...it's just that they tend to grossly
exaggerate, distort, add extra bits which don't actually apply and so
on that you should never ever "trust" a stereotype as being in any way
right...but they do sometimes carry the threads of some small
underlying truth here and there :) - so I realise that some of these
"floating-point" arguments can sound entirely daft, even to fellow
assembly programmers, but, well, it's like a kind of "intuition" you
build up about these things...you kind of "get to know" machines and,
thus, you can look at some things and say "oh, that's not very
machine-like!" and the rest of the world thinks you're stark raving
bonkers, understandably...

I get this problem most often when watching sci-fi things with
"robots" in them on the TV or in movies...and I'm like: "no,
no...robots wouldn't be like that at all...no! A machine wouldn't
think like that at all! You call that thing a robot?!? They just have
no idea at all, do they?" with all the ordinary people around me
thinking "oh dear, she's a bit strange, isn't she?"...like, for
instance, everyone else probably watched the Matrix and thought "Woah,
cool!" but I was thinking: "If the Sun was blocked out then if _any_
method to get through the cloud layer (and I could, myself, think up a
good ten methods or so worth the attempt...oh, that's "programmer
thinking"...any problem that shows its face is automatically "analysed
and debugged" instinctively at the subconscious level...it's, of
course, silly and pointless to work out solutions for these fictious
robots in a future that doesn't actually exist but, like, I don't do
it consciously anymore, really...the "programmer instinct" kicks in
and every problem and every bug watch out!! I can go into "machine
thinking" mode and equally never give up!! ;) or remove the cloud
layer exists, then a machine would - _regardless_ of how long it would
take - simply _do_ it, no questions ask and no hesitation entered
into" (time means something completely different to machines than to
us: they never tire, they never die, they never give up, they never
have doubts or are in two minds, they don't care for "looking silly"
even if they were to fail a million times...so, I mean, why _wouldn't_
a machine proceed, _even if_ it took a million years? ;)...

This is, of course, all a bit silly, really...but that comes of
"machine thinking" and "machine intuition", I suppose...it's like rich
people who've always been rich trying to _really_ understand what
"poverty" actually means...from time to time you can hear absurd
comments about: "I'm a billionaire...why can't they be too? It must be
because they are all stupid and lazy...right, let's _punish_ the poor
and that'll teach them not to be stupid and lazy anymore"...you know,
some people really don't see or understand that such comments are
absurd and will actually make things _WORSE_...for those that just
don't get it, ponder this: "give a man a fish and he eats for a
day...teach a man to fish and he eats for a lifetime...steal away his
fishing rod and relocate him away from his river so as to 'teach' him
to stop being so bloody lazy and go and find a river and work out how
to fish all by himself through just trial and error and the man
doesn't eat at all and drops dead"...agreed, option #1 is not as good
as option #2 but what's the absurdity of proposing option #3? What's
known as "severely missing the entire point", I think...to help in the
clarification, "poverty" is where someone _already_ is _far below_ the
official standard of "available means and resources" deemed necessary
to live...and everyone needs _some_ "means and resources" available -
a river and fishing-rod and such - or you're asking the _impossible_
for them to catch any fish at all...you can't go fishing where there
are no fish, clearly...

> It is not the answer I expected.

It rarely is in this life...

> I thought it was about some "habits"
> HLL users have. If I converted some C-code to asm, then you
> (asm-gurus) could say "typically HLL-thinking".

"Could" an operative word; It's not necessarily always "bad", as, in
fact, especially with C as the HLL language, it's the least "abstract"
of the HLLs...C only goes for "portability abstract" but stops short
of "problem domain abstract" (for example, C's "int" has no specific
size because different machines have different "natural" sizes for
their integers: a 16-bit machine and it's 16-bits, 32-bit machine and
it's 32-bits and, in the times when C first started, we even had 9-bit
machines because "8 bits is a byte" wasn't the "standard" it is
now...but, C's "int" is defined as "the natural machine word
size"...it's merely "abstracting" what size that actually is to be
"portable" to different machines where that differs...this is a very
different lower-level kind of "abstract" than some text-processing
VHLL which has "problem domain" abstractions where the language has
_NOTHING_ to do with the machine at all, in fact...the least
"machine-like" and more "human-like", the better for "problem domain"
HLLs)...

In reading the original authors of C's "design criteria", C was only
made "abstract" for the "portability" reasons...it was created
together with UNIX, after all, so it was designed initially as an "OS
creating language"...hence, it really does _want_ to be "low-level"
and if you take C "raw" without its standard library, you can really
see just how much they really stuck by that...absolutely NO means of
I/O inherently in C at all...because, for something like OS writing
(systems software who has as one of its responsibilities, a need to
_interface with hardware_), NOT straying too far from the machine is a
Good Thing...

BUT, UNIX was to be a "portable" OS...hence, the idea was to add
_just_ the abstractions necessary to ensure that and then they
effectively stopped...note how many compare "high-level assemblers"
(note, due to Randy's crap naming - sorry, Randy, but you know I've
never liked the name - I have to stress I mean _a_ HLA (which includes
things like MASM and TASM as well) and not only Randy's specific _the_
HLA :) to being "akin" to C in places...therefore, C really was kind
of an attempt to create a "portable ASM" and ASM programmers shouldn't
be too unkind to it because it's the closest cousin in the HLL world
and its amazing levels of _popularity_ actually, to my mind,
_demonstrates_ clearly that people do want and recognise that
"low-level" is _necessary_ (otherwise, no-one would have been
interested in C when BASIC or something "problem domain" is clearly
much easier to use :)...

Mind you, even C's very "minimal" attempts to cure "portability" and
cure "portability" _only_ still abstract enough that C can, indeed, be
"HLL thinking" and suffer because of the old "HLL abstraction /
translation" issue...it _has_ compromised - even if it attempted to
compromise the _least_ of any HLL away from ASM - itself in getting
that "portability"...of course, it was originally designed for UNIX
where "portability" was kind of _the whole point_ of it that this
compromise was deemed "acceptable"...so, like I say, I'd suggest that
we shouldn't be too harsh on the original designs of C because it
really is - in its purest form, without the "standard library" (which,
of course, are in large part merely standard UNIX original _API
functions_ so even those could be partially forgiven or an ASM
programmer using Win32 API could be accused of minor bit of
"hipocrisy" in condemning someone for doing what they actually do all
the time...of course, on non-UNIX systems, that "standard library" is
NOT the API any more that it's an "extra layer" but C couldn't
originally be faulted on that...that's something that by necessity
happened to it as it got moved onto machines and OSes where "exit()"
and so forth weren't actual direct API functions) - C really was
attempting "portable ASM"...it didn't not want to be ASM-like but the
needs for "portability" on wildly different machines forced it to be
"abstract" to account for that...but looking at its "minimal" design
and constructions like "VarA++" (an "INC" instruction?) and all that
kind of thing, the design really was "let's get as low and ASM-like as
possible, as far as the overriding need to be 'portable' permits us to
go"...

Hence, C ain't such a bad example...BUT, yes, the ASM programmer does
have machine insights that C programmers - who've never known ASM to
realise what they are doing "wrong" - don't realise...for example,
_why_ is a shift instruction ("<<" or ">>") better for multiplying and
dividing by 2, because what's wrong with "x * 2" or "x / 2"? Mind you,
that's a contrived example which probably wouldn't happen in reality,
because a modern "optimising compiler" would probably "convert" that
"behind the scenes" into shifts and so forth without the C programmer
knowing...so, they'd actually, interestingly, tend to find that "* 2"
works as well as "<<" and "be spared" knowing...except, of course, as
ASM programmers know, "being spared" knowing things has its plus and
minus points...abstraction, as I like to say, is a double-edged
sword...whatever is "done for you" is something you never learn
yourself (and, no, I don't apply this to HLA because, at any point
whatsoever - and it _will_ happen if they are following AoA and
Randy's "programme" to bring them lower and lower as he goes along -
you _CAN_ do it yourself and learn...there may be a criticism in
suggesting that perhaps Randy himself doesn't stress this too much or
make enough "raw" examples - I tend to sometimes think that, I
confess - with a lack, perhaps, of some "non-beginner" stuff to go
along with what's available...but I've mentioned this to Randy and
it's not that he's got the slightest thing at all against that - he'd
Love to see it - but, well, as amazing as his productivity is, there's
a simple physical fact that one man can't be in two places at once...I
mean, we cut Rene some slack with all his "this will, in time, be part
of RosAsm but isn't at the moment because I've not had the time to
finish it off yet"...I just think it's fair play to say the same to
Randy as well...not least because he's _always_ called HLA a
"prototype" and never suggested it was anywhere near completed...and
it still isn't really...but Randy's "not complete" does, on occasion,
beat other people's "completed", if you catch my drift, because HLA is
so much more equipped that even when it was "half finished", it was
still capable of things some "completed and fine-tuned" tools simply
couldn't do)...

> But it's kind of a
> relief if that's not the case. Then I can continue writing asm code
> the way I already do (the best I can), and stop worrying about if I
> "think assembly" or not. The more I learn about assembly,
> optimization, CPU's etc., the more I will "think assembly". Yes?

Basically, yes; I think I mentioned it in my other post...it's not a
"rules and regulations" thing, it the kind of "intuition" you build up
about knowing what the machine does and doesn't do well with...for
example, many people who've not got the experience yet might say
"machines are good at maths" (common enough thing people tend to say
from seeing the spread*** calculate things all over the place
:)...but, actually, machines excel in _logic_...it's actually a pretty
_recent_ thing that even the basic integer "multiply" and "divide"
instructions - fundamental and basic arithmetic there - were among the
_slowest_ instructions on a CPU (some even earlier CPUs didn't even
have "multiply" instructions _at all_ and just "did lots of addition"
(i.e. 3 * 3 = 3 + 3 + 3 :) or shifted bits around and added many
intermediate results together (i.e. as used in video stuff often, x *
320 = x * 256 + x * 64...where 64 and 256 are powers of 2 that you can
merely "shift bits" to do very quick multiplying :))...they aren't
anymore, mind you, as the CPU makers decided to work really hard on
making these run well (because, of course, they get used often enough
that it's worth making the effort on them to get them running well
:)...but, it gives you an idea of what I mean when people probably
assume that CPUs happily "multiply by 76" without blinking...well, on
earlier CPUs, not at all because "multiply" itself needed to be
"emulated" with bit shifts and addition (no actual "multiply"
instruction) and, up until recently, "MUL" and "DIV" were actually
horribly slow instructions - among the slowest and, also, varied
drastically in how long it took according to what kinds of numbers
were in the calculation (basically because the CPU would - as the
instructions were so slow - attempt to "take shortcuts" wherever it
could see any :) - and ASM coders would actually have their "tricks"
to multiply and divide numbers, _avoiding_ the actual "MUL" and "DIV"
instructions themselves for this purpose...

Also, another thing about ASM coding that comes from "assembly
thinking" related to the above is knowing that the "rules" can
actually change...I came to PCs prior to the "floating-point unit"
(FPU) being actually bolted onto the CPU itself (happened with the
80486...up until then, floating-point instructions actually needed a
separate "FPU" chip which would communicate with the CPU as a
"co-processor"...mind you, though this was slower to communicate with,
the separate FPU did actually _run in parallel_ with the CPU so they
could both be doing different things at the same time :)...hence,
there were all things about "avoid floating-point!", "Use fixed
point!" (an "emulation" of fractional numbers using only integer
commands by "imagining" a "binary point" inside the integer and
interpreting it differently :) and so forth...but, these days,
improved chip-making technology meant that they could literally stick
the once separate FPU straight onto the CPU itself and the "penalties"
that once were have been greatly reduced...this is why, when you meet
the "FPU" floating-point instructions as you learn assembly or go
further and look at the actual binary encodings for these
instructions, they are completely different in style to the main stuff
(have their own "register stack", encoded completely differently, etc.
:)...and that's due to the fact that it was once literally a
completely _separate_ processor of its own once...and, just for
"backwards compatibility", once they put it onto the main CPU itself,
they kept the original style, registers and encoding so that old
software could run completely oblivious to the fact that the FPU
wasn't "separate" (and also "optional") anymore...

So, the "rules" down here in "ASMLand(tm)" do actually change around
on occasion because the hardware manufacturers who make the chips
actually go and "optimise" something that was once horrible to use to
make it perfectly "acceptable" to use...that's another kind of element
of "assembly thinking", I suppose, in that HLLs tend not to have
"avoid this method, use another method...oh, wait, Intel have fixed it
and it runs okay now...so, if you like, you can _now_ actually use
that original method because it runs okay" rules of thumb...

Proper "assembly thinking", you see, does actually go _beyond_ merely
knowing the instructions alone because of things like "cache memory"
and constant "optimising" by the hardware manufacturers as they
improve their chip designs...that's actually why - as well as making
the idea clearer to understand - I've tended to say "machine thinking"
in most of my posts...you work _through_ assembly and it's what
assembly programmers do but, in a sense, it's actually slightly
_beyond_ that and is more "machine thinking"...you take into account -
for the best ASM code - of things like how the cache works, how the
bus slows things down...that, generally, if you can avoid it, you try
to avoid it like the plague...until, of course, AMD come up with a
design that "cures" it in the next chips...because, after all, guess
what "cache memory" is really all about? It's exactly just such a
"fix" on the "bottleneck" problem that CPUs outpace (often by extreme
amounts) anything else in the system so that if interfacing with
memory too often, they'd be constantly forced to slow down to wait for
other components to "catch up"...the idea being that the CPU has its
own "on-board" RAM (quick access) and then it can work with that
without being slowed down and then that "cache memory" can be more
"lazily" used to update actual RAM "in bulk"...so, there's another
thing for "assembly thinking": Try to keep things close together and
sequential in memory (fitting in with "cache line" sizes, if you're
really pedantic :) so that it works well with how the cache memory is
designed for (it is designed with the concept of "locality"...when you
ask for something in memory, it grabs a whole bunch of extra stuff
near it too, on the presumption - which is usually the case - that the
next you'll ask for will be nearby...work with those "cache memory"
presumptions and you're going with the grain and get all the
benefits...go "against the grain", though, and grab things randomly
from all over memory and, in fact, cache memory can actually be
_detrimental_ because you're making the cache memory mechanisms work
harder than actually would be the case if it wasn't there at
all...although, in practice, even in HLLs, no-one ever writes code
that access memory so randomly over great distances that the cache
usually works well...which is, of course, _why_ they chose it to work
this way by noticing that most code does quite naturally work with
this principle of "locality of reference" and made the cache work hard
to greatly improve that...but, as with most things, there's a
"trade-off" in that when it doesn't work well - you get a "cache miss"
that requires it to grab a whole bunch of stuff from actual RAM over
slower buses - the penalty is actually _worse_ than if cache memory
weren't there...it greatly improves the "likely" case at the cost that
the "more unlikely" case is actually made slightly _worse_...but,
overall, when things "go with the grain" of the cache mechanisms it's
an overall "win" and things are improved...but taking account of this
and making things fit really well with cache operation is where you
can greatly optimise things...although, of course, even better -
something only ASM coders can _specifically_ specify in their code -
is to keep as much "on-chip" in registers, going as rarely as possible
to memory (can't ever be totally avoided but then you wouldn't really
want to...but keeping memory access to a minimum makes an important
difference :), so that the CPU can run at the full CPU rate without
any "waits" at all...compilers try to utilise registers, of course,
but only ASM coders can be really clever and perhaps get an entire
algorithm working totally "on-chip"...and when you can manage that,
you'll really "kick arse" over HLLs...CPUs tend to _massively_ outpace
other system components that if forced to wait on other things, you
are really, really "dragging" the CPU's speed down...as I noted to
someone, who switched off their cache memory completely to test out
the hypothesis and got stupidly slow results which kind of proved my
point, if there were no cache at all and every instruction needed
memory, then ignore the CPU GHz rating in the advertisements, your
program is actually running at _bus speed_ instead, which tends to be
quite a bit slower...because for every single instruction, it simply
has to sit there and wait for the bus to deliver things...luckily,
things like cache avoid that and no program would ever be 100% "memory
access" instructions...but realising that your PC system has places
where it "bottlenecks" and where to avoid them is exactly the kind of
things ASM coders know but everyone else doesn't and everyone else's
code crawls like a snail and they fall off their seats in amazement
that the ASM code is running easily ten times faster than their
supposedly "optimised" C code...it's like "how on Earth could that be
happening? Can ASM actually speed up the processor itself?"...nope, it
doesn't speed up the CPU, it merely makes sure that the CPU is really
running at its true maximum capacity and not sitting around waiting
all the time...

In fact, as I've remarked before, if some people out there _realised_
just how much their systems were running "below capacity" and wasting
their time on "layered abstraction" and so on and so forth, they'd
probably entirely realise and sympathise why I have such a passion in
loathing Microsoft, the chief culprits usually in why your PC has to
be ten or twenty times (if you're lucky, that is ;) the _real_
"minimum specification" that the hardware - being utilised to its
proper capacity - could manage...

It's not entirely true the remarks about "but Windows is so slow when
you call API - and you've got to call API at some point, due to the
design - what's the point in ASM on Windows?"...but I do entirely
appreciate the "defeatist" attitude there because Microsoft really are
exactly that bad that you feel like throwing your hands up in the air
and saying "okay, you win...I surrender!"...but, really, my opinion
takes the reverse point you can take out of this: "indeed, Microsoft
are _so crap_ that you've just _GOT TO_ do as best as you can
everywhere else that you can do in trying to 'cancel out' their sheer
incompetence"...indeed, Microsoft API are so slow...but then, there's
an awful lot you can do in ASM code to _avoid_ as many API calls as
possible...in fact, that's why computer games tend to run brilliantly
and knock your socks off at their speed, while Windows itself bores
you to death, taking two minutes just to load something and refresh
the desktop and windows on the screen...basically, they - as far as is
actually possible - _ignore_ Windows...Microsoft added DirectX to give
them this "more direct path" exactly because all computer game writers
were _staying in DOS_ to be able to do this kind of programming...they
were kind of forced to do this or the only games in Windows would be
"Solitaire" (hardly CPU intensive ;) and it was kind of a "damning
advert" that no-one was moving to Windows, due to this major _failing_
in its design and coding...

Mind you, it's a general GUI thing because it's not only Windows but
things like X-Windows too that were designed by "theoreticians" with
"HLL thinking" that don't understand that an OS should actually _get
out of the way_ as often as possible...Microsoft's "control freak"
attitude and Love of "HLL thinking" meant that they, like many others,
completely _FORGOT_ the need for such things...hey, they write
spreadsheets and word processors badly in HLLs, you can't expect them
to actually understand what _programming_ really is...it's not "doing
jigsaws" with "layered abstraction", it's getting the bloody machine
to do things as best as is possible...

I _still_ think it's wrong...things like "DirectX" are a "patch" over
an originally _flawed_ design...people like Maxim with his "I Love
GDI!" car sticker might not understand but then he believes Microsoft
can't do any wrong, even when Microsoft _themselves_ actually admit
they have...as with anything else, good and bad tend to come together
and the "bad" of "assembly thinking" is that you finally understand
just how much of a _scam_ is being forced onto people and, in a sense,
just how much of your hard-earned cash you've _wasted_ supporting the
laziness and ignorance of Microsoft coders...

Mind you, you can kind of see this by looking at software and its
quality over time, comparing it to the hardware improvements...since,
say, 1984 (year of first Apple Mac release that brought the GUI to
everyone and also an amusing year to choose because of Orwell's novel
:), hardware has actually improved _many thousandfold_ in _all
directions_ (comparison: C64 1MHz vs. PC 3,000Mhz (3Ghz)...C64 64KB
vs. PC 1,000,000KB (1GB)...C64 tape cassette (3 or 4 minutes to
"quick-load" program using most of 64KB into memory) vs. 120GB hard
drive...blah-blah-blah...these aren't just "supercomputers" to a 1984
C64 user, there's are "super-hyper-computers" ;)...but comparing
software _QUALITY_? Was there actually two decades in between at all?
No-one would have accepted waiting a half minute for some Microsoft
package to "boot up" _even back then_ - when there was a _damn good
excuse_ for things to be that slow _physically_ - so why on Earth is
it tolerated today?

Some - sensing _exactly_ what it suggests about the software industry
in terms of the _damning_ statement it makes - really don't like me
making these points and dispute them...but, considering how hardware
has moved forward, then, relatively speaking, software quality has
gone _backwards_...because, of course, hardware moving forward brings
the software that runs on it along forwards with it...so, if
hardware's improved _several thousandfold_ then should things be in
order, software should be demonstrating a similar trend...obviously,
software does from version to version seem to improve (ignoring weird
things like Media Player 9 being _worse_ than Media Player 8 but
that's Microsoft for you ;) but that's masking something...hardware
improvements is "covering our arses", so to speak...relative to where
things _should_ be, everything's actually distinctly "backward" from
that by too far a measure to be excused...you know, coming from other
machines to the PC, other than the CPU clock speed, everything else
was a _downgrade_...having used nicely implemented GUIs for a number
of years, things were thrust back into a "command prompt" that wasn't
even that impressive in its own terms...it's why I pour compliments
onto iD with DOOM and so forth...because they seem to be still
operating as an "extension" of how things were before, so to
speak..._at least_ that good should be "normal", whereas it's,
instead, "ground-breaking"...and, heck, they use _C_ (but are, indeed,
"ASM thinking" coders :)...

It's like this massive "What if?" question hanging over all of the PC
world...what if IBM had taken their PC more seriously? What if
Microsoft hadn't managed to bluff their way into things? What if
Intel's x86 hadn't had that _awful_ bloody design? It should be noted
that these things were all more or less _mistakes_, _blunders_ and
_accidents_...IBM put the PC together almost as a kind of "joke" (they
weren't at all interested in it and poured mockery and ridicule over
"desktops"...they built it _only_ to keep Apple off manager's
desktops, as they didn't like seeing a rival's logo in _their_
"all-IBM" client's offices :)...the Intel x86 was really a "terrible
hack" when it first started with no intention it should have a "shelf
life" at all and certainly NOT at least 30 years ahead of it...and we
don't need to hear the stories about Bill Gates bluffing people and
paying next to nothing for DOS, changing the logo and then becoming a
billionaire, really, as using Windows itself makes the point
adequately enough...

There's a kind of "awe" thing with computers, that they are
"high-tech" and "really smart and clever" and stuff...so, like how if
a 14-year-old could work out what the power button did they got called
a "super computer whizz-kid Einstein of the future!" or something...if
people can get over this "awe" and accept things as actually being
just as mundane and boring as their washing machine or video recorder
(just serving a different "general" purpose :), then perhaps we'd get
some "poetic justice" that these people do NOT really deserve much in
the way of admiration...they've been scamming and hacking and
"patching over" from start to finish...if PCs were people, your
machine would be covered in bandaids, have a nasty green infection
thingy coming out of the DVD drive, its arm would be in plaster, its
legs in traction...looking like it's only just barely survived a
horrible car crash...needless to say, the software - like this
"patient's" brain - is just sitting in some indefinite coma...

Beth :)