Re: learning asm.

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

Date: Mon, 10 Nov 2003 03:31:28 -0000

ernobe wrote:
> Beth said:
> > My point here is that the video system should _ALSO_ be hanging
off a
> > hardware IRQ on a PC system...
>
> Is this your only real, justifiable argument against software
interrupts?

Not at all; This was my _clarification_ of your miscomprehension of
what I'd said...though there is no great fault there because, yes,
both are referring to as "interrupts" because they use the same
interrupt system of the CPU...even though, in practice, they are used
for quite separate things...and my point was that, for one thing, they
are great but, for the other thing, they can be used, yes, but there
are better options...

You've - dare I say "carefully" - snipped the actual points about
software interrupts I made in that post...in fact, you seem to have
chosen to address the most unrepresentative part of my post...oh,
well, whatever...it's your perogative...

But, if you like, we can discuss the inherent limitation of 256
interrupts...of which, a hardware IRQ for both PICs must be taken out
of this, so we're down to 240 interrupts...therefore, with any
reasonable sized OS API, you cannot devote one interrupt per API and
this wouldn't be leaving any scope for much flexibility or extension
later too...something like the Windows API with 10,000s of functions
all over the place most certainly could NOT fit into 240
"slots"...neither could X Windows along with the Linux API, just to
point out that this isn't an "MS only" thing...

And the point here is that, therefore, we have what we tend to find in
that a "function number" is passed to the INT (in EAX/AX/AH by usual
conventions)...at a minimum, this will therefore require a jump table
or similar mechanisms on the other side of the "INT" in order to
branch off to the required API function...if not all the potential
EAX/AX/AH "slots" are filled (very likely with using EAX or AX as your
"function number" register...especially because you'd want to be
leaving some room for later "extensions", presumably), then there
should also be validation code on the other side of the "INT" that
checks that the "function number" is actually a valid API within the
bounds of those API provided...

Then there is the fact that an "INT" command triggers the interrupt
system which isn't the fastest method of transfer...it'll require an
extra doubleword of stack space for the EFLAGS too...remember that
these are all new points in _addition_ to the ones stated in the last
post (and there's a few more I'm considering but I'd want to make 100%
absolutely sure with the CPU documentation that I've got the interrupt
system issues correct before I'd mention them)...

Yet the sole plus point for using "INT" for OS API is that
"relocation" is taken care of implicitly by the IVT / IDT
table...that's not really a good enough reason to use it, in my
opinion...the interrupt system would be better devoted solely to
hardware considerations and the "INT" instruction merely used in the
rare occasion where software might need to generate a "fake" event for
some reason or something similar...you _can_ use the interrupt system
for these things, as it will "work" but I'd say that, under a
multi-tasking operating system, it would be "ill-advised"...

Other methods work better; Rather than use the interrupt system's IVT
/ IDT "jump table", the OS provides some sort of mechanism for its own
"API jump table"...this could be (and is) done in many ways...Windows,
for example, employs two notable examples...the "imports" of a program
are listed in the header and the loader creates the required "jump
table" at load-time, which the program then uses...

Also, with COM-based interfaces, we see the OOP-style method of
actually passing around "jump tables" attached to specific
objects...this method is actually quite good in that the API interface
can be all one big "jump table" (say, at program start, EAX is loaded
with the address of this massive API jump table and then a program may
proceed to CALL indirectly via the addresses provided in that
table)...or it can be split up into convenient "groups" or "objects"
(say, when calling the "CreateIcon" API, it returns a new "jump table"
to the API that manipulate icons...allowing the API to be separated
into convenient "groups")...

Note that using a "this" pointer with these API like in COM is not
specifically necessary...if you'd prefer not to or the API does not
work in such an "object" fashion then it's really the "jump tables"
that are significant here...that is, they could all be full of
"static" functions, to use C terminology and operate in the more
traditional manner...adding some form of "this" pointer to the
parameter list of an API, though, begins to allow the OS to work in an
OO fashion...of course, a "static" function that has some sort of
"handle" parameter _is_ really object-orientated, even if not formally
so or admitted to...for example, if the "DrawIcon" API (found in the
jump table returned by the "CreateIcon" API :) takes a parameter that
somehow references some icon somewhere in the system then that's
merely a "this" pointer "in disguise", so to speak...strictly, though
most OOP implementations use memory addresses for "this", it can be
_any_ type of unique reference, in fact...

Thus, in fact, I would resist specifying it as specifically an OOP
method here...they are "static" functions unless the API's parameters
want to add some sort of "this" to their list...as this more general
way of defining the mechanism allows either to be "mixed and matched"
as is suitable and preferred by the API author...

But, in the end, the whole thing is a "relocation" issue...that is, we
can't "JMP" or "CALL" directly to memory addresses for OS API because
those addresses may be subject to change (e.g. a newer version of the
OS has improved the API so it's now bigger / smaller...or the API are
demand-loaded libraries - like Windows' DLL files - and may be
effectively loaded into different memory locations that fixed
addresses in a program won't be acceptable)...a bit of "flexibility" -
one layer of "indirection" - needs to be added to any calls to API
functions so that they may be effectively located anywhere in
memory...

With the "INT" instruction, this "indirection" is implicit in the
interrupt system...the "INT" vector number is not itself an address
but an _index_ into a "jump table" of addresses...therefore, the OS
sets up its own interrupt vector with the required address and
programs can "INT 21h" or "INT 80h" happily...the actual address of
the "INT 21h" code can be moved elsewhere but as long as the address
in the IVT / IDT is changed accordingly then this poses no problem...

This is the essential reason why the "INT" instruction is used for
this under some operating systems...it has implicit "indirection" in
it that makes relocation easy...but, note, that the only real
component here of interest is the fact that "INT" does something
similar to a "PUSHF; CALL [ offset IDT + (Vector *
sizeof(VectorTableEntry)) ]" implicitly...it's naturally indirecting
via a "jump table"...

Well, instead, the OS can employ its own method for providing an
appropriate "jump table" (or "jump tables", if you want to separate it
out into "groups" and "objects", perhaps) and then the application can
directly issue "CALL [ offset APIJumpTable + (index *
sizeof(OSJumpTableEntry)) ]"...note that there's no "pushf" this time,
which is usually entirely unnecessary for calling OS API and is more
redundent "overhead" for using the "INT" instruction here, where it's
not particularly the best method...

Note very carefully, though...I'm NOT talking about an OS completely
using the Windows style "HLL" calling conventions at all...don't think
"Linux uses INT 80h, Windows doesn't...Beth is saying don't use
INT...therefore, she's saying to use Windows conventions and not Linux
ones"...because that would be a false conclusion...

What I'd ultimately suggest would be that this hypothetical OS API
would load parameters into registers and use an "overflow" register
that points to memory, if there's an API that takes more parameters
than available registers...that is, just like Linux's "INT 80h"
interface...it makes an indirect CALL via the "jump table" (however
that is ultimately decided to be provided to applications by the
OS...there are a few possibilities - fixing an OS "jump table", like
it were some "personal IDT" for the OS API at a fixed address...or
passing the address of this table to a program at startup in a
register...or having the loader create the "jump table" from "import"
names, a la Windows' imports...or whatever (and any of these may be
"cascaded", in that an API function itself could return further "jump
tables"...thus, these schemes are easily extended to use OOP "objects"
or merely just to "group" related API for convenience or whatever) -
but it's the "jump table" aspect that's relevent here)...I'd also use
some of the older conventions, such as an error being signalled by the
carry flag so that a simple "JC ErrorRoutine" after every OS API call
can be added for branching on errors (EAX or whatever can then
function as the "error code" or something) rather than the "cmp eax,
ERROR_FILE_NOT_FOUND; je ErrorRoutine" style of sequence common in
some places...

Note that, yes, we can use registers and we can use the carry flag and
so forth because I'm talking about a _specific_
interface..."portability" is NOT a consideration at this particular
level...but it's NOT being forgotten either...for every OS API, there
can be an equivalent C library function that "wraps" the raw API call
for HLLs to use this interface in a "portable" way...I'm actually NOT
kicking out "portability" requirements altogether...I'm just rightly
placing them as "higher level considerations"...NOT in all instances
is "portability" necessary...thus, not in all instances will
"portability" constructs be applied...the matter is left open as a
decision that the _developer_ takes as is appropriate to their
application, not as some "ivory tower" system-wide decision made
"blind" by the OS author...as far as is possible, choice and Liberty
should be provided...this is, in fact, _crucial_ and _central_ to any
"toolmaker's view" OS design...

For cross-OS capabilities, then the "higher-level" C wrapper interface
is simply standardised - a la UNIX clones - so that the same C source
that chooses to use the "wrappers" for "portability" reasons will
happily compile on other "compatible" platforms that employ the same
API and wrapper interface...this is, of course, _exactly_ how C / UNIX
/ HLA and so forth all provide their "portability" too...the
difference here is that it's an _optional_ thing...note that Linux is
_already_ doing something similar with its C-based and "INT 80h" based
interfaces...if you use "INT 80h" then it won't transfer well - won't
be "portable" - to other UNIXen that don't use the "INT 80h"
interface...whereas, if this requirement is important then, instead,
you use C and you use the C-based interface and, yup, that source code
happily recompiles on all the different "compatible" flavours of
UNIX...

This stuff _ISN'T_ "magic" and, suitably, I'm suggesting that we grab
that large curtain and pull it down to _expose_ the "Wizard of Oz" as
his very un-magical self...by doing things this way, we can have an
optimal API calling method (there would also be further methods
employed _inside_ the OS API in order to attempt to reduce "overhead"
there too) but, nope, there is actually NO NEED to completely forsake
"portability" and all those other "fancy features" that many operating
systems provide...

In fact, what I'm specifically doing here is breaking it open and
laying it out flat and _exposed_...rather than bundle things around
with a "high-level" interface only, it is broken up and laid out
flat...there is the "raw" interface which is, yes, platform-specific
and just goes _directly_ about its job with the absolute minimum
"overhead" possible...if you need _performance_ and you will take
"portability" on-board yourself or find it acceptable for it to even
not be portable at all (e.g. it's some "here today, gone tomorrow"
cheap and cheerful game or simple application and you really don't
care in the slightest about "porting" it to an Apple iMac or anything
like that) then you can dive straight into the "raw" interface...note
the important point, also, about "you can take the portability
on-board yourself"...because, in fact, there is more than one method
to achieve "portability"...instead of the OS "magically" providing it
for you, then you can, instead, simply separate out those parts that
are OS-specific from which aren't and write your own "portability"
libraries and so forth...for example, HLA provides Windows and Linux
"portability" because Randy has taken the time to write just such a
"portability" library...in fact, that's exactly what C's "stdlib" is
doing as well...an OS can actually be _totally_ "non-portable" in its
provided interface but using such a method - taking the "portability"
issues on-board yourself with your own code and devices - then this
stuff is _also_ perfectly possible and would work just as well...

Hence, as I say, "portability" is a _higher-level_ consideration...it
shouldn't be bound and bundled with the OS API directly...there is no
need to do this specifically and it _forces_ all applications to
choose "portability" rather than "performance"...this "portability",
mark my words, _COSTS_...you are incurring often substantial overhead
with every API call...in Windows, in fact, the cost of API calls
because of NOT taking this "toolmaker's view" attitude to the design
is often stupidly massive...oh, and before anyone jumps in with the
"but it's only a few clocks here and there lost to overhead and
machines are fast", this is not actually the point at all...it's a
relative measurement..."the fastest code is the code that doesn't run
at all"...it's not the absolute speed but the _relative_ speed, if you
will...minus "overhead" is always faster than with "overhead"...and,
as I'm trying to point out, when that "overhead" is actually not
necessary (providing "portability" that actually isn't needed or
used), it's a _complete waste of time_...

I think it was Randy who pointed out in one of his texts that there's
_thousands_ of clocks (was it 6,000 or 60,000 that he measured? I
can't remember...so, to avoid being accused of trying to "bias" the
argument, I'll pretend the figure was, say, 5,000 which biases towards
Windows unnecessarily fairly to provide "the benefit of the doubt"
because, to be fair, I don't specifically remember the exact figure
here), lost in processing a single "window message"...but, yes, even
with a potentially large figure, what's even 60,000 - heck, 600,000 -
clocks to a modern machine capable of 3,000,000,000 clocks every
second?

A great deal, in fact...because this "overhead" is NOT a one-off
deal...if it was then, sure, this is unnecessary pedanticism...but
we're talking "main loop" code and modern OSes _require_ you to use
API for _everything_...and, in Windows case, it insists on passing you
every single message - a series of WM_MOUSEMOVE, WM_SETCURSOR,
WM_NCHITTEST, etc., etc. for _every single movement_ of the mouse over
a window...for those with "message viewers", wobble a mouse around
over a window and just watch all those messages...and to make the
point clear as crystal, move the mouse over a patch of a window that
_DOESN'T_ accept any input whatsoever...a text label...wobble the
mouse there and, oh, it's _still_ bombarding the application with
these messages...

On the other hand, an application _KNOWS_ ahead of time which messages
it deals with ahead of time...you can work this out quite easily by
looking at the "window procedure" and noting which messages it looks
for...for example, there's a big "switch" statement that deals with
just WM_CREATE, WM_PAINT, WM_DESTROY or whatever...thus, in fact, it's
a grand waste of time for Windows to be sending any other messages to
this application...it, in fact, completely ignores them and sends them
straight on back to Windows with the "DefWindowProc" API...you go
through all the message processing nonsense - which is NOT a small
matter in the slightest, it's _terrible_ when it comes to the
"overhead" and length of time it takes - constantly for no
particularly good reason...

So, also, I'd suggest a simple method to greatly optimise this for any
event-driven OS...it's an extension of the method that X Windows uses
to "minimise" network traffic (X Windows is implicitly designed to be
able to work across networks in a distributed manner without any
change because it's structured as a client / server
relationship...when the server is "local", then everything is being
run on the same machine...when the server is "remote", then the actual
"server" providing the X Windows stuff can be located on the other
side of the globe...the design of X Windows is that it always uses
this client / server thing and that running an application on the same
machine as the server is simply the "special case" of when both client
and server reside on the exact same machine...therefore, you can write
an X Windows application and it can automatically be used in both a
"local" and "remote" way without needing to make a single change to
the program whatsoever...anyway, due to this "remote server" business,
X Windows is _slightly_ more intelligent about sending messages
because, well, it could potentially be sending them back and forth
over a 56K modem to the other side of the world...thus, attempting to
"minimise" the network traffic is inherent in the design so that this
stuff works well :)...when an application starts, it actually has no
"message queue" at all...note that, for console-style non-event driven
applications, you'd NOT actually want one of these, anyway...so, it's
more optimal for that type of application, anyway...but, if it a GUI
process then it will need one of these things and so calls some
"CreateMessageQueue" API...now, here's the clever bit...it's
exceedinly simple but would be exceedingly better too...when you
create the message queue and the windows and so forth, you _specify_
what messages the application actually processes...thus, if it's an
"output only" window, the mouse input messages are not processed...the
OS, though, has been _informed_ of this fact...so it simply does not
even bother the application with such messages at all...there's no
point, in fact...the application doesn't process them and would only
send them straight on back to the OS for "default processing",
anyway...thus, for all messages not processed, jump straight to the
"default processing"...

Hey presto, a far more optimal and better performing system by simply
having the sense to realise that the application should _tell_ the OS
what it needs...in short, the OS needs to drop its "control freakism"
and you get a better system...note that NO functionality is lost here
whatsoever...you can have just as many messages as Windows does and
that the application can ask to receive any and all of them, if that's
what it wants...so, sure, if you want some general "hook" thing that
inspects _ALL_ messages then, fine, specifically _ask_ for that when
creating the message queue and the windows...it'll then, indeed, start
acting exactly as Windows does by default, in passing every possible
message to the application to look at and choose if it wants to
process it...

Note that this optimisation can actually be "back-tracked" for even
better performance...for instance, if the application says "this
window does not process mouse messages" to the OS then, in fact,
there's a further possibility for the OS to tell the driver "for this
area of the screen occupied by this window, mouse details are not
necessary"...the OS can "pass back" this information...then the mouse
driver itself can not even bother to disturb the OS...it receives a
mouse movement, updates the cursor, realises its in an "output only"
area of the screen and so just stops there...no application is
interested to know that the mouse has moved, the OS doesn't care
either (there's no "mouse capture" or anything like that in effect
either) and has informed the mouse driver not to bother...the OS has
put a "do not disturb" sign on that particular window (or, of course,
part of a window or whatever)...therefore, the entire system -
employing this sort of design - can end up doing only what it strictly
needs to be doing...and we all know the saying: "the fastest code is
the code that never runs"...

But, note, at no point is any actual "functionality" compromised
here...if you tell the OS "I want all messages" and the OS tells the
driver "I want all mouse movement information" then, yup, it's exactly
equivalent to what Windows would do by default...we're NOT giving up
any functionality whatsoever with this scheme...this is not one of
those "I personally don't like C so let's throw out all C support to
make it run faster"...this is purely _design_ and _algorithmical_
optimisation...both this "message" stuff and the design of the OS API
interface...

It's my "Golden Rule" that I always try to aim for: "Equal or
better"...and that's what these "optimisations" are...they can be made
entirely _equal_ but there is room to make things much better
too...so, don't panic if you're thinking what I'm talking about is
giving up something in Windows or Linux that you particularly
like...that's NOT my aim at all...it's just "optimising" what is there
to work better without compromising any of the functionality...you can
_still_ be "portable" - just by using "wrappers" rather than having it
directly hard-wired into the API interface - and you can _still_
process all those messages if you like...

This is the entire point of "the toolmaker's view" that I'm trying to
stress...for instance, by delibrately breaking things up into their
"elements", we can choose whether we want "performance" or
"portability"...BOTH are available, it's up to you to choose what's
most appropriate...some super-fast "demo" will probably go for "raw
API" for fantastic speed and "who cares about portability?"...some
other serious application that needs to be "portable" to many systems
takes the "portable" route and operates just as well - if not better,
as I _will_ be looking on ways to make that better and easier too,
without compromising any functionality, if possible - then it can do
so happily..."best of both worlds"..."equal or better"...

In a sense, this is loosely (stress on "loosely") comparable to the
RISC vs. CISC concept...it's most "famous" in hardware terms but the
basic rough argument holds for any sort of "one complex vs. many
simple" thing...Windows is a CISC-like OS providing thousands of
high-level API for practically everything you can think of...a bit
like BASIC providing loads of high-level functions (well, Bill was
involved with BASIC...the attitude may have rubbed off ;)...these are
CISC-like...whereas, what I'm talking about is a RISC-like OS design
where it provides all the same things but just breaks it all down into
the minimum "elements" and then you build these up into higher-level
CISC-like functions...something like C or Forth - from the HLL world -
demonstrate the RISC-y attitude to make the comparison to BASIC being
CISC-y in attitude...they provide just the "bare essentials" and then
are built up into the "complex" stuff...

The ASM example would be things like the CISC-y "ENTER", "LEAVE",
"MOVS", "LODS", "LOOP" high-level instructions...versus breaking these
down into "push ebp; mov ebp, esp", "move esp, ebp; pop ebp", "mov
temp, ds:[si];mov es:[di], temp; inc si; inc di" and so on and so
forth...interestingly, the RISC-y counterparts may take more
instructions but these are simpler instructions so they often compare
favourably with the CISC equivalents...and the _real_ advantage of the
RISC-y style is that you can do some "unusual" things too...say, a
"MOVS" that automatically skips copying spaces in a string or
something like that...the RISC-y counterpart is infinitely more
flexible and provides much, much more scope for performing
optimisations...and, in fact, _despite_ the inclusion of these CISC-y
instructions on the x86 CPU, this is actually a "compatibility"
thing...the x86 actually has a very RISC-y core and merely executes
mutiple RISC instructions - microcode stuff - for these CISC
instructions...this is why, actually, the "broken up" RISC
instructions often perform equally well (or even potentially _better_
in certain conditions) than the CISC instructions, even though this is
one instruction versus many...

Anyway, this hardware argument of "one complex versus many simple" is
best known there but the essentials of that basic argument roughly
correspond elsewhere too...so what I'm talking about is really a
"RISC-y OS" (not to be confused with "RISC OS", which is something
completely different for the Archimedes computer...which, amusingly,
isn't actually a "RISC-y OS" like the one I'm talking about but merely
an OS for a RISC computer ;)...I'm saying "go for a many simple"
option and then build those up into the more complex functionality
that you want...note that, of course, it need not necessarily be _you_
specifically who does this...the OS can be provided with the required
standard "wrapper" libraries and other programmers may write these
libraries, which you may make use of (personally, of course, I'd be
suggesting "open source" libraries because that's my preference and
philosophy...it would mean that the libraries received the infamous
"thousand eyes" treatment to make them as best as possible...but this
would not be specifically forced on anyone...you know, just like Linux
is GPL and there are many GPL stuff for it but there's nothing
prohibiting commercial closed source applications being made for
Linux...it's "not in the spirit" but it's not prohibited :)...

And that's the nice bit about this "RISC-y" attitude...I could code up
a C-compatible "portable" library that provides you with "device
contexts", "pens", "brushes" and other things like that so that to
_you_ - the "HLL developer" in this example - you can use this OS
_exactly_ as you'd use GDI under Windows or whatever...but, underneath
this, the library you're using is actually merely a "wrapper" over
some direct, non-portable, "raw" graphical interface...but you're
using the "high-level" library so this needn't concern you
whatsoever...

The advantage comes around when you decide "actually, I'd like to
write a cutting-edge high-performance multi-media application"...in
this context, you decide that having it "non-portable" isn't something
that deeply concerns you...or, alternatively, you decide that
performance is important enough to warrant a little extra effort in
isolating the "OS-specific" parts from the non-specific parts and
you'll simply recode the specific parts for other OSes (a technique
employed by HLA, the C "stdlib", OpenGL, many computer games and many
other "portability" devices...in fact, at some point somewhere, almost
everything that's "portable" is using this underlying technique
_somewhere_...being "under the hood", you might not be aware of this
but it _is_ going on, I assure you...thus, one possibility is that
you'll do this yourself to gain precise control over it so as to
optimise it to still give acceptable high-performance without
compromising the "portability" you want :)...

For these sorts of options, you've made the decisions that will _best
suit_ what you wish to achieve with your application...thus, you have
chosen that rather than use some "DrawLine" high-level graphic
library, you'll get down and dirty plotting pixels or invoking the
card's accelerated "Blit" functionality or whatever...note that all
the "high-level" library actually does, in fact, is merely perform
these lower level operations on your behalf...but you've decided that
you're going to do it yourself because then you can work out some
specific optimisations that suits your application and gets better
overall performance...you choose to throw out using "wrappers" with
stack frames and so forth, rather using the direct "pass everything in
registers" raw API interface...rather than process all messages, you
specifically select the ones you need for your application...

All these options are _available_ to you...the RISC-y attitude brings
greater flexibility, freedom and choice to you as a developer...also,
the "high-level" libraries are simply making use of the lower-level
interfaces "on behalf of" applications where we care more for getting
the job done quickly than for the performance of the final
result...this is implicit "code re-use" throughout the system...it can
still "bloat" if someone's not careful about what they are doing but,
inherently, this is thinking in an "anti-bloat" way...

You could even conceivably do something like this...write your program
at first using the high-level interfaces and libraries...once
complete, you think you could do with speeding it up and reducing the
size a bit...so, you can bit by bit replace the high-level interfaces
and library calls with lower-level optimised alternatives...stop when
you feel you've done the job sufficiently well...if you're a pedantic
sort then go right down "to the wire"...note that if these libraries
are "open source" as I'd suggest would be best then the effort of
replacing these functions would be quite simple too...copy and paste
the library code then directly alter it...with the source code
available, you can inspect how the high-level library does its work
and then re-code something similar that's more optimised for your
application specifically...

That is my "equal or better" Golden Rule shining through...it's a
RISC-like OS but, using library code, you can create all the same
CISC-like interfaces you may prefer to use...oh, and an interesting
idea pops up too...Windows uses "stdcall" as a sort of "language
neutral" calling convention...but this RISC-y OS has a "raw" low-level
interface and then uses "wrapper" functions for higher-level
interfacing...well, why not supply a set of C-based wrappers in one
library, a set of Pascal-based wrappers in another, a set of
VisualBASIC wrappers in another library? Yet another example of how
breaking CISC down into a RISC-style can give you exactly the same
functionality, a greater array of options (it's _still_ possible to
simply use "stdcall" wrappers and be exactly like Windows is by
default) and "the best of both worlds" / "equal or better"...by
selecting the appropriate wrapper, it can be tailored specifically to
the conventions and so forth of that language (something like
VisualBASIC would likely need something complex to put things into
"objects" and so forth...C, on the other hand, would just put
parameters into registers and then make the direct "raw" API call
:)...

It must be understood...I'm not asking for "compromises" nor
"restrictions" here, threatening something you know and like...quite
the opposite..._Windows_ is the OS that already does such restricting
of developers...I'm talking about freeing this all back up...getting
back the Liberty, choice and freedom to develop as is appropriate to
the application, not just to some strange "ivory tower" whims invented
blindly by OS authors as the "official" "academic" way we should all
follow...Windows and such got there first so it forms the "default"
thinking people have on these issues...so, turning up late, it might
seem like I'm talking about "dead ends" and "heretical"
notions...quite the reverse, if you'll be willing to see it...the
others represent that and that's why I'm concern to point out the
alternatives...the immense benefits of a RISC-y "toolmaker's view" of
things instead...to point out that it is _they_ who restrict...my
ideas would _liberate_, provide more options, be more flexible and
will have the potential to be _more optimal_, not less so, for
providing these things...

Less is more; "many simple" - RISC - often equals or beats CISC "one
complex"..."equal or better"...and "the best of _BOTH_ worlds"
simultaneously...this is essentially what I'm talking about...this
might not float your boat...you may not want to be any sort of
"convert"...feel free to disagree...

BUT DON'T try to imply that what I'm talking about is "insane" or
"couldn't work" (as most of these ideas _do_ actually exist - I'm the
very first to confess that they aren't "original" - and all I'm doing
is putting together all the best bits into one consistent idea then it
_will_ work because it _has_ worked and, most probably, if you're
using Windows, Linux and running a few computer games, these things
you've already benefitted from...it's just a case of putting all the
good ideas together and putting all the bad ones to one side...the
"original" part of what I'm saying is the idea of putting it all
together...the actual "bits and pieces" that I'm talking about do
_already_ exist in other systems or one part is in Linux and another
part is in Windows...such as the "hybrid" API interface I'm talking
about...it _is_ actually a case of grabbing the "best bits" from DOS,
Windows and Linux and trying to throw out the "bad bits" :)...

> That at some point they will be out of sync with hardware
interrupts? What
> if tomorrow the x86 shipped with video IRQs? We'll all be singing
a
> different tune, and if you're still around your posts will begin to
sound
> like newbies' blurps even more than mine do!

Huh? Umm, if tomorrow _PCs_ shipped with video IRQs (x86s won't...an
x86 is a CPU...it's the standard _PC architecture_ that lacks
it...x86s can already deal with such an IRQ...one _was_ originally
specified in the standards but never got properly picked up by
manufacturers - an "accident of history"...IBM didn't pick up on it
and, at the time, IBM still defined what was "standard" so the
"clones" often didn't implement it because they were still, in those
days, chasing after "100% compatibility" with whatever IBM
did...whether what IBM did was actually a good idea or not :)...then
I'd say "Yay! At last!"...that's exactly what I'm calling for...I'd be
overjoyed...and it would hardly make my posts look like "newbie
blurps" when, in fact, I'd just demanded something and had actually
got it...it would look a little more like an amazing "Nostradamus"
psychic prediction of the future...someone "ahead of their time"...if
they actually went ahead and did exactly what I've been saying all
along that they should do...

And, yeah, I'd be singing a different tune...namely, they'd "fixed"
the problem I've been talking about with the solution I'd have
recommended...so, sure, I'd _cease_ complaining about that because
they'd just fixed it...they'd just done what I've been asking of them
all along to do...that's excellent...that's great...I'd be jumping up
and down with joy at that...

I'm confused here, though...what _specifically_ don't you like about
what I'm saying here that you're trying - quite desparately, if you
don't mind me saying - to imply that I'm "off her rocker" and that
people should kill-file me and so on and so forth? I didn't believe
that, this time, I was actually being all that greatly
"heretical"...because, boy, when I'm a "heretic", I don't hesitate or
excuse my heresy and I could see that potentially upsetting someone
too strongly grounded in the "status quo" to accept easily or
immediately...that's fair enough...but, this time, you're jumping
straight in with some "you are a mad woman!" thing somewhat
pre-maturely and, dare I say, unconvincingly...

But, you know, it's okay...there's no need to panic...you see, there's
no way I could single-handedly create an entire OS of Windows / Linux
standard by myself in any reasonable period of time...everyone tends
to think me a little "insane" to say the least...this won't amount to
anything, you do realise? It's like some minor post no-one'll be
paying any attention to, I assure you, and it won't lead to any
"revolutions" or you having to give up using Linux tomorrow or
anything remotely similar to that...there's really nothing to get
upset about...if anything, it's _me_ who has the right to be most
upset because I'm really NOT talking about anything "daft" or "insane"
in actual fact but everyone'll, I'm sure, treat it exactly as if I
am...I'm the one wasting time here, dreaming out loud only to be
knocked back and ridiculed for doing so...you've got - pardon the
French - sod all to be worried about while I have to sit here and
"sunbathe" in all the various insults coming my way for just wanting
to discuss the perfectly reasonable topic of "CISC versus RISC" from a
_software_ perspective rather than the traditional thing of only
confining such discussions to hardware considerations only...I'm the
one wasting time, effort, passion, rage, intellect and so forth on
something that's most probably doomed to complete failure from the
start as no-one'll pay the slightest bit of attention to what I'm
saying...I've made my bed and must sit in it (though I do accept that
is the price and, therefore, pay it)...while all you have to do is
ignore my posts because everyone else will...even potentially when
they actually read them...that they will, I assure you, NOT amount to
anything you ever need worry about...if they were going to do that
then my "heresy" would have rubbed off on people by now...it
hasn't...this isn't interesting anyone...I'm the "mad woman in the
corner ranting away"...fair enough...I actually don't really have a
choice in the matter due to my personality...so I'll keep ranting
away, whether it does any good or not...but, trust me, you are the one
with the _least_ worries here...the least right to be "upset" by
anything I've said...just ignore my posts if you don't like them and
nothing more need be said...if anyone else is reading then it's most
probably simply for the "amusement factor"...blah-blah-blah...

There's really no need to "attack"...because it would only be kicking
someone when they're down, anyway...I'm not taken seriously - "whacko
rants" / "[ 7465 lines snipped ]" / my name attached only to mockery
like "the Beth attitude" from Rene - and practically everything I say
is challenged by someone somewhere, so there's no element of
"authority" to worry about either...I don't have any, anyway...but
no-one presumes that I do, regardless, so there's no danger on that
front either...

There's really no point in ridiculing a clown...they look stupid,
anyway...that's just being personally nasty to the clown to upset them
for no beneficial reason...

"People say I'm the life of the party
'Cause I tell a joke or two
Although I might be laughing loud and hearty
Deep inside I'm blue

So take a good look at my face
You know my smile looks out of place
If you look closer it's easy to trace
The tracks of my tears

I need you...
Need you

Since you left me if you see me with another girl
Looking like I'm having fun
Although she may be cute, she's just a substitute
'Cause you're the permanent one

So take a good look at my face
You know my smile looks out of place
If you look closer it's easy to trace
The tracks of my tears

Outside I'm masquerading
Inside my hope is fading
I'm just a clown since you put me down
My smile is my make up
I wear since my break-up with you

Baby, take a good look at my face
You know my smile looks out of place
If you look closer it's easy to trace
The tracks of my tears"

[ "The tracks of my tears", the Miracles / Smokey Robinson / Johnny
Rivers / etc., etc., etc....more or less a "traditional" tune by now,
it's been redone so many times :) ]

Beth :)