Re: learning asm.

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 10/16/03 

Date: Thu, 16 Oct 2003 15:34:37 +0100

wolfgang kern wrote:
> Hi Beth!

Hi Wolfgang :)

> Sorry for the delayed reply..

No need to apologise...I'm so all over the place myself with posts
everywhere, I probably wouldn't have remembered this thread,
anyway...my little brain only handles so much and then it just fails
quite ungracefully :)

> | > My question was about a 'new' library-standard.
>
> | I know what you mean, wolfgang...but the problem is often just a
> | lack of agreement and co-operation...like, Randy has created a
> | standard library...no-one's interested...so, say, I create
> | one...no-one's interested, as they want a "new" one again...you
> | create one and no-one's interested...oh, no, they want a "new"
> | one ;)
>
> | You know what I mean? If everyone keeps asking for a "new" library
> | all the time then we'd just end up with a hundred libraries that
> | no-one actually uses...there won't be any such thing as a
> | "perfect" library whatever you do (Rene's points sneaking their
> | way in there..."generic" means "compromise (to suit many
> | situations)", which may mean making a sacrifice that "specific"
> | would not require...although, of course, "specific's" problem
> | here is that it almost always demands a sacrifice in the one
> | variable programmers don't always have to spare: time ;)...
>
> Yes, but couldn't we do a clean up with all the 'never used'
> within these 10 000 function-libraries.

Totally; In fact, a library should never be approaching 10,000
functions...if it is then it's not taking a reasonable approach to the
problem...such libraries are monsterous and lead to _more complex_
solutions rather than easier ones...

In this biz, though many continue to fail to see it, _less is
more_...RISC getting the edge on CISC...C's "winning formula" that
made it so popular and flexible, being the fact that it actually goes
for "as minimal as possible" and didn't add bells and whistles
directly...though Rene pushes it, the basic point about "specific" and
"generic" does hold...because that is where ASM gets that potential
edge over HLLs from the programmer being able to put _only_ what's
necessary to the task in hand (no strange "portability handshaking"
that HLLs insist upon, whether it is _needed or not_...if
"portability" actually isn't needed or a desirable attribute then this
nonsense is _entirely redundent_, in fact...it's jumping through hoops
that need not be jumped through because they serve no useful
purpose...yes, sometimes you've _got_ to use a stack because it really
is the best way to deal with recursive functions or something...but
insisting on it for all occasions? Especially when, for a heck of a
lot of code, recursion is an exception, not a rule...this whole "take
the safest route regardless"...yes, it works...and sometimes that's
what really needs to be done...but forcing it as a "rule" that must
always be adhered to regardless of whether it's useful or not I don't
like...the application should define what's necessary, not some
academic in an ivory tower who just wants to be famous for inventing
some arbitrary list of "ten commandments" because those sort of lists
are always popular and famous...like those "top ten rich people"
lists, they're always great fun to read even if they're actually
mostly useless for anything practical ;)...

