Re: push pop ebp

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/02/04 

Date: Fri, 02 Jul 2004 12:12:22 GMT

Ro wrote:
> this is the time I need all registers I can use
> if i write
> push ebp
>
> ;can i use here
> ;ebp like a general-purpose register ?
> ;e.g
> mov ebp, 9000
> label:
> ....
> dec ebp
> jnz label
>
> pop ebp

Yes, you may use it there; EBP _is_ a general purpose register
that may be used as you see fit...the only difference with EBP
is that it defaults - as wolfgang warns - to using the SS
segment register [SS:EBP] rather than the DS segment register
[DS:ESI]...though, under 32-bit OSes, like Windows or Linux, all
the segment registers actually all point to the same 4GB address
space and, hence, not even this distinction is particularly
relevent (e.g. SS:EBP = DS:EBP, as SS = DS under the so-called
"flat mode" that most 32-bit x86 OSes use :)...

It also nominally the so-called "base pointer" register to be
used to create "stack frames" by recording the "base" of the
"stack frame"...this behaviour, though, is NOT enforced in any
way and you're free to not bother with "stack frames" or use a
different register or whatever...the sole reason why EBP is
considered the register to use for this: It defaults to using
SS, like ESP also does, because Intel - seeing the need for a
second register for implementing the common device of "stack
frames" - set up this particular register to use a different
default segment register with this "base pointer" purpose in
mind (it also supplies the "BP" in the name, of course ;)...

Note that, under most 32-bit OSes, all the segment registers
point to identical address spaces (well, except for FS under
Windows...it breaks strict "flat mode" architecture to use FS as
a convenient pointer to a "per-thread information block"...but
things are otherwise "flat mode" throughout and this is only
really a "convenience" kind of thing) that this "default"
actually doesn't make any difference whatsoever under most
32-bit OSes...that is, you could rather decide to use EBX or
something instead because the SS / DS default thing makes
absolutely no difference when all the segment registers are all
the same and simply "aliases" of each other...there is actually
no particular reason or advantage to use EBP under these
particular conditions for the "base pointer" (though, this
applies to "flat mode" conditions only...it does make a
difference - no need for "SS:" segment overrides - under other
memory architectures where SS <> DS...but, in practice, none of
the popular 32-bit OSes do anything but "flat mode" :)...in a
sense, it only gets used under such conditions because, well, if
you want a "base pointer" to create a "stack frame", then you've
got to use _one_ of the registers for this purpose...and you
might as well use the one that's actually _called_ "base
pointer"...well, it's the "natural choice", isn't it? :)

And you often don't need to use such "stack frames",
anyway...they are a "generic" way to access local variables,
usually used by HLL compilers to simplify an otherwise complex
issue...assembly language coders can often avoid the need and
free up the register, if it's beneficial to do so...but NOT in
all instances, as we'll see...

In fact, it's because the alternative - using ESP directly and
not bothering with EBP or "stack frames" at all - is not a
"generic" solution that fits all possible situations, that HLLs
use these "stack frames"...that is to say, a HLL compiler is an
_automatic_ tool and the code it generates must _always_ work as
intended (pretty useless to have a compiler which you feed
entirely _correct_ code but it produces faulty output that
doesn't work...it's an implicit "guarantee" with HLL compilers
that they always endeavour to produce "safe" output that works
for all occassions...and, indeed, it is because compilers are
dumb process but also must keep this guarantee which often
brings about the instances of "bloat" and "inefficiency" that
HLL compilers typically generate that an assembly language coder
knows is not actually needed in that instance)...

For simple procedures with a fixed amount of "local variables"
and parameters, then ESP can be used directly - "[ ESP + xx ]" -
_EXCEPT_ to remember that ESP _does_ CHANGE whenever "PUSH" or
"POP" (and similar instructions) are used...so, the "xx" in "[
ESP + xx ]" isn't necessarily constant throughout that procedure
if "PUSH" and "POP" are used...one has to "count the bytes" and
account for any movement of ESP in the procedure...BUT this is
perfectly possible and frees up EBP for other uses, as well as
cutting down some of the procedure "overhead" in not needing the
typical "push ebp; mov ebp, esp" prologue and "mov esp, ebp; pop
ebp" epilogue (which the machine instructions "enter" and
"leave" are CISC equivalents to these sequences)...

The reason why HLL compilers can't easily automate this
generally is because of a particularly tricky situation that may
arise...and which also causes difficulty to a programmer
deciding to use the "direct ESP" method instead...if you have
looping code where ESP changes (because extra "local variables"
are added or the stack is used to preserve registers or
something similar that makes the value of ESP constantly change)
then how does one reliably access a _particular_ variable (say,
the second parameter) with an instruction of the form: "[ ESP +
xx ]"? The problem being that "xx" will actually _change_ and
_vary_ constantly inside the loop because of other things the
procedure does...

This can often be a complex enough problem for a human
programmer to solve manually and that's with "intelligence" and
"knowing what the program is supposed to be doing" on the
programmer's side while they do so...for a HLL compiler to work
out a "safe" sequence that uses "direct ESP" would require it to
follow and understand the code to know how ESP moves around and,
even then, it may simply NOT be possible to only use "[ ESP +
xx ]" type instructions but take a completely different approach
to get around it...

HLL compilers lack one often crucial ability: They don't
_understand_ what the code is supposed to be doing...oh, yes,
they understand the C code or whatever when they read it...but
they don't "extrapolate", they don't "comprehend" _WHY_ the
instructions are as they are, they aren't able to really 100%
follow the logic of the code and, most importantly, can't ever
be sure - without that "understanding" - whether it would or
wouldn't be "safe" in a particular instance...often, source code
simply DOES NOT have enough information contained within it to
notify the compiler...and the compiler is, in the end, a "dumb"
automated process (however elaborate and clever they get coding
it :)...and, simply, this is where HLL compilers _DO_ have very
real faults and drawbacks...take the typical "optimising
compilers are so good, there's no possible way to beat them"
hype with a pinch - no, make that a bucket - of salt...they are,
after all, "optimising" compiler, NOT "optimal"
compilers...that, in itself should say it all: It's an implicit
admission that they _CAN_ fail, produce inefficient and less
than optimal code...because, of course, if they could label it
"optimal compiler" then they most certainly _would_ do
so...there's hardly a better advert you could make than "the
absolutely 100% perfect never-makes-mistakes or produces
inefficiencies compiler"...

[ And, anyway, it's perfectly arguable that "optimal" is a
logical impossibility - a mere "concept" we can imagine but not
actually physically achievable - just as much as "Utopia" or
"infinity" or "random numbers (from a deterministic machine, let
alone a deterministic universe ;)"...but THAT argument, as you
might imagine, is large enough and highly philosophical that you
could devote a series of volumes to the subject and still not
cover it all...I'll spare everyone the torture on that one,
except this little note that it's very possible a physical
impossibility to demand absolute 100% "optimal"...a bit like
"world peace"...you couldn't eradicate _all_ conflict right down
to siblings fighting over who gets to play with a toy or a
married couple arguing over who cleans the dishers and that kind
of thing ;)... ]

Anyway, anyway...because "direct ESP" is complicated at the best
of times and there are certain situations where it wouldn't be
good enough, HLL compilers take the "simple" and "safe" option:
Use a register to store the address of the stack on entry - the
"base pointer" EBP usually - and then you can access things off
EBP ("[ EBP + xx ]") without that value changing...and when
you're all done, you pop the value in EBP into ESP to just
"jump" back to where the stack pointer was on entry...a solution
which is suitable for a HLL compiler because it's effectively
"brainless" (not really meant as an insult to compilers, it's a
_fact_ that they don't have a brain or intelligence, just a
program following orders ;)...the "base pointer" register keeps
track of the stack pointer on entry, so you need not in any way
concern yourself with keeping track of where ESP is at any
particular point and can easily access things off this "base
pointer" (which doesn't change, so you can use those "xx"
_constants_ :)...

It's simple, it's safe and it's "generic"...so you can use this
"stack frame" method and be happy that the compiler's generated
code will always function correctly and you don't need any
complicated code to implement it either...you can literally
_dump_ "push ebp; mov ebp, esp" at the start and "mov esp, ebp;
pop ebp" at the end absolutely 100% without thinking...both
compilers and programmers _DO_ just "dump" these sequences into
procedures without spending a thought about it at all...an
entirely "brainless" method, which is exactly right and suitable
for an equally "brainless" HLL compiler...

HLL compilers also do other similar things, such as using the
stack to pass parameters too...again, the point being that using
the stack works in _all_ instances - hence, is "safe" and
"generic" (and suitably "brainless" that you can always simply
just "dump" such code into the program without needing to think
anything through) - but may prove to be less than efficient and
contain actually redundent actions...compilers also - for the
purposes of simple linking by name - have to follow a
"convention" of some sort for their procedures to make sure that
the call to the procedure does actually match up with what that
procedure is expecting (order of parameter, who is responsible
for clean-up, etc. :)...modern additions allow the "calling
convention" to actually be added onto the procedure
prototype...such as "_cdecl" for C convention or I think it's
"declspec()" or something that VC++ uses...I use Borland tools,
you see, so I'm not completely sure on what exactly it
uses...but, well, as mention of "Borland" and "Microsoft" imply,
this is often a "proprietary extension" on many HLLs...

Indeed, due to HLLs often requiring "portability", then it
becomes impossible to _generally_ specify that these HLLs offer
something more detailed like: "_eax int _callercleanup
Procedure(_eax char *Filename, _ebx int Handle, _stack int
Count);" or whatever, where the exact "conventions" used by a
procedure could be explicitly spelt out per procedure...these
could only at best be offered as "proprietary extensions", due
to the inherent "non-portability" of something like an "_eax"
modifier to specify a parameter is passed in the EAX
register...the reason, obviously, being that such a modifier can
only apply to the Intel x86 architecture because only that has
the EAX register...a Motorola would have A3 or something
specified instead...the best that can be standardised for all
platforms with "portability2 in mind does already exist in C but
it's hardly the most sparkling way to go about it:
"register"...which only "suggests" that "we'd quite like this to
be in some kind of register, if possible"...but no mention of
which one and no guarantee that it'll be honoured, anyway...

The point of using the stack - in addition that it is "portable"
because it doesn't refer to any specific register but just a
general "idea" of how to use the logical "stack" abstraction -
is that it makes all procedures potentially
recursive..."parameters in registers", on the other hand, has
the issue - if the procedure is called recursively directly or
indirectly - that you will overwrite previous values, as there's
only one set of registers (well, from the perspective of the
software interface to the CPU...there are actually more
physically in the chip but this is all "transparent" so cannot
be used from software: "Backwards compatibility" is the culprit
on that particular problem)...so, of course, you want to call it
recursively but don't want to lose the previous values? Well,
ummm, use "PUSH EAX" or something, right? Yes...and then you're
effectively pushing your parameters onto the stack, anyway, if
you really think about it...

Hence, HLL compilers are also, again, respecting this notion of
"generic"...that the same simple, uncomplicated, singular
"generic" method can just be "dumped" into the code without
thought every single time...that is, _ALL_ procedures are made
re-enterant automatically, _whether they need this or not_ by
always pushing things via the stack every time regardless...

_WHY_ HLL compilers must do things this way is clear: They have
certain attributes that they _MUST_ fulfill, such as
"portability", "safe", "brainless", etc....and if anything is to
go, it's NOT "portability", it's efficiency instead...it doesn't
provide multiple possibilities and select the most appropriate
one (because that requires some "intelligent analysis" that may
be beyond what an essentially brainless automated compiler
process can deal with) but calculates a _single_ "safe" and
"generic" method that works in all instances, using that every
time...even if, in many instances, this isn't the best method to
use and contains inefficiency or redundency...they _MUST_ do
this or won't be able to sport such keywords as "portable!",
"safe!", "reliable!" and such on the side of the box to persuade
project managers to choose their particular HLL to deploy a
particular project or two...a HLL is a HLL _because_ this is the
_compromises_ it chooses to make...

And, yes, my actual objection here is NOT that I don't
understand why HLLs make these choices nor some belief that HLLs
are inherently "evil" or anything like that...my, I think quite
legitimate, objection here is simply: They are _COMPROMISES_ so
_CALL THEM_ "compromises", don't try to pretend they are
Heaven-sent gifts from the gods or something...I think you know
what I'm saying: So long as it's _honest_ about what these
mechanisms are, then I see no problem in them being there or
being deployed in appropriate instances...the problem is
pretending that "portability" for a program that doesn't need it
is somehow "good" when it's a TOTAL REDUNDENCY that _HARMS_ the
software...more, I'm also of the opinion that the _wrong_
compromises are chosen often here (so the implied "dishonesty"
about what they are is even more potent when they are calling
wrong things "right", as well as simply not calling them by
their true names, anyway)...that is, something like
"portability" is HARD-WIRED into a language or OS and, again,
_ALL_ programs must suffer any penalties, compromises and such
because so long as just _one_ program out there needs this, they
are "generic" and include it at all times for all programs doing
all manner of completely different things...as it's hard-wired,
it's also often simply impossible to by-pass when not
needed...and, again, my objection isn't the existence of these
things but more how people go about using them...that is, there
actually is _NO NEED_ for a programming language itself to be
"portable" but rather can _offer_ "portability" by offering
various mechanisms...HLA, for example, is NOT "portable" at all
in itself, as it's an assembly language...but, with the addition
of the right kinds of support - the "standard library" - it can
_offer_ that possibility when required...it's not "portable" in
itself but it can be _MADE_ into something "portable" by
following the correct procedures and using the supplied
support...thus, _WHEN_ it is appropriate to be "portable", the
program can be made such...when it is not, this support is
simply ignored, as it's not required in that instance...perhaps
this is a touch "philosophical" but I believe it should be a
_CHOICE_, not some "policy" decided blindly from some academic
"ivory tower"...does Dennis Ritchie (C) know what programs I'm
going to write and what their needs are? Does Soustroupe (C++)?
Has Booch (OOP) ever seen any of my code or have any idea what
applications I might need to write? No, they don't...so, why
exactly are _they_ the ones deciding these things _BLINDLY_ and
then _HARD-WIRING_ it into what they provide when they actually
have no qualification regards the specific applications that
need to be created to do so...what they are doing is operating
with "averages", "most likely cases" and so forth...this _MIGHT_
apply, of course...on the other hand, it might NOT apply...I'm
not saying these decisions don't need to be taken but that
perhaps the wrong people are typically making the decisions "on
behalf of" programmers who are actually better qualified with
regard to their specific application to know what it does and
doesn't require...

For instance, academic "ivory tower" policy suggests "don't use
GOTO"...well, in assembly language, "JMP" pretty much is
"GOTO"...all programs end up as machine instructions...hence, by
extension, all programs everywhere are "wrong" according to such
"ivory tower" thinking...it's, of course, an actual _NONSENSE_
to be dictating such things _blindly_, whatever they may
be...again, it's not the advice that's necessarily wrong (heck,
BASIC programs with "GOTO" _ARE_ a bugger to read ;) but _HOW_
this advice is being given...by "diktat"...in fact, consider the
typical reactions used when someone "violates" these ivory tower
"diktats"...you use "GOTO", you use assembly language, you
suggest something opposing the "established order" and out comes
the "secret police" to pour scorn and mockery over
you...compliance to the dictator through fear of
embarassment...pay CLOSE ATTENTION to what I'm saying here and
then review how programmers typically talk to each other:
"You're not using the Graham hashing algorithm?!? Why you are a
simpleton! You cannot read, let alone programmer...[ insert
insult ]...[ insert mockery ]...[ insert scorn ]"...you even
find this in computer stores too...lo, the customer has asked a
legitimate "newbie" question! Make them feel inferior! Insult
them over and over until they "comply"...an _ENTIRE INDUSTRY_
follows this mentality...it's ingrained, unfortunately, to the
very core...I am, indeed, looked on as somehow "wrong" because I
question things from time to time...I'm "evil" because I take
the time to try to _EXPLAIN_ something without delibrately
complicating it or otherwise maintaining this strange elitist
"join the club" attitude...I'm also stuck in the middle of it
too...sure, I'm probably accidentally guilty of doing it from
time to time too (hard to avoid when it _is_ so fundamentally
stamped into how the entire computer industry operates: make
people feel inferior, delibrately complicate things with jargon
so that only you understand what's happening, etc....it,
unfortunately, _feeds the ego_ to carry on with the "join the
elitist club" mentality so it self-perpetuates completely
unconsciously)...

Therefore, my apparently "strange alligences" (at least, to some
people's opinions they are strange) become clearer...Randy
offers _choices_ with his HLA, he _explains_ and attempts to
_de-mystify_ how it all works, he carries no "elitist" attitude
that assembly language is only for "gurus" and tries to welcome
all into the fold who are interested...yes, he does sometimes
perhaps talk in an "academic" way...but then - hello?!? - he
_was_ a university lecturer, after all...he _is_ an academic so
hardly surprising if his language is that way from time to
time...one thing I've NOT detected, though, is the thing that
some academics do in wrapping things up in so much jargon that
it's completely inpenetrable so that people just have to accept
on trust that it does actually make sense and this is the right
academic to be asking and following...hence, I've heard the
accusations that Randy is like this but, sorry, I simply don't
see it...I can understand how it might be _expected_ that he's
like that and if a jargon term appears then people jump to the
conclusion that "oh, more of the same!"...but that would be
jumping the gun and a false conclusion...even his harshest
critics have had to recognise this grudgingly from time to time
(e.g. he knows what he's talking about, he is _FOR_ assembly
language very firmly, if you listen through the jargon then you
hear a human being trying to help you, NOT some "academic"
trying to hoodwink you through complicated terms and "follow
what I say" diktats or otherwise)...

Rene's so utterly correct about the general "specific assembly"
points he makes from time to time (unfortunately, he's tended to
stop making them as he once so excellently did before...when I
tended to actually back him up, in face of opposition, not the
other way around as one of his harshest critics...concentrating
on mostly useless things like "assemble speed" and "it's a
ReactOS assembler" and what-not...he shouldn't have dropped the
SpAsm name, not just from the perspective that it was simply a
better name but he also seems to be losing a grip on the
underlying principles of explaining and advocating "specific
assembly") that it is actually a massive source of frustration
to me that he does not seem to grasp the importance of _CHOICE_
in the matter...that the "mistake" HLLs made were to "enforce by
diktat" that simply doing the same in reverse with assembly
language is the exact same mistake all over again...

The power of assembly language stems from _one_ attribute it has
above all others: _Liberty_...you can do _anything_ that the
machine (and OS usually, if you have one of the restrictive
ones...not a problem for Annie or wolfgang but the rest of us
have to consider this point ;) allows...

Which, indeed, covers this situation of using the stack to make
all procedures potentially recursive...in fact, generally
speaking, a _majority_ of procedures tend NOT to need such a
thing...but, no matter, so long as just _one_ procedure out
there is recursive then they _ALL_ suffer being made so: Making
a procedure that's not called recursively "recursive safe" still
works, it's just often inefficient to do so...so they are _ALL_
made that way and the inefficiency accepted...

Another similar one again - though actually fully unnecessary
now, with the way modern OSes and the treat interrupts under
multi-tasking - is that the called procedure must preserve
registers...why? Well, interrupt procedures _must_ do so, as
they must return things they way they were on interrupt...BUT
modern OSes and CPU designs conspire to make this unnecessary:
programmers cannot directly "hook" or replace the OS's interrupt
service routines, the CPU allows this all to be handled by use
of a task switch (which automatically saves and restores
register contents) and it doesn't work in the way it used to
work...leading to the strange situation that registers are
preserved by procedures throughout the system when not even the
original inspiration for doing so needs to do that anymore...it
logically makes more sense the other way around...a procedure
that knows it has important register contents to preserve should
be the one to preserve it, not the called procedure...every
procedure can thus be written with the presumption that _all_
registers are available from the start...the calling procedure
only preserves what needs to be preserved...one particular
benefit of doing this way around is that of saving a register
before a _series_ of procedure calls and restoring it after
them...one save / restore for the whole series only on the
registers that are actually storing important information rather
than save / restore, save / restore, save / restore on all
registers used by a procedure "just in case"...

Of course, it is still possible that the calling procedure
preserves a register which wouldn't actually have been effected
by the called procedure at all...but this "worst case" is, at
its very worst, no better than the other method...on the other
hand, it can be better in many other cases: "equal or better" is
always worth pursuing and will provide an improvement...note
that, of course, the ultimate "best way" for this to be done is
that both caller and callee _know_ which registers preserve what
and only deal specifically with those register that need it
only...but this is another consequence of HLLs always needing
"generic" solutions and needing that everything is "portable" in
all instances...such procedures, indeed, need to be "black
boxes"...but a "no requirements" black box - called procedures
have free reign on all registers on the presumption that is now
the _caller's_ responsibility to look after its _own_ register
contents (surely, I'm not alone in thinking this makes much more
sense? The caller knows what's important and what isn't and it
has responsibility for its own variables...the callee starts
with the presumption that all registers are available) - than
the reverse, which is amazingly the usual default: Called
procedures must presume all registers they use might be in use
and so must preserve anything they touch before touching it
(encouraging the _least_ use of registers, whereas the most use
of registers usually leads to better performance - avoiding
"stalls", keeping as much on-chip as possible without going to
memory, etc. - so this is kind of implicitly encouraging the
wrong style of code most often)...every call must save / restore
individually (no possibility to save / restore across _multiple
calls_ as in the opposite scheme)...but the most strangest thing
here is that caller must _depend_ on callee not to ruin any of
its registers...if it does, then it could make a program go AWOL
and crash...hardly encouraging of robust coding to have such a
warped "default" used by most programmers and OSes and so
forth...a strange kind of "black box" to be sure that carries
such potentially dangerous "requirements" on its use...really,
the requirement of "safety" should be on the caller, not
callee...after all, before using a potentially dangerous tool,
you put on protective gloves and glasses - take responsibility
for your _own_ safety and protection - you don't throw a
chainsaw around with the presumption that it's the chainsaw's
responsibility not to kill you, right? But, bizzarely, it _IS_
the wrong way around most commonly in the majority of code out
there...you call a procedure and must cross your fingers and
Hope that it doesn't ruin your important register contents
(!!!)...

The problem, again, is "generic" thinking...the old-style (which
no longer is used, in fact) interrupt service routines - due to
the possibility that they could interrupt code at any point -
_MUST_ preserve register contents...there's no opinion in the
matter because of _how_ they get called (if you don't, you're
guaranteed to crash interrupted programs and probably the entire
system ;)...but the same requirements aren't necessary on code
_called_ quite knowingly and delibrately by a program...indeed,
the _reverse_ makes more sense that it's caller's
responsibility...but, no, this would introduce two possibilities
"specific" to particular contexts...this is not "generic" enough
to have only _one_ method to apply to the whole system...the
"dump code" brainless requirement...so, creating redundency,
encouraging worse performance, taking a less robust and quite
illogical policy is used because that "standardises" it so that
all procedures are exactly the same...and, as noted, ironically,
interrupts are now completely swallowed up by modern OS designs
that ordinary application code does not ever "hook" or "replace"
such things...more, the CPU handles it automatically as part of
a "task switch", anyway...so across the whole system, procedures
are tending to follow a "generic" solution that no longer has
any justification whatsoever...

But, nevertheless, because it's become a "force of habit" to
follow this "de facto" standard, everyone who wants to write a
procedure (that needs register preservation...for instance, a
library procedure that could be called from anywhere) does it
without thinking...they type "call xxxx" and inside the
procedure put a series of "PUSH register" as their first
instructions, for every register used regardless, and "POP
register" as their last...well, consider switching to the
reverse instead: "PUSH register" only on the registers that
procedure wants to preserve" then the "CALL xxxx" then the "POP
register" to restore the contents...that the caller takes
responsibility for its own register contents...now the called
procedure can be written _free_ of any "PUSH / POP" sequences
with an assumption that all registers are free for use...

Unfortunately, this is often made impractical...the OS itself
takes things the wrong way around so though going against the
grain of this and taking the reverse perspective still works, it
actually becomes inefficient in "double saving" the
registers...if such a scheme exists, then it naturally has to be
_uniform_ across the system to be useful and efficient and,
unfortunately, most OSes (where this is applicable) tend to
standardise it all the wrong way around...

Although, this last example of "register preservation" is NOT
quite so relevent in modern OS environments so much...it's an
example that's "dating", granted...but shows how such "HLL
thinking" has been around for a long time...that it really does
permeate entire systems with redundencies, inefficiencies,
etc....remembering that the system is _FULL_ of such things
everywhere: call overhead, backwards register preservation,
needless stack use, layer upon layer of "abstraction",
indirection, portability, etc., etc....all of which _accumulate_
across the entire system, being called over and over
again...resulting in a PC with monsterous capabilities taking a
minute to load an application, a second to refresh the graphics
and so forth...a second and a minute are times that are often
unacceptably long for a human being (considering you only want
to load something or refresh the graphics, not exactly demanding
"Cold Fusion" or anything absurd or unreasonable from the
machine) but, for a machine, this is a relative eternity...

This is an inherent "conflict of interest" that HLLs must battle
with...the usual casualty of this war is "efficiency" because
with a prevailing attitude of "buy more RAM!", "portability is
god!", "oh, nevermind, hardware will be better in a year's time,
let the hardware cover the software inefficiency" and so forth,
a touch of "bloat", a touch of "slow", a touch of "redundent" is
what HLL thinking tends to implicitly take on...

In truth, a large element of the problem with HLLs (and also
many OS designs and so on) is what I believe is simply the wrong
set of priorities and attitudes toward the cause of delivering
good software are decided and adopted...things are seen from the
wrong viewpoint...

For example, machine code is always non-portable, specific to
that machine...and, in the end, all code becomes machine
code...but the source code gets confused with the final binary
output and "portability" is still worshipped, as if the CPU was
actually running C source code (because that's only what the
programmers sees with their own two eyes)...it's a subtle
influence but it's there...portability, abstraction, layers,
etc....your system is full of them...and not all of them are
actually serving a useful purpose...for instance, OS device
drivers provide a "device-independent" interface to the OS, why
does the application need to talk _via_ the OS's equally
"device-independent" interface? Especially when it's weirdly
_different_ to the device driver's version...ummm, so there's a
"translation" from one "device-independent" layer to another
"device-independent" layer...and, well, simply: _WHY_? What
actual purpose does this serve? In some cases, actually
absolutely nothing...it's taken on "portability" quite
needlessly...it's implementing "genericism" to no useful
_physical_ effect in the machine code...it's avoiding "porting"
difficulties that will never happen because it'll never be
"ported"...

After all, if software really was _actually_ "ported" as much as
people make a fuss about "portability" then I should be able to
buy an Apple iMac or some other non-PC system and suffer
absolutely no problems getting _identical software_ for it that
I had for the PC...I mean, all the software is "portable",
right? So, all machines must have completely identical software
for them...just a "re-compile"...that, well, there's no
particular advantage in buying a PC, in fact, because whatever
you're doing, whatever software you use, it's all equally
available for other systems, right? Why, it's all "portable" and
it's all being "ported" over to other systems, yes? In all
directions, as well, of course...there's all that iMac software
for the PC too that's been "ported" across, yes? It's a Utopia
of "portability" surrounding us, isn't it? Indeed, there is
absolutely no difference between various systems because
software has made everything "portable" that all systems are
completely identical in what they provide...so, of course, there
is no PC dominance...no reason to prefer that system to any
other...

Yeah, exactly...when practice does not reflect the "theory"
thrown around, then you'd be entirely correct to _CHALLENGE_
that supposed "accepted wisdom"...

HLLs are perfect, yes? The more "abstraction", the better?
"Optimising compilers" are able to perform miracles and are
perfect and infallible and undefeatable?

Okay, fine...then _explain_ why most software is crap? I mean,
it is, isn't it? Most software is bloated, slow, mismanages RAM,
etc....if all these "wisdoms" and HLL tools are so "perfect" and
"infallible" - and they must be because if you dare to challenge
any aspect of their "established wisdom", then you're beaten
down with a large stick...made to feel inferior or stupid and
held up for humilation and so forth - then how come software
that follows these "wisdoms" is crap?

Don't just accept the words...double check that the _practice_
is actually meeting the "theory" proposed...it's amazing just
how much it clearly _ISN'T WORKING_ but people still carry on
because the "expert" and the "textbook" _INSIST_ so strongly
that it does work...though no real-life examples actually back
this up...

Not just software, it's a general human thing; We're told that
"downsizing" improves all these companies...so why do companies
that do this then have to "downsize" yet again a year later? And
then again a year after that? Because, oh dear, once one starts
this trend, they all try to "out-compete" each other in how
drastically they can slash their operations...great...but, at
some point, there, quite logically, is a _limit_ on how far this
can go...I mean, fire all of your staff and, ummm, you're out of
business...it can't go on indefinitely but the way may companies
behave, downsizing and downsizing and downsizing, then - oh
dear - reporting finanical troubles and a difficulty competing,
they have to do it again...and again...

Ignore the "theory" for a second and instead look at the
practice; I'll use my country as an example because I know it
best but anyone in a Western country (and some that aren't) will
recognise all the trends...over the past few decades,
governments have privatised tons of industries...why? Because,
so the "theory" says, this improves the service while taking the
burden off the taxpayer...great, that "theory" sounds
brilliant...then this same government is now increasing taxes
towards record highs...businesses are actually NOT delivering
this "improved service" on the ground (one only needs to point
to the railways in this country...since privatisation, the only
statistics to go up is the number of crashes and deaths and the
_cost_ of it all to customers and taxpayers...so much so, that
the government is increasingly being _forced_ - through the
mismanagement - to renationalise by the back door...I don't
think they want to do so but there's no option: the private
companies are doing such a _dreadful_ job...costs rising and
rising for _worse_ and _worse_ service...cutting cuts and making
shortcuts on "safety", literally leading to trains flying off
the badly maintained lines and killing people)...on the
contrary, costs seem to be rising across the board...and then
businesses are "downsizing" and "outsourcing" and so
forth...this is all "good", we're told...hard to believe when
it's your job that's going...but let's put the emotive stuff to
one side because it's not actually needed...it clearly _ISN'T_
working on their own cold terms, anyway...

Because, if these things were actually doing what the "theory"
suggests they should then add it all up: Privatised industries
taken off the taxes, tax rates being increased to record levels,
businesses with highly "streamlined" services that are
"competitive", downsizing, outsourcing, etc., etc....all of
these things reported by the "theory" to mean improved services,
lower costs, excellent economies and so on and so forth...

So, where is all the money going? Governments taking everything
off the tax burden and increases the taxes...but, yet, the
billions and billions of money we're told that this will "save"
doesn't seem to be being used on anything..._where_ has that
money gone? Because from doing all this, they should be saving
billions but, yet, they are closing schools and hospitals at the
very same time...which, again, ignoring the social and medical
impact temporarily and only looking at the economics, this
should further _reduce_ the burden on taxes yet again....so
where's all this money that's being saved? It doesn't seem to
add up that the _costs_ and _taxes_ are being increased, yet, at
the same time, less is actually being spent on things, as
schools and hospitals and so forth are closing...basic
arithmetic, people...if "incoming" is increasing and "outgoing"
is decreasing then there should be a massive, massive "surplus"
sitting around somewhere...but, no, we also see massive
debts...where the hell is all this money vanishing to? It's got
to be going somewhere...and it's clearly NOT going into all the
things it's supposed to be going into...I mean, quite seriously,
are they just embezelling it into their own pockets or
something? Is that what all the armies of "managers" are all
about? Getting the "scum" to keep the "Kings" in the splendour
they are accustomed to?

Businesses are similar..."downsizing", "streamlining" and
"outsourcing" but yet this didn't do anything to prevent the
world economy nose-diving, did it? And then these same companies
report that they _NEED_ to "downsize", "streamline" or
"outsource" in order to simply stay in business...outright
_corruption_ increasingly being found in the ranks...managers
who _FAIL_ to make their companies do well are _REWARDED_ with
"bonuses" or given "Golden Handshakes" from companies that are
doing increasingly _worse_ and _worse_...

Oh, it goes much further...this is a modern psychological
memetic disease, in fact...for instance, more and more
"self-help" books are getting released but more and more
dysfunction in society regardless...they can't actually work too
well then, can they? In fact, could they even be _making things
worse_ because, well, it's an inherent logical nonsense in all
the important positions...what I mean is, in a well-run company
the "efficiency expert" who's called in to improve things
_becomes_ the least "efficient" thing there (well, if the
company is perfect, then hiring an "efficiency expert" is a
total waste of money and, therefore, is the _least_ efficient
thing to be doing ;)...shrinks that cure their patients'
psychological problems are actually reducing their potential
customers...

So, these jobs are actually asking managers and shrinks and so
forth to _put themselves out of a job_...well, of course they
aren't too keen to actually do that...and, instead, we find
managers hiring more managers who hire more managers...a case of
hiding? Safety in numbers? So that no-one notices that they are
the ones doing the _least_ most often...the actual people who
are most _redundent_ and _inefficient_ in a company, with their
increased red tape and their often inflated wages to decide
what? Oh, bring in some sub-ordinate "managers"...they can
actually do the real work and then our manager can just manage
managers...and the managers hired in, ummm, go and do the same
thing...stratas and stratas of "managers" all just bossing each
other around...keeping track of all this? Well, needs to be
done...so watch the red tape increase and increase...

It's a modern psychological disease...following "theory",
adhering to "political correctness", reading "self-help" books,
paying shrinks to cure problems but they diagnose more and more
rather than seemingly sorting anything out, "eat this!" one week
then "no, don't eat that!" the next, "reality TV" taking over
the airwaves so we can enjoy watching how dysfunctional other
people are and know that our own dysfunction ain't so bad, etc.,
etc....people don't like you? Do they suggest that you endevour
to become a more likeable person? Nope, you _FAKE_ it
instead...you should "positive think", perfect a _false_ smile
to _deceive_ others...you should "power dress" to just _LOOK_
like you know what you're doing (no suggestion ever given that,
instead, you _learn your job_ so incredibly well that you don't
need to present a _superficial_ image of knowing what you're
doing because you clearly _DO_ know what you're doing from your
talents alone)...

Do you see my point? It's a blind worship of "theory"...of
_imagined_ Utopias...of _superficial_ solutions in giving people
_false_ smiles...of _pretending_ you are more skilled with your
"power dress" rather than _actually being so_...

It's quite literally an entire "virtual" universe, with little
if any connection to _reality_, that everyone just "plays the
game" inside...it's not a conspiracy, it's not delibrate...it's
just the consequences - the "trend" - of how things are...that
is, if your job is to cure psychological problems then if most
people are psychologically sound then there's nothing for you to
do...you don't earn any money and can't make a living...but, of
course, everyone needs to do that somehow...so, ummm, let's go
_looking_ for the smallest thing and inflate it into a big
psychological problem...oh, can't find anything? Nevermind, just
_INVENT_ something to justify your job...and then the managers
do the same thing...ummm, nothing to be done? Ah, well...let's
institute "reviews"...let's have people fill out forms...create
"red tape" simply for the sake of justifying that the managers
are actually doing something...self-perpetuating when the
employees are spending so much time with "red tape" and "peer
reviews" and so forth, their productivity naturally drops (well,
they are NOT doing their actual jobs while they do all this "red
tape" nonsense :)...ah, so this is an excuse for the managers to
institute _MORE_ "red tape" to diagnose where the productivity
drop is coming from...and then institute even more "red tape" as
a proposed way to fix it...oh, crap...productivity's nose-dived
even further...hmmm, needs more "red tape", clearly! Until
employees are spending all their time filling out forms to say
why they aren't being productive, that's stopping them doing
their actual work...this is the problem that this stuff can be
self-perpetuating and it just gets worse and worse all the
time...

One day, the managers will wake up and suddenly realise: "Wait a
minute! We've 'downsized' all the employees, there's no-one left
doing any actual work...we're a company of managers
only!"...they'll "downsize" and realise: "Wait a minute! We're a
large multi-national corporation but we've so downsized and
merged together jobs that only _one_ person is left doing _all_
the work...well, that sure saves on the wage bill, for
certain...but, ummm, is it actually possible for so few people
to do such a massive job?"...governments will wake up one
morning and realise that they've privatised _everything_ so,
ummm, there's nothing left for them to be doing anymore because
they are now responsible for nothing at all (nevermind, you can
always just "invent" a war or two, right? ;)...blah-blah-blah...

It'll all end in disaster unless nothing is done about it...

But, nevermind, because the Good News is that, yes, you _CAN_
use EBP in your code...which is nice...

Beth ;)

Quantcast