Less is more; That's why I advocate the "minimalist" approach
throughout...if you like, it's a simple extension of "the fastest code
is the code that never runs (doesn't even exist)"...so, the next best
code is the code that's tiny (nigh-on non-existent)...next best is
fractionally bigger...and so on and so forth..._LESS_ is the target,
not more and more features regardless...even the worst culprits MS are
starting to see the folly in that approach of 600,000,000 API...which,
even if you wanted to and tried really hard, is actually _beyond_
being useful...it actually starts working in the reverse direction and
makes things more complicated and more difficult and worse
performance...the "buy more RAM" mentality haven't picked up that,
_truly_, there _IS_ a very real limit to how far you can push things
in this direction...hence, also, what I've been saying about
"backwards compatibility" returning to haunt people thirty years later
(well, the x86 chip is approaching that anniversary and the whole
64-bit fiasco shows that it just won't die...both AMD and Intel's
approaches are still "haunted" by it in different ways...but at least
fair play to Intel for attempting to do a "clean up" and start afresh
without all that nonsense that's been plaguing the PC world for 30
years...I mean, ten years ago, there were 64-bit consoles and Silicon
Graphics machines...why so long to reach the PC world? That bloody
awful real-mode addressing scheme has a _LOT_ to answer for...in fact,
everything that MS aren't responsible for in delaying the industry ten
years, it's Intel's horrible 8086 designs and subsequent "hacks" that
have been delaying things that long instead...mind you, if past
experience is anything to go by (it's not but if it were...) then
because Intel are "doing the right thing" in trying to put these
problems firmly in the past, then chances are AMD will "win" the
64-bit battle...as history weirdly always seems to choose the _worst_
choice rather than the _right_ choice...the x86 architecture _should_
be finally phased out and buried...so you can bet your bottom dollar
that that's exactly what _WON'T_ happen and AMD'll be the one locked
into keeping the x86 chip "undead" for another 30 years...what do you
reckon? A large wooden stake to the heart of the CPU might finally
kill it off? Nah, that's too easy, it's _bound_ NOT to work ;)...

As for "cleaning up" our standard libraries? Well, don't we actually
need a "standard library" that everyone actually uses _before_ that's
worth doing?

> ie:
> I don't use anymore (except external conversion modules):
> 4/15/16-bit colour text/graphics (I need 1/8/32(24)-bit only)
> I need only one 'print' (like fcprint) function.

I program GUIs and graphics routines very often (if I have a
speciality, it's this, just because I like drawing pretty graphics,
'tis true ;)...a "print" routine - other than perhaps one for writing
debugging information to a log file - is not needed by me
whatsoever...I require "print" functions where you can specify font,
font size, underline, the pixel at which to write the text, etc....and
I'd think a reasonable "clean-up" would be to drop ASCII altogether
and use either Unicode or UTF-8 or whatever, as they are "out of date"
to some people as much as older text mode stuff is to you...

You couldn't get universal agreement to remove anything but the most
useless parts (if even that is achievable) and that wouldn't make too
great a difference...and it would be much more useful, in my opinion,
if the _OS_ were "cleaned-up" instead...that would solve far more
problems to "clean-up" the obselete 1960s and 1970s techniques out of
the underlying system altogether...because, amonst other things, you
won't be able to shift some "old-skool" support out of this library
until the OS gives it up too that no-one, for sure, is using it and
needs it...for instance, while there's the "console" working in a
teletype fashion, we can't kick out "printf" as someone might be using
that...though it's total "fluff" for GUI coders because GUI text
doesn't work in a teletype manner that "printf" follows...merging
"console" with "GUI" somehow or dropping "console" altogether or
whatever is needed before it's legitimate to dump "printf" or replace
it with some GUI-based "printf" that accepts X and Y co-ordinates and
a pointer to the font as well as the text to print or something (i.e.
like Windows' "DrawText", which is a bit like a "GUI printf"...the
closest it gets, anyway ;)...

> [function-number vs. procedure]
> | Yes; The two above are essentially no different from a usage
> | perspective...except that "procxxx" is abstracted so that, for
> | instance, "procxxx" could exist on a 68K with exactly the same
> | definition..."fnxcall" couldn't do this because of "AH" and "AL"
> | and so forth, which aren't on a 68K...
>
> Ok, but as ASM is (should be?) a CPU-specific language anyway
> portability of libraries won't make too much sense.
> But I see, most ASM-tools use HLL-libraries.

Yes, this is my essential point in why I keep mentioning this...these
routines and OS API and stuff should actually NOT be dealing with
"portability" at their lowest-level...it's one presumption too
far..."portability" is naturally and logically a _higher-level_
thing...rather, write the routines in a low-level way and then there
are "high level wrappers" which add this capability _when
needed_...better yet, you could create a set of C wrappers, Pascal
wrappers, BASIC wrappers for each of their own particular high-level
conventions...

Linux almost gets it right with how it does its API (C routines versus
"INT 80h" interface), except that they ruin it all by using the "INT"
instruction to make the call to the API...which is a bad choice for
the same reasons as your "fnxcall" example was, when I was mentioning
about the extra needed with a "jump table" or "switch" to branch off
to the right API according to the AH "function number"...plus, "INT"
itself is simply a more expensive way to do things...the "relocation"
it provides can be got other ways and _should be_...because we don't
need to be paying the "relocation" price _at run-time_ when it could
all be eaten up at compile-time or load-time or whatever...plus,
"INTs" in a multi-tasking environment - because of it asserting the
#INT pin and such - is a bad choice for other reasons too...

Something in between Windows and Linux would actually work
best...there's a "low-level" interface that uses registers with a
"high-level wrapper" for HLLs and "portability" to POSIX or UNIX or
whatever...but, nope, don't use "INT", use Windows' way of CALLing
straight to each API and deal with it all at compile-time / link-time
/ load-time rather than run-time, where it's going to be expensive to
performance...I highly recommend this "hybrid" style of what Linux and
Windows do to any OS coders out there :)...

> | [ Although, there is an implementation difference here from how
> | you've written it..."procxxx" is a call made directly to the
> | routine you want..."fnxcall" requires a "function number" to be
> | supplied, so that inside the "fnxcall" there's at a minimum some
> | sort of jump table (or, worse, if it's been HLL-coded then
> | "switch" may have been used and there's a long series of
> | "if"-style constructs...good HLL compilers will turn that into
> | a binary search rather than a linear one, if it gets big
> | enough...but, still, we're comparing "doing a search" (however
> | fast) with "no search required at all"...the latter is
> | guaranteed to win - "the fastest code is the code that never
> | executes" - however clever you are with your look-up ;)...the
> | need for a search is also logically redundant...that is, the
> | programmer already knows what they want...so, if you lay out
> | each option so that it's directly accessible then the search
> | can be done by the programmer during development - looking
> | through the list of routines for its name - and is not
> | necessary at run-time...
>
> Right, function-numbers aren't much faster than pushed
'class-ID/msg-type'.

Well, more than that...there's a middle ground - a hybrid between a
BIOS interrupt and a Windows call - which _is_ better than them
both..."function numbers" are a logically redundent thing...Windows
makes no use of them at all but rather links things up at link- and
loader-time to make, I suppose, a "custom jump table" for that program
to use to all the API...changing entries in this "jump table" is how
you re-locate and other than making the CALL indirectly through the
"jump table", there's no run-time penalty for this process at all (and
if you wanted to be really fussy about this, then we could "loan" what
a DOS MZ executable does in having a big list of what needs to be
relocated and the loader literally changes the operands of the CALL
instruction directly to point to the right places...but the gain is
not great and the effort to implement more tricky that going this far
is probably overkill :)...

We'll "borrow" this from Windows because it actually does things
better in this one context (but loses all that advantage with all the
other HLL nonsense it insists upon)...so, no "function numbers"...but,
_yes_, we're otherwise doing something like a BIOS call where we load
registers and not the stack and so forth...it's a hybrid...a little
bit of each but different to them both...

This "middle-ground" does the best job...and, also, to handle the
"relocation" issue, there's an alternative way to consider...using
something like COM, the whole system could have everythign split up
into "objects" and "interfaces", passing jump tables around...and then
the program simply uses the "pointer to a jump table" to pull out the
function it needs from this table and makes a CALL to it...then the
relocation is handled at run-time but costs no more than an indirect
CALL (which was the best we were managing to do, anyway)...you can see
this in using DirectX - which follows COM - because you actually only
need to import _one_ function from a DLL (something like
"CreateDirect3D8" :) and that's only really to load the DLL in and get
the first "jump table"...thereafter, the code itself provides
functions to other jump tables and so forth...a DirectX program's
"imports" are only things like "CreateDirectSound", "CreateDirect3D"
and then all the rest - including the implicit ability to "relocate"
code - is handled by the way COM itself works...note that it _doesn't_
strictly have to be "OOP" and pass a "this" pointer...that element is
for COM's OOP stuff...for this low-cost relocation-on-the-fly, all
that's actually required is these "jump tables" to library / API
functions...

For example, when an OS starts a new process, EAX has a pointer to a
jump table "object" that contains functions like "LoadLibrary",
"FreeLibrary", etc....thus, the program can CALL via EAX to these
functions to load in some other library and the return from the
function is, yup, another "jump table" object that has all the
functions in that library...and perhaps that library has a
"CreateFile" function which returns a "jump table" to all the file I/O
functions...there's neither any need for "function numbers", using
"INT" nor adding in a whole bunch of "imports / exports" that bloat up
the executable...simply, the program itself is written to _expect_
that the library / API functions could be located anywhere and so uses
the "jump tables" provided to find the function addresses...

But this isn't actually COM so there's no "HLL" stack
thing...parameters go via registers...if you want "portability" then,
instead, you call in a "wrapper" library that works this way and it
will call the true low-level interface on behalf of the "portable"
program..."portability" is not part of the library / API itself
because it's, as I say, an implicitly "higher-level" thing...C / C++
programmers, though, will just use their high-level library and can
remain blissfully unaware that there's a low-level interface...this
really doesn't effect them or get in their way at all...I mean, how
many Linux C / C++ programmers are aware that there function calls are
actually ending up as "INT 80h" calls? The "wrappers" there provide
the "portability" and "POSIX compliance" but it's all quite optional
in that you can completely ignore that and make the "INT 80h" call
directly and make the choice that you want better _performance_ than
"portability" (although, as noted, the use of "INT" in Linux sort of
spoils that whole thing by not being the best choice of actually
calling the API)...

And as for "this" pointers, that's not necessarily either, unless this
library call really is an _OOP_ call...which is also the convenient
thing about this method...you turn it into an OOP function by simply
having a "this" pointer in EAX or something...if non-OOP then it
doesn't...but they are otherwise identical...that's nice and simple
and consistent and non-conflicting :)...

This, to my mind, deals with relocation, "portability", high-level
interfaces while never once demanding that the high-performance ASM
coder has to compromise on anything whatsoever (the sole "compromise"
is that it's an indirect "call [ eax ]" rather than a direct "call
$4000" instruction...but other than going through every single CALL
instruction and manually changing each and every address operand, you
can't do relocation with any less run-time penalty than this...the
"indirection" is implicit from the fact that you want to
"relocate"...I mean, when you make an "INT" call, it's doing exactly
the same thing implicitly through the IVT / IDT interrupt table...when
you use Windows, it actually makes a "custom jump table" of the API
you "import" to CALL...it's _implicit_ in what you want done that this
"compromise" is going to be present _somewhere_ _somehow_...that's
what this "relocation" stuff is, effectively ;)...which sounds like a
winner all ways round to me to keep our VB programmers perfectly happy
to use this stuff but without demanding that you, wolfgang, have to
suffer some horrible HLL bloated nonsense...I suppose all that's
needed is a very clever library / API design...which, of course, was
the original topic here so I'll shut up about this to get back to that
:)

> 'My' modules know the exact entry-point anyway,

Hard-coded?

The problem with this is that future modifications may move library
functions around and you have to re-compile...of course, if you can do
this, that's great and the best way...but if your library just happens
to be "KERNEL32.DLL" or "OPENGL.LIB" or something then it's not
practical to re-compile tens of thousands of applications, just
because, ooh, "CreateProcess" (which maybe, most of the applications
are never actually using) has moved by 16 bytes because the function
before it had a few instructions added to improve its performance...

What is possible with some "own system" like what you have isn't
always possible in a wider context where you don't have the ability to
just re-compile things...although, in fact, the more you add to KESYS
in terms of applications and the more changes you might make to
improve performance, the more awkward hard-coding addresses will
become...that's why all these other systems simply don't (in fact,
arguably "can't") just hard-code addresses...if all other things were
equal then hard-coding _would_ be the best way...unfortunately, all
other things are NOT equal, which throws a spanner in the
works...although, as I've shown above, I've been thinking things
through on this and the above stuff "loans" from different approaches
to try to get the "best" that demands the _least_ compromises from any
party...using "call [ eax + 12 ]" is only a minor compromise, compared
to Windows' HLL stuff or BIOS / Linux "INT" and "function numbers"...

> but the function-numbers make sense for mixed real/P16/P32 code,
> so the function-numbered call actually invokes the linker.

Well, if we're talking about "clean-up" then why are we still using
any "real" or "P16" code at all? Isn't that mostly old "obselete"
stuff that we can save a packet by simply "cleaning up" and leaving
out altogether?

And, actually, all the methods proposed can deal with this in a far
more intelligent way...as mentioned, all the methods (except
hard-coding) use a "jump table" of one sort or another (the IVT / IDT
is just a "jump table", Windows' "imports" are just a "custom jump
table" and my stuff is literally a completely undisguised "jump table"
solution :)...so, you want to cater for real / P16 / P32 code? Just
fill up the "jump table" with the corresponding addresses to real /
P16 / P32 code...job done...and no no need to "invoke" any linkers...

> [stack frames vs. register]
> | Only ISRs strictly need the callee to preserve / restore
> | registers...and these tend to be either forbidden under an OS or
> | are going to require other exceptional treatment - "IRET" rather
> | than "RET", acknowledgement to the PIC, etc. - that these are
> | left as "exceptional"...all other types of procedure, though,
> | would actually benefit in some instances from the reverse
> | attitude...the _caller_ has responsibility to save / restore
> | what's important to it...the callee proceeds as if _all_ registers
> | are free...worst case, it's equal to the callee having the
> | responsibility...but, in the best case, we can save / restore
> | over multiple calls to procedures (far more typical arrangement
> | under modern "layered" OSes like Windows to be making a series of
> | calls in a row)...
>
> My code follow simple rules:
> keep ebp to point to the centre of the system-variables/flags
block,
> routines may alter (return-value) all registers except ebp/esp,
> push/pop saves are performed from code-parts who needs to do so
only,
> local variables ([esp+xx]) are created only 'within' a routine,
> and for sure only if really no more free registers available.

Yes; _IF_ this were a case of code that I _completely controlled_ then
I'd know what registers need to be stored / restored and would _only_
deal with those...and when it's possible to pre-calculate where ESP is
(and I can be bothered to do so ;), then, yup, I'll offset off that
and free up EBP...and so on and so forth...

But when dealing with code that's outside of my control...where, for
instance, someone is trying to run some Beth95 OS code on the new
Beth2K OS, then some "binary compatibility" has to be present or it
simply won't work...

Also, one big problem with the "EBX is destroyed" style of doing
things in older documentation - that lead to it vanishing
(unfortunately, they all ran to C calling conventions and stuff, which
is running too far ;) - is that if I then want to improve this
routine, I may have to use some more registers or what-not to get it
to perform better...but that changes around which registers are
destroyed and which aren't...in OOP-speak, I'm violating "information
hiding" by openly revealing the "internal details" of the
routine...and, though OOP is also full of lots of crap theoretical
talk, lots of it is based in _practice_ and this is one example...you
might not see the problem immediately (millions didn't and old
documentation really did have "EBX is destroyed", listing out the
specific register stuff for each API so that _only_ those that really
need preserving are preserved)...but then if you later try to improve
the routine and realise that you could make it far better by also
using EBP (trashing it), then if you run this against older code that
was written assuming EBP _wouldn't_ be trashed (because the old
documentation says that's fine :) will blow up ungracefully...oh dear!
:(

Thus, the above set of "rules" are my attempt to do the _minimum_ to
avoid such future problems happening _without_ demanding too much of a
compromise for the speed freaks to make...as I say, the problem has
been that such problems _did_ happen and then everyone went rushing
off to using HLL methods all the time, all over the place...which,
yes, guarantees that you avoid these problems but, well, they were
right to run away...it's just they ran far too far straight towards
"bloatware"...and my "rules" above - and the general stuff about
"relocation" and so forth - are, as I say, my attempt to find that
perfect "middle ground" that pleases both groups as best as
possible...

And seeing as you're thinking "oh, that's not too bad" when you are
clearly a very "specific" "speed freak" kind of programmer (hex
coding? Writing your own OS? You're sort of the definition of a "speed
freak" programmer at its extreme ;) then all I'd need is for Randy (or
someone else...I just say Randy because he knows this stuff better
than most on here...the group "expert" :) to also approve it from a
"software engineering" "HLL" viewpoint and that means I _did_ succeed
in finding a good "compromise"...then, once "approved", it's in the
public domain for any OS / API / library to use as they see fit ;)...

> [...documentation that lists "ESI is destroyed..]
>
> Yes, my docs look a bit like RBIL :)

There can be a nasty problem with that, mind you, which I've mentioned
above...although, everything you do is "own code" so some of the
issues don't apply...but, more generally, there is a potential problem
that "improvements" can render the documentation useless...and, most
importantly, older code will start to not work with the "newer
improved" library functions because in changing them to improve them,
the registers trashed may change around...and if you insist that they
don't then you're stepping on your own toes...like you write "EBP is
preserved" in the documentation then realise you can double the speed
by using an extra register and, oh look, EBP is free for that...but,
oh dear, if you now use EBP then it's _trashed_, not "preserved" as
the older documentation said...and older programs will have been
written according to that older documentation, not knowing how the
routines would change in the future...so the program is storing
something in EBP, thinking that this is okay as the routine doesn't
trash EBP...are you starting to see the little problem that could
happen here? Older code has to be re-written and re-compiled...either
that or you're putting shackles on your own ankles as to what you can
do to improve a routine because to keep with what the older
documentation says, you'll now have to "PUSH EBP" and "POP
EBP"...which defeats the whole purpose of why we went to the effort of
listing out which registers are "destroyed" and which are "preserved"
so that we didn't need to do any unnecessary "PUSH / POP"...

> | What's left to consider?
> []..."toolmaker's view" really is the most sensible
> | because it provides for _BOTH_ requirements by offering
> | _CHOICE_...it's not "low-level and the HLL people be damned!" nor
> | "it must be portable and low-level performance be damned!" either
> | :)...
>
> Agree! Let the programmer decide...

To be fair, other systems have long since got this message, but not
"control freak" Windows...and Linux, though it has both levels,
doesn't really take full advantage of it properly...and some libraries
do have the "wrapper" idea but tend to be rare or are useless
"VisualBASIC wrappers" over _C_ interfaces, which is, like, not much
of a choice between HLLs...

What's missing is that the idea of "let the programmer decide" should
be as widely shouted and used everywhere as "portability" (wrongly)
is...if you like, "let the programmer decide" (Liberty) should be the
thing people praise and seek, not "portability" which is a false god
pretending to be Liberty when it's actually the opposite, being a
tight restriction...

> | Parameters should generally go directly into registers...
>
> Yes, but I wont recommend a strict order or an 'overflow'-register.

For my own code, neither would I...having anything "fixed" restricts
the flexibility...but, as mentioned, these rules are "compromise"
rules to give the HLL people their "binary compatibility", "backwards
compatibility" and all that nonsense...

In fact, in situations where there is no need to "compromise" at all
then there should be NO RULES but what the programmer makes...but,
well, when you have lots of different code by different people all
working together, it's got to have some "rules" or it can't work at
all...my attempts here are to devise a "minimal" set of "rules" that
all should be quite happy to agree on...hence, why I make the odd
"HLL-friendly" compromise (although, the vast majority are simply
shipped outside into "wrapper" functions because that allows the HLL
people to have whatever "portability" they want without it forcing
every program and the OS to waste time being "portable" in places
where it probably is useless and doesn't apply...if the HLL coder has
to bring in the HLL wrapper library then the _programmer is deciding_
that they want this and will accept that it's not quite so good
performance...it doesn't get in their way at all...in fact, as
"wrappers" could be tailored to each individual language and package
then it could actually be _better_ for them...but it also doesn't get
in the way of "speed freaks" wanting to avoid all redundencies to push
the machine to its limits :)...

> I work with a standard register usage:
> EAX gp/error-code/function-return/msg-ASCII-quads/..
> EBX LBA-sector/menu-CSRS/grid-CRSR/enum-return/X-graph/..
> ECX counter/size/sub-index/Y-graph/..
> EDX offset/sub-size/sub-index/screen-position/graph-angle/..
> ESI source-ptr/parameter-ptr1/..
> EDI destination-ptr/parameter-ptr2/..
> EBP L1-cached, systems area and operand buffers
> Carry: error Zero: empty/done NCNZ: (cc:nba) OK/continue

Yes, that doesn't look too far from my preferred ways to use
them...that is, when all other things are equal because, for instance,
under Windows and HLLs, all the return codes come in EAX and so I've
got no choice there and have to use "cmp eax, SomeValue" rather than
the much more convenient and faster "JC ErrorRoutine" (where
"ErrorRoutine" can deal with error codes in EAX :) after a
call...using something like "JC" or "JZ" is much nicer, faster,
smaller and cleaner way to deal with easily branching when an error
happens...so, I'd rather that...but when dealing with Windows and
HLLs, they don't do things this way that there's no choice where they
want to pass things to me from...

> | Is this getting pedantic for the sake of pedantic over a few
> | clocks and a few bytes? I'd say: No, it _isn't_...
>
> [..] agreed.

Oh, well...at least there's one person sufficiently mad in this world
to agree with me...hehehe ;)

> | > Shared between processes or between CPUs?
> | I presume whatever the underlying OS provides to support that
> | (remember, wolfgang, under the Windoze OS, you have to do what Big
> | Brother Bill tells you to do ;)...
>
> :)

Well, more like:

:(

...when you actually have to do what Big Brother Bill says all the
time because he can be such a big old "meanie" ;)

> [the not so common formats...]
> | It's one of those "where do you draw the line?"
>
> I'd try to put the line as far as agreeable...

Me too; But the problem is that "agreement" is something that's in
incredibly short supply...and, generally, you have to be the first
prepared to "compromise" or the other people simply won't move at
all...it's a terrible human condition - that can be seen in many
conflicts like Northern Ireland, Isreal, etc. - that people generally
make up their minds on something, then stubbornly stick by it come
what may...always saying "I'll make my compromises, once my enemy does
so first"...and, of course, when _both_ sides say that, absolutely
nothing can and does happen...a "Mexican stand-off", "Mutually Assured
Destruction", etc....even when this lack of compromise is _killing
them_, humans are still unwilling to ever change or even make the
smallest concession...because, of course, it's like: "then he'd be
'winning' and I can't have that"...it's some "stags locking horns"
animal instinct, left over from primate days...unfortunately, even if
it's "obselete", it's still there and people stick stubbornly to it,
come what may (in fact, right now, I predict there is someone who
doesn't agree and is getting enraged and stubborn and will want to
fight me over it and so on and so forth...*yawn*...even though it will
do nothing useful...well, except _prove_ that I actually was right all
along...hehehe ;)...

> | > btw: Unicode is needed for the Asian area only,
> | > western civilisations may satisfy all needs with the
> | > extended ASCII-set.
> | > Ok,ok, I'm aware to start a new sub-thread-discussion with this
:)
>
> | Doubtedlessly, because I'm about to step in because of the
> | comments ;)...
>
> | The "Asian area", as you put it, is covering quite a few "target
> | demographics", as the marketeers might put it...there's at least
> | Israel, Russia and Japan which could (nominally, at least) be
> | called "Western" (or, if you like, "effectively Western", if
> | that's better cultural politics) but who need non-Latin scripts
> | for their languages...
>
> | And ANSI (extended ASCII) doesn't totally cover even all European
> | possibilities completely...
>
> Sure, of course not all at once,
> but as I'm (beside many others) unable to decipher Greek or Russian
> characters, and I wouldn't know how to spell a dashed Polish "L" or
> a Spain "N"-variant and all other non-international characters,
> I'd see more sense in a local interpretation for ASCII >128.

The problem with that is, for example, I've just used WGET to download
a "teach yourself Japanese" website (no, no particular reason...just
curiosity and to be able to at least read basic stuff to get an idea
of what's going on)...and, of course, for this application, I need
_BOTH_ English and Japanese characters at the same time (well, at a
minimum, I need both for the "how to read Japanese characters"
lessons, up until there's enough taught that the lessons themselves
could be in Japanese...but seeing as I've only just downloaded the
stuff then that's a while away, I think ;)...

Zusätzlich, benötige ich die deutschen Buchstaben manchmal...

But these might not be available in the UK code page...for instance,
Rene used the "§" in his RosAsm (but, also, luckily, uses "$" as a
substitute)...well, to get at this character in order to put it in my
posts, I had to use "character map"...it's not on the UK keyboard (and
I don't think it's on the US one either, is it?)...whereas, I can type
"£" easily because, obviously, the UK currency symbol is given its own
key on UK keyboards but other places - like the US - will have to go
searching character map to find it...

Plus, you're _still_ thinking in a Latinised way...how do the Chinese
/ Japanese / Koreans fit _thousands_ of ideographic characters into
ASCII >= 128?

Nope, something like Unicode _is_ needed by very many people...even
though, sure, there's many situations where "code pages" will do
(after all, "code pages" did work okay when they were in charge
:)...note that if you use UTF-8, then that actually _IS_ "ASCII
compatible"...that is, the characters < 128 are standard ASCII and
then it uses multi-byte sequences where byte > 128 to access the rest
of Unicode...so that encoding would give you something like you
want...

And, actually, here is _exactly_ where the use of libraries comes into
its own...not a language expert and don't want to really become one?
Then grab someone else's string handling library that has already had
it all worked out ahead of time...the problem, though, is that people
who say "no" to libraries are going to have a problem here...because
this isn't like other libraries where it's just a question of
re-writing it...you also need to know the _information_...although,
you can look at the Unicode tables and make your own, this is not a
five minute job to do it properly...

> | ..but, again, Japan has no such cultural issues, as far as I'm
> | aware, and they absolutely Adore their high-tech gadgets that
> | there's got to be ASM coders around...
>
> Yes a good point. But as books, docs and international communication
> are already that far bound (and almost worldwide agreed) to use
> English?

Yes; But there's a difference between a "Lingua Franca" and
"localisation" (US: "localization"...oh, the irony! ;)...

For instance, you could write your replies to me in German and I would
be able to follow along happily (though don't expect any miracles in
German reply from me ;)...although, here's some madness for you: You
could write to me totally in German and I could reply totally in
English...and, yup, between you and me, we'd be able to hold a
perfectly reasonable - if weird - conversation...that would be
"localisation" when we only consider between you and me, as I'm
tailoring things for you and you are tailoring things for me...

But what about _everyone else on the group_? Many won't be able to
follow along with your German replies properly...hence, the "Lingua
Franca" of this group is English to ensure that everyone can follow
along the discussions (it's implied with this group that it's English
language...for other languages, there is, for instance, a German
language CLAX :)...

So, yes, the "Lingua Franca" has been agreed as English (oh, I still
Love the irony of that, considering what "Lingua Franca" translates
as...but that shows how times change...a Latin phrase saying "the
language of the Franks", which, if anything, should be French, as it's
called "France", "Frankreich", etc. for the obvious reasons...but now
the "Lingua Franca" isn't French and no-one speaks Latin anymore
either but for small phrases like this...amazing how much things can
change, eh? ;)...

But "localisation" (US: "localization") is a different
matter...there's no agreement - nor should there ever be - for the
Japanese to start speaking and writing English in their own
country...and, anyway, if we're talking about the world speaking but
one language, then Chinese _still_ holds the weight on numbers of
people who speak it, that English, in a fair fight, should not
actually win, even if all us here would prefer that to Chinese because
we have no idea how to speak that language...

> I'm sure about some ASM-friends from Japan are with us :)

Well, yeah sure...it's just I've not noticed any Japanese people
writing (of course, they _could_ be writing and just not mentioning it
or something)...it's not a big deal, I suppose...if they are, they
are...if they aren't, then they aren't...it's just something I noticed
because I've seen posts from many places but some countries seem to be
absent...now, some countries have a reasonable explanation (like, we
got through a post from China once but that person mentioned that they
weren't really supposed to be here because of political things...and
very poor countries probably ain't going to have many ASM programmers
when we're enough of a rarity in Western countries, anyway ;)...

I'm just interested, you know, as to why I've seen plenty of German
and Russian posters but what about "hacker central" countries like
Norway, Sweden, the Netherlands and that sort of thing...again, I'm
not suggesting there's no-one...just you'd expect to see more...

One obvious thing, of course, is that Germans are taught English well
at school and, correct me if I'm wrong, but Russians are too (even
with the Cold War, where you'd expect not)...not that other countries
aren't taught English but perhaps not taught it so well for them to
feel totally confident, perhaps?

Mind you, I actually have NO IDEA what's going on...this is all just
purely guesswork...it's just noticing the sort of "gaps" here and
there geographically (but, as I say, Japan is highly high-tech that it
can't be because there's no ASM programmers at all in Japan...that's
just _not_ possible, yeah? ;)...and then just wondering why it might
be...chances are, I reckon, on it being about, perhaps, confidence in
English...Brits, Yanks and Aussies obviously have no problem with
that...Germans are well taught English in school (and, well, English
and German are actually also close cousins language-wise...we share
half our idioms in common, for instance, and those tend to be highly
"culturally context-sensitive" that, for example, "taking someone
under your wing" is easily understood by Germans and English alike
because we say the same basic idiom...whereas, another language might
be totally confused by the above - because taking it literally means
something quite silly - and have some "four sheets on the tongue is
better than nine" saying instead...which sounds quite silly to us
lot..."swings and roundabouts", as they say...well, as they say, in
_SOME_ countries...others may say "see-saws and rocking horses" to
mean exactly the same thing ;)...

> | ...but I find the "internationalism" strengthens things
> | ...that I'm thinking "the more, the merrier" :)
>
> Yes, but would you start learning several thousands Chinese
> 'pictures' just to give Unicode more sense ;)

Well, no, not to give Unicode more sense...but I _am_ thinking of
learning at some of the "pictures" for Japanese because I do have a
fondness for their whole way of doing things...I don't know, maybe I
was Japanese in a past life...I just find their stuff cool and
stuff...and the German I picked up while over there has been
interesting and useful that, like, I'm interested to have a look at
other things too...

Sure, I'll never be fluent in these things or anything...but even
basic appreciation of, say, the alphabet is groovy...for example, with
Russian, lots of otherwise weird-looking words suddenly become
familiar when you can just "decode" the letters...for example:

??????

What's that? Looks odd to a non-Russian, right? Okay, let me give only
two pieces of information and you'll recognise what the word is...the
letter that looks like "p" is actually more equivalent to and said
like "r" in English...and the first letter is said like "D"...

So, now it's:

D????r

Like often seen in German, the "k" is synonymous with an English "c"
in most places...so, we have: "Doctor"...and if you _heard_ someone
speak the above word then you'd recognise it easily as it sounds the
same (accepting accents ;)...

So, like, not being fluent ain't such a big deal because I'm
interested from a learning point of view at looking how all these
things work and relate to each other, rather than going to live in
Russia for the next three decades or anything...

> [*direct I/O ...]
> | > Think of VXD and then disassemble all those DLL's
> | > (I need to do this whenever I decide to use a new add-on
> | > hardware).
>
> | [ Legally, of course...due to the European legal exception that
> | disassembly _is_ considered permissible where there are no other
> | reasonable sources of information under certain
> | circumstances...nudge, nudge, wink, wink ;) ]
>
> :) If disassembling of bought and paid code once will be prohibited
> by law, I will become an outlaw as of immediate!

Well, be thankful you're part of Europe because our rules are more
relaxed than America's on these sorts of "I own it all to make lots of
money!!!" patent and copyright things...though, of course, the Berne
Convention is common because that was an agreed treaty over how to
deal with internationally...

> [snipped our ranting chorus about existing API-code :) ]

:)

> [direct I/O and portability..]
> Yes, agreed.

:)

> And I try to repeat with my words:
> Faster, smarter, shorter HW-drivers, libraries and API-code
> doesn't necessarily mean the loss of portability.

Well, the thing I try to point out is that the very concept of
"portability" is highly nebulous...what exactly do people mean?
Because, in truth, "portability" is a many-faceted thing...and there's
degrees and measures (for instance, Unicode define different "levels"
of "conforming implementation" because, well, they know asking for
everyone to put in all the complicated stuff about Arabic font
rendering and so forth is a bit silly for every single program, when
many programs won't be needing it (even if, yes, international word
processors _couldn't_ ignore these things :)...so they have different
"levels" of "conforming" to account for this :)...

The essential problem, as I see it, is that people realised "oh,
portability is an important thing" (when no-one thought about it at
all and all machines were completely different - no PC domination -
and everything was blowing up and crashing everywhere! ;) and then
immediately rushed from having _no portability at all_ into making
everything "portable" in every single way and each layer is "portable"
from other layers and so forth...the old problem of going from one
extreme to its complete opposite...from no "portability" at all to
"portability must be everywhere!!!" obsessiveness, blindly worshipping
it as being capable of everything..."C is great!" / "Why?" / "It's
portability magic!!!" / "Portable = infallible perfect god??? How does
that work?" / "It doesn't 'work', it is godly 'magic' put into all
HLLs with a magic wand!! Which is why ASM cannot be 'portable' and
'magical' like the supreme HLLs!!! And if you are not 'portable' then
you are an evil demon of hell!!!"...oooo-kay, whatever you say...

Beth ;)