Re: learning asm.

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

Date: Sun, 9 Nov 2003 17:33:27 -0000

ernobe wrote:
> Beth wrote:
> >> Also, Linux's method of passing
> >> the parameters (as many as possible) in registers is *very*
> > efficient
> >> when switching address spaces as you don't have to do
> > cross-address-space
> >> memory copies (expensive).
> >> Call gates aren't a whole lot better, speed-wise,
> >> so there's not much wrong with the INT instruction. Indeed, on
most
> >> CPUs, the equivalent of INT is called "SYS" (system call).
> >
> > Yes; But that's actually why it's a bad choice...umm, I know that
> > sounds odd...but if INT and Call gates are hardly any different
when a
> > context switch is required but that a CALL - sans context switch,
sans
> > user -> supervisor -> user transitions, etc. - is much better then
> > CALL rates as "about equal" for the worst case and "...or possibly
> > better" for the less drastic cases...
> >
> > As for context switches and user -> supervisor transitions, then
from
> > the other stuff I've been saying about the sort of architecture
this
> > fits in with, this stuff is at a minimum, anyway...a
"micro-kernel"
> > with a strictly "toolmaker's view" about things...as much OS code
as
> > possible is kept as user code and subject to full protections...in
> > fact, I'd seriously consider that but a single security object has
> > ring zero rights and is the sole component in charge of
controlling
> > access for other user mode code...nothing else strictly needs it,
> > nothing else gets it (device drivers have "gaps" opened up using
the
> > I/O permissions bitmap to access hardware or memory-mapped stuff
> > mapped into their address space..._ONLY_ what they require is
granted
> > by this sole "security" object...the _ONLY_ thing that needs to
> > execute at ring zero in the entire system...and transfers to it
are
> > actually slightly rare)...
> >
> > Thus, there are effectively NO user -> supervisor transitions
> > whatsoever _UNLESS_ ring 0-like security permissions are needed to
be
> > granted / removed (an infrequent event in comparison to most
things,
> > such as loading / unloading device drivers)...all the high-level
> > libraries (the OS _delibrately_ only implements the absolute
minimum
> > in a somewhat non-portable ("specific") way...everything else is
dealt
> > with using optional high-level libraries which bring "portability"
and
> > such to the raw API...these would be made "standard" as part of
the OS
> > distribution but strictly are NOT really a part of the OS, as they
are
> > simply user code libraries over a raw, minimal API...they may all
be
> > replaced with your own code or by an alternative library or
whatever)
> > can execute in the program's address space in the context of the
> > program itself...
>
> We're all for a user/programmer perspective switch from
security/portability
> to true/multitasking, like any good assembly programmer.

No, I'm not in any way talking about compromising security
whatsoever...I would insist that the joke Microsoft call "security" is
not even in the right ballpark and simply is nowhere near good
enough...and who said anything about not having an OS that supports
OpenGL or X Windows or being able to compile ANSI C GNU utilities
source code without modification? There are _many different kinds_ of
"portability"...I'm only talking about the _actual implementation_ of
the OS itself...it _is_ and very much will be "portable" in all other
regards...that's why I'm including those "high-level libraries" along
with the OS...

> The question is, where is the Assembler OS?

For a modern 32-bit example:
http://www.menuetos.org/

But, of course, DOS was an assembler OS of an earlier era...the Amiga
Workbench, the Atari ST's GEM were 68000...Apple's original Mac did
use some Pascal but was peppered with an awful lot of assembly code in
order to get the required speed on the lesser hardware of the time...

In fact, C was _invented_ for UNIX...so that's an obvious
self-prophecising exception...and Microsoft took their time to follow
this...Windows was where they started but even that wasn't total when
we go right back to the start...DOS was completely assembly...

It is a relatively "modern" and "recent" thing (remembering that time
in computing circles is always measured a little faster than time
elsewhere, due to the unfailing adherence by the hardware people to
Moore's infamous law ;) to compose an entire OS as far as is possible
in a HLL...

The UNIX / C relationship lead to "portable" OSes...this, by the way,
was purely intended as a time-saver and nothing more...because, as we
can see from the various flavours of UNIX, it's the fact that a _C
compiler_ is bundled with the OS and then source code for applications
is distributed that really makes things "portable" there...I draw
attention, as I did before when the discussion was about SCO, to what
GNU actually stands for: "GNU's _NOT_ UNIX"...for legal reasons,
things like Linux are merely "clones" of UNIX...based on the _ideas_
and conventions but NOT on the actual source code...even with the
incredibly close OS to C language relationship, we still end up
putting things in registers and calling INT 80h...

It is _modern_ thinking that OSes should be "portable" and composed
almost entirely in C# or whatever...but as I'm trying to point out,
there are substantial reasons to consider that this is NOT actually a
path to pursue...the reason Windows is bloated and slow is the
combination of Microsoft's "who gives a crap?" attitude mixed with HLL
this and HLL that everywhere...

It can and will _only get worse_...everyone's accepted this and, in my
merely voicing a minor dissenting opinion of the most, most minor
kind, I'm the burnt witch for my "heresy"...how dare anyone suggest
that an operating system - the fundamental software running an entire
system - be specifically coded for that system?

Note, if you're about to say "what about portability?" then you're one
of the worryingly large number who doesn't see that there are _many
different kinds_ of "portable"...this assembly coded OS can, indeed,
comply with parts of POSIX and have OpenGL libraries and use the X
Windows interface standard and so on and so forth...

The difference you already know...do we need to write an assembler in
assembly? No, actually, we don't...is the "portability" of a compiler
inherited by what it compiles? No, not particularly...if it were,
cross-compilers would be an impossibility...the OS source code is NOT
"portable"...it is specifically crafted for the target architecture so
as to maximise the use of the system resources (an OS doing a "good
job" should be like a good cameraman...they are doing _well_ when you
DON'T NOTICE THEY ARE ACTUALLY THERE)...but the higher-level
interfaces that are implemented may be whatever-and-his-brother's
"standard" and "portable" with this or that...

But, you cry, "but you can't port this OS to another machine!"...yes,
indeed...but, in practice, there's no point...NT was "portable" but
even the world's richest company with all its commercial muscle
eventually gave up on bothering too much about this sort of
thing...90% of desktops are PCs...the next largest share is owned by
Apple with their iMacs and Apple have their own machines sewn up there
and Apple users are loyal so there's nowhere to go in that direction,
really...

DEC Alphas? Well, yes, maybe...but you've got to ask yourself...in
choosing a HLL here so as to cater for "portability" of your OS to an
x86 and an Alpha, you've just bloated the software and reduced its
performance...to cater for 0.1% of the market, who - in all honesty -
are actually perfectly happy with the OS that comes with that
machine...Apple users are also generally happy with the OS that comes
with their machines too...it's really x86 and Microsoft that pose the
problems here...

So, for a split second, let's drop the blind worship...that is, humour
me for a second in imagining things in a different alien way...think
of it like this...you are going to go "portable" to cater for about
0.01% of the market, who don't actually want what you're offering and
are accepting absurd bloat and worse performance in the most
fundamental piece of software that implicitly defines the entire
performance and operation of the system?

Indeed...and now you can start to see the very beginnings of why
Windows is a pile of crap...the wrong compromises have been made
here...the "god" of HLL was worshipped in the wrong instance...you
want to tell me all about using C# for some disk utility you wrote?
Great, fantastic, excellent...but an OS is _fundamental_...it operates
by a higher set of standards and rules...a bug in an OS is a bug in
every single application that ever runs on that OS...a poorly
performing OS - churning away at the hard drive because it requires
768GB just to draw the desktop - means a poorly performing
system...OSes require at least one level higher standards than
ordinary applications...because there code is implicitly running as
part of every other application...all these applications should be
being _freed_ by the OS, not held back by awfully written "portable"
bloated slow code...

Write the OS in assembly specifically for the target system...and
then, if you want, re-write a "compatible" version for a different
system in the different assembly of that machine...and, yes, you can
make these two versions "portable" in terms of how they operate...but
they are not source code "portable" whatsoever...each is coded
specifically for the target machine...

But, oh dear, what about all these tons of architectures everywhere?
Ummm, where? There's x86 and that's about it...even if you really,
really insist on a different architecture, the essential issue here is
that it's better to re-code for each specific machine than it is to
try to come up with some portable "halfway house" generalisation
that's big, bloated, slow and not really using the full extents of the
machine...an x86's segmentation and its four priviliedge "rings" is
capable of incredibly robust operation...but, nope, "portable"...so we
pretend there's only "user" and "supervisor"...and we pretend there's
only paging...and then we sit around waiting for those blue screens of
death to bring the entire system down...

> Forth, in its modern incantation, is close,
> from which we learn that these perspectives are mutually
incompatible.

I severely beg to differ...for your information, the term "toolmaker's
view", I've been reliably informed, comes straight from OS
theoreticians and textbooks where it has all been considered and they
have reached a similar conclusion as me...

More is less; It's as simple as that...it's _better_ to take a
"RISC"-like attitude...provide the very basics...and then use these to
create higher-level functionality...

Heck, _even Microsoft_ are beginning to see the light and are
suggesting that they need to slaughter their 10,000s of API to merely
8,000...still not good enough, really...but, from Microsoft, it's
miraculous they had their eyes open to see that this really is the way
to go...in a sense, the _ONLY_ way to go...the "buy more RAM" attitude
is starting to bite at its own heels...things are getting
exponentially worse all the time...

If people don't "stop the rot" soon - and even Microsoft are realising
that they have to at some point (and, equally, Intel are desparate to
drop the hacked together x86 architecture, if they can...the 64-bit
processor may be where they do that, although I have heard that they
do have an agreement with AMD about their 64-bit implementation or
something) - then, fine, I'll sit back and wait for everyone else to
"catch up" realising why this _must_ happen eventually...okay, not
necessarily the "code an OS in assembly"...but the general attitude of
beginning to "stop the rot"...hardware can only cover up the
increasingly worse and worse software that is being produced...and as
the bloat is being built on the bloat by bloat itself, the whole thing
is decelerating all the time...keeping with this trend, at some point,
the hardware will NO LONGER cover our arses anymore...

> A
> true portable Forth operating system would be nothing but an
enhanced
> version of their meta-compiler. A meta-compiler as an OS? A
compiler as
> an OS? But if you get down to it, that is what you're asking isn't
it?

Not exactly...it's a mite more subtle than that...but, yes, there are
elements of comparison...but, tell me, how on Earth is the Windows
API - with its "wsprintf" and "lstrlen" and MSVC40.DLL and its
"stdcall" conventions and so forth - NOT a "HLL compiler" as it stands
right now?

And pre-PC, all machines came with BASIC or something burnt onto a ROM
chip...there was no hint of "mutually incompatible" there, I can
assure you...

And, stop and think for a second...when you re-compile the Linux
kernel or "port" over a GNU tool using the pre-packaged GCC, where is
your "portability" really coming from? If you grabbed a FreeBSD or
other UNIX flavour _BINARY_, will it execute "as is"...no "emulation"
layers to smooth over...literally trying to run one binary on
another...nope, blows a fuse...

So, where's the "portability"? The "portability" is in the basic
standards for the available API being shared on all UNIX-compatible
clones...the "portability" is coming from distributing _source code_
and using _GCC_ to re-compile it specifically for the particular OS...

Thus, in fact, you're getting all your precious "portability" from
_standardised library routines_ and having a _C compiler_
installed...so, in fact, the OS is "portable" because there is a
compiler available as standard...what would be the distinction - other
than on-disk organisation and the flexibility to have different
third-party compilers - with an OS where this stuff is all part and
parcel of the OS itself? In practice, absolutely bugger all...and, oh
yes, a "meta-compiler" would be, indeed, excellent...

"Mutually incompatible"? Sorry...bullcrap...and where did you invent
this "mutually incompatible" thing from anywhere? "Mutually exclusive"
is the standard term for such things...but, hey, why not? Shakespeare
invented language as he went along - "eyeball" and such - so I won't
begrudge you giving it a go as you go along too...

> Or
> perhaps you're an anarchist who wants to take Open Source to its
limits,
> perhaps an explanation on your part would ease Betovs' psychological
> make-up as he inches closer to coming to terms with the perceived
view that
> his extreme leftism is nothing but outright anarchy.

No; I've specifically stated that "anarchy" is the one system that has
failed in 100% of all cases ever...anarchy is the "default" things
revert to when there is nothing else...but, in ALL cases, anarchy has
_failed_ because some form of "systems of laws" has come to replace
it...even if more a "honour amongst thieves" system rather than a full
judical system, it's still not "anarchy" anymore and anarchy _always
fails_...

This is typical, though...when someone hears something that sounds
like "heresy", they presume that this person is an "anarchist"...yes,
indeed...Corpernicus was a total "anarchist"...in opposing the
Church's view that the Earth was the centre of the universe, he was
surely _only_ intent on destroying all systems of laws completely...to
unleash "demons" to roam the Earth eating up small children and
God-fearing Christians...burn the witch! Burn the witch! There could
have been no other intent by Corpernicus - whatever he claimed about
"trying to make people see the actual truth" - but to "serve satan" in
bringing chaos and anarchy on the world...yup, the good old "we fear
change!" knee-jerk reaction...seen a million times before...

I assure you, I have absolutely NO intent in destroying a single thing
that you hold precious in the long run...I mention these things in an
entire _preventative_ and _truthful_ capacity...I'm sure you will not
believe this, of course, just because I say so (and that is, indeed,
exactly right...you _should_ always remain sceptical, I would be
disappointed by any other reaction, in truth :)...and the only
reasonable "proof" that could be accepted is to actually sit around
and wait for the chaos and "anarchy" of not doing anything to see that
I was specifcally working to try to _PREVENT_ exactly that...the
complete and utter reverse of the charges laid before me...

For those that read my posts, they'll know the keywords I always
use...a "balanced" system...NO party should ever go to an
"extreme"...go beyond the extents of the law...heck, I've been
complimented more than once on sounding exactly like a lawyer at times
and that I'd make a great one...I immediately try to educate the virus
coder that their "anarchy" is actually nonsense...I've stated
repeatedly that "bringing down the system" is essentially stupid
because WE ARE THE SYSTEM...I believe in variety and diversity
("bio-diversity" as the security people like to call it) but this is
NOT "chaos" I speak of...it's entirely ordered and it is the essential
nature of the universe around us, ordered by the laws that govern our
reality...

"Anarchist"? I think not...I am different in many ways but difference
does not mean "chaos", whatever your "we fear change!" knee-jerk
reaction is telling you (just as Corpernicus was _correcting_ an
actually factual flaw in the "system"...he was trying to _fix_ what
was _broken_...he was NOT trying to destroy or unleash chaos or demons
or anything such thing...in fact, as we can see in science today, it
was the beginnings of the attempt to _remove_ choas and restore the
actual order)...

I understand that you may not believe what I have to say just because
I say it...I would urge you to remain sceptical, in fact...but my
intent has always been the same throughout my life...to _understand_,
to _fix_ where things appear to be broken, to _resolve_...I am a
programmer...programmers are professional problem-solvers...it's in my
blood, so to speak...every time I see a problem, you can be assured
that I'm at least trying to think up a feasible, practical solution to
it...even if I'm not actually able to implement any solution, I'm
_still_ thinking up the solution anyway...as I say, it's in the
blood...

There is a problem here - though some may not see this, there is
testimony in the growing dissatisifaction of the "status quo"...if
things actually were "right" then there would be a _lessening_ or even
NO dissatisfaction...if it's going up, in whatever way, there _is_ a
problem there somewhere which needs to be addressed - and, though I
confess that I could be entirely wrong in my "bugfix" here, this is
how I see it being resolved in the best practical way possible...

> > ....
> > Now, note, _application software_ should be potentially portable
> > between OSes...so, yeah, you have standardised API and OpenGL and
> > X-Windows (I'd support that, in fact, more than most people
do)...but
> > this is NOT the same thing as the OS itself having "portable"
source
> > code...again, "portability" is a multi-faceted thing, not just a
"I
> > have it" / "I don't have it" binary switch...application
> > "portability"...yeah, great! "portable" OS source code? Why
bother?
> > You'll pull your hair out trying only to end up focussing only on
x86
> > machines because they dominate everything and splitting your focus
> > nine ways is too complicated that you've got to settle on just
> > one...UNIX is a special case, even now...and required a
programming
> > language to be invented so that it would work...an OS and a
> > programming language? Oh, well...good luck to all the hobbyist OS
> > developers...you'll need every ounce of luck you can get ;)
>
> The moment Unix begins to get optimized for the PC we'll start
replacing C
> with regular Assembly.

Good...

> Both developments are now half-way, and what will
> get us through it is the realization that computers don't control
us, we
> control them.

I think you'll find it's a "symbiosis", in fact...a co-dependency...

Much like the one humans developed with farm animals when we came up
with that earlier technology of argiculture...you know, looking after
the animals and giving them food and calling out the vets to make them
better when they are ill and so forth...in return for this "easy life"
whilst alive, the farmer reserves the right to then exploit the
resources of the animal...milking it, killing it to take its hide for
materials or its meat for food and so forth...although, yes, the
vegetarians would be entirely correct to point out that the animal's
_permission_ to comply with this "symbiotic" deal is not gained...but,
nonetheless, it's a "symbiosis"...just the animal is not giving much
of a say in the matter (but, then again, when a parasitic worm lodges
itself into a person's stomach, it's not offering any choices in the
matter either..."symbiosis" is often NOT by mutual consent...but,
regardless, there is a _co-dependency_ there :)...

The "human / machine" symbiosis is, indeed, a very different and
complicated one...but, essentially, this is what it is...biology only
concerns itself with living things that the term "symbiosis" would not
usually be applied to a relationship between a living thing and an
inanimate object...but, nonetheless, that's what it is...the proof of
the pudding is a blackout...or a bank's computer suddenly losing
everyone's account details...or how we're able to do more during a day
because lightbulbs light up the night for us...we are in a symbiosis
with our technology...it controls us as much as we control it...the
only thing missing from this inanimate / organic "symbiosis" that
would be present in an organic / organic is that there's no need to
cut any sort of "deal" with an inanimate object...they don't gain any
"benefit"...as well, what would "benefit" actually mean to a
lightbulb?

> Why isn't there even one respectable compiler written in
> pure Assembly? It all begins with the answer to this question.

Yes; So what is the answer?

1. It takes too long...
2. I prefer using HLLs because they are easier...
3. Everyone else seems to be using HLLs...so that's, like, got to be
"right" or something, yeah?
4. The compiler textbook I'm working from has the example code in
Pascal...
5. The boss insisted upon it...
6. I'm "borrowing" some source code from elsewhere and it's C
code...best to write the rest in C as well because that's easier...
7. There are more C coders than ASM coders, due to social and
educational reasons...a compiler is a big project requiring many
programmers...if we use C then we can get more people working on it...
8. There aren't as many ASM coders so they'll likely cost a lot more
to hire...whereas, the university down the road is spitting out a good
hundred reasonable C++ coders every year...too many people for a
particular vacancy? Then they'll have to be _glad_ that they are
getting a job...if they want to "negotiate better terms" then we'll
simply hire someone else who _won't_ do that and will accept whatever
we give them...which will probably be less than what we'd pay an ASM
coder by a margin...but with this many student applicants all
desparate to get their first job and pretty much happy to accept
anything...then we can have lower wages here and there'll _still_ be a
queue going around the block for the job...because, after all,
"beggers can't be choosers"...
9. [ Betov's answer ] What are you talking about? With the "preparse",
RosAsm can be a compiler and it is written in pure 100% ASM...and it
is more respectable by comparing to HLL sh*t swindling!
10. An inexperienced ASM coder won't do as good a job as a good
optimising compiler...those "gurus" who can do a better job are
unavailable...
11. An inexperienced ASM coder won't do as good a job as a good
optimising compiler...those "gurus" who can do a better job aren't
interested in writing HLL compilers because they are, of course, "ASM
gurus" _because_ they only use "real" assemblers, disassemblers and
hex editors...they don't use compilers, why on Earth would they be
particularly interested in creating something they don't feel they
have a use for when no-one's paying them to do it?
12. Pay us some good money and I'll do that for you...but no money
and, sorry, I ain't got the time...
13. Blah-blah-blah...

Which particular answer did you have in mind here? Also, it's
probably - as it usually is the case - that more than one answer,
perhaps of the ones above, are conspiring together, as there is rarely
but one cause leading to but one effect...

> > ....
> > But, let me throw the question back at you in a different
light...why
> > on Earth should people be feeling such a need to fight the OS all
the
> > time to get back 10 cycles? Now, there are a breed of people
who'll
> > always do it for the hell of it...but this goes beyond that...PC
> > systems always were a backwards step and I don't really think -
even
> > with all these amazing hardware developments - that this has ever
been
> > completely thrown off...most C64 games, for example, always
managed a
> > steady 60Hz or 50Hz refreshing their display (an interrupt line
> > specifically for detecting the vertical blank...actually, it could
be
> > asked to interrupt on any _scanline_...a massive, massive omission
> > from the PC hardware...even if things have now moved onto
> > accelerations and such, it's still wrong...it makes all programs
have
> > the _wrong_ structure...they _POLL_ for the vertical blank on a
device
> > perfectly suited to a regular interrupt...I mean, to a 3GHz
machine, a
> > 60th of a second is an eternity...it _deserves_ and always had
> > deserved an interrupt line...unfortunately, it got allocated but
IBM
> > and others decided not to bother implementing it in their
"standard"
> > hardware and the "VGA IRQ" died off like a dodo)...
>
> So now we're back to square one, you dodo,

Actually, no, you've miscomprehended...

> if you saw the same program I did
> on Discovery or People and Arts, I forget which, you know it was the
pigs
> that did them off, those ugly, stinking Dutch pigs.

Ummm, sorry...without having seen that program, I have no idea what it
is you're talking about here and the above just comes across as
slightly surreal...farm animals in the Netherlands were responsible
for the VGA IRQ being missing on PCs? Or...wait...you mean it was pigs
that killed off the dodo? Why would a programme about pigs and dodos
be on the "People and Arts" channel? Or is this all very much
metaphorical or something? Nope, sorry...I'm just completely lost
here...perhaps I also needed to see the programme to understand or
something?

> I mean, first you
> complain that interrupts are wrong,

Well, first, I didn't say "wrong"...second, the complaint was about
using _software interrupt_ for invoking OS API...which an entirely
different situation to below...

> and now you are all for them,

Incorrect; We're talking about two completely different things here,
in fact...and my opinion has not changed nor is it inconsistent...

> and all
> for the sake of porting C64 games of all things!

First, the reference to the C64 was purely an illustrative example of
a system that _does_ have a "video IRQ" that was very usefully
exploited in numerous games to very good effect (the example, of
course, _MUST_ come from a different system to the PC because the
whole issue here is that the PC lacks the particular IRQ I'm talking
about)...it has nothing to do with "porting C64 games" but with
providing an example of the useful utility of such an IRQ to perform
miracles...anyone who knows about that little 8-bit "breadbox", will
know how this IRQ was used to "overkill" levels to perform amazing
"special effects" that, strictly, were beyond the C64's technical
specifications...the C64's VIC video chip could draw eight 24 x 21
hardware "sprites" but by exploiting the "scanline IRQ", many games
would constantly move those eight sprites around as the monitor traced
a beam down the screen so as to have far more sprites on-screen or to
combine them to have more colours or a larger size (for example, by
lining up the 8 actual sprites horizontally and then changing their
"y" position and the data that defines their shape as we go down the
screen, then - from a 320x200 screen - you could cover a potential
192x200 area of that screen in sprites (about two-thirds of the entire
screen C64 screen!)...effectively worth about 76 sprites in total
area!!! The scanline IRQ has allowed there to be almost _ten times_
more sprites visible on the screen than the technical specifications
of "8 hardware sprites" would suggest is even possible...another trick
of the "scanline IRQ" was that the C64 could only technically display
4 colours for "multi-colour" graphics...but by simply changing those
colours around as the scanline moved down the screen, it was possible
to display more than was strictly possible...

And the important thing to realise here is that these effects were
100% flicker-free (well, not always...but that was down to bad timing
and coding on the programmer's part...a "bug" of trying to squeeze too
much processing in the short spaces of time available and overrunning
that time)...this stuff - done correctly - was absolutely steady as a
rock on the screen...

Second, this is a _hardware IRQ_ we're talking about...unfortunately,
both - software and hardware - are called "interrupts" because they
employ the interrupt mechanisms...but, in use, there's quite a
difference between them...software interrupts are one way to deal with
"relocation" issues because they are automatically redirected via the
interrupt tables (IVT or IDT, depending on processor mode)...hardware
IRQs - I'll call them IRQs to distinguish them from software
"interrupts" here - on the other hand, are completely different in use
and _essential_ for a smoothly running, nicely timed multi-tasking
system that doesn't drop keystrokes or stutter audio streams because,
oops, it's missed its timing because the system works completely on
polling...

Hardware IRQs are important, great and, basically, mandatory...plus,
with everything event-driven, the system doesn't miss a thing but
doesn't need to waste even a single clock cycle waiting for events
("polling") because the hardware's working on a "don't call us, we'll
call you" system...

My point here is that the video system should _ALSO_ be hanging off a
hardware IRQ on a PC system...it was originally specified that it
would do so...but, due to accident and history, this IRQ got
"lost"...and, now, most programs are _wrongly_ structured because of
it...that is, as mentioned, an event-driven system goes about its
business - no "polling" at all - and then the hardware IRQs interrupt
at the appropriate points...this is _good_ multi-tasking design and
what every such system should be aiming for...but, unfortunately, the
PC lacks the essential IRQ for video operations and, thus, software
gets structured to "poll" for the vertical blank, with graphics placed
centrally, interspersed with the main code (for a game, this would be
moving the player character and monsters and checking interactions and
bounding them within the map and so forth...which is really the
_actual_ game itself...the graphics merely let you know what's going
on in the game :)...this is _bad_ program structure (worse, bad system
structure) because synchronising to the vertical blank - essential for
smooth animations - requires polling...and polling requires sitting in
a loop doing nothing else...there are clocks going to waste because of
this...and, strictly, without this IRQ, the PC is a system that has a
flawed multi-tasking design...you can stick everything of importance
onto IRQs, _except_ the video...video, though, is not any exception to
this design philosophy, even if many people over-prioritise it because
they obsess on the subject...

There's no contradiction here; To summarise, all I/O hardware that
qualifies should be placed on a hardware IRQ so that it may use the
interrupt system to be able to work completely
asynchronously...software interrupts - which, in a sense, is just a
"hack" to "borrow" the system designed for the hardware IRQs for
software relocation issues - shouldn't really be used as there are
much better ways to go about this sort of "relocation" thing than
using this mechanism...and, amongst other things, it's strictly poor
show to use software interrupts while you have important hardware IRQs
around because they may be different but _are_ using the same
mechanism and circuitry...thus, they would be "getting in each other's
way" and competing for attention...when, sorry, no contest...the
hardware IRQ should be getting the attentions...granted, it will in
the end because the interrupt system is clever enough not to "lose"
IRQs but it really shouldn't have to compete with some random OS API
call whatsoever...yes, you could play around with the "priorities" and
so forth but you needn't do this at all because using software
interrupts is an unnecessary thing here, anyway...

It works like this, basically...consider the interrupt system to be
exclusive to hardware IRQs...that's where it works well and is a vital
component of a system...in fact, the use of interrupts here is
_GOOD_..._VERY GOOD_...it means there's no need to "poll" for that
particular piece of hardware and the CPU can go off to deal with other
things because the hardware itself will signal asynchronously the #INT
pin and will interrupt the flow to deal with that hardware _when_ it
needs it and _only_ when it needs it...this is an event-driven system
and that is a _very good_ system...interrupts are fantastic here...it
would be insane to consider things being any other way...

But the "INT" instruction to generate software interrupts? Use
sparingly...in fact, if possible, never use it at all...a legitimate
use is to "fake" a hardware IRQ for some reason, perhaps...the use of
this instruction under _single-tasking_ systems was essentially a
"relocation hack"..."INT" automatically indirects via the IVT or IDT
so that programs can have "INT 21h" or "INT 80h" written inside them
throughout...and if the code for "INT 21h" or "INT 80h" is moved or
changed or anything inside the OS, then all that needs to be done is
to change the entry in the IVT / IDT...there's no need to re-compile
all the programs...as we're talking about a _single tasking_ system
here, then issues like asynchronous hardware "competing" with a random
OS API call - and even potentially _losing_ this battle if priorities
have not been set correctly, which is clearly NOT what should be
happening at all...responding to the hard drive so as to "release" it
for other tasks for other programs clearly has the natural logical
priority in a multi-tasking system over calling a "DrawLine" API or
something - were NOT RELEVENT...yes, it was _fine_ for DOS to use "INT
21h" everywhere because the whole operating system worked entirely
_synchronously_ and was _single tasking_...thus, there were NO "other
programs" that might want the disk...and everything was synchronised
that the OS API would just sit there waiting for the disk to finish
before returning, anyway...things just didn't happen out of order on
such a system, as they do (and _should_ do to fully maximise the use
of resources :) on a multi-tasking system...

And the important point is that OS API _can be done_ with other
mechanisms...you can deal with the "relocation" issue in better
ways...such as at load-time and by using "CALL" or similar
device...which, due credit to Microsoft, they actually _have done_
with Windows...a rare example of where MS got it right and others got
it wrong...and those who know of my "Love" for Microsoft know that
it's far from easy to get such words to come out of my mouth when it
comes to Microsoft...but, well, facts are as facts are...Microsoft
obviously _did_ read the correct chapters of OS theory books on this
particular issue (not necessarily on other issues, mind you...but
here, they got it right, for once :), where others must have skipped
over those parts because they "sounded boring" or something and just
carried on doing things the DOS way, not really considering whether it
was still appropriate to do that in a multi-tasking system...

There is no "loop", no "contradiction" or anything like that here...my
opinion is consistent and, sorry, but "the toolmaker's view" and the
"not the best idea to use INT for software purposes in a multi-tasking
system" points are completely mirrored by many OS theorists and OS
textbooks (come on, I'm hardly likely to use such a crap-sounding term
as "toolmaker's view" off my own back...I'm a Lover of language and
that just sounds crap and is very undescriptive of what it actually
means...I'd never come up with that myself...but, in mentioning this,
someone pointed out to me what the "official" term was from the
authorities who'd actually come to much the same opinion as me on this
subject and, for clarity, I use that term so as not to introduce a
hundred different terms for the same thing, which would confuse
everyone unnecessarily ;)...I am, actually, for once, NOT really being
a "heretic" here...this time I'm reading from the established
"gospels" by the authorities in these matters...

And, note one final thing here, I am not saying "wrong"...using "INT"
isn't "wrong" and it will work...but it is "ill-advised" because there
exists _better_ options that have much more desirable consequences...

> Seems like we have some
> loop breaking to do here, and more than peoples computer operating
systems
> will break as a result.

Sorry, but you are just being slightly weird now...I'm not exactly
sure what you mean by the above but it almost sounds like some sort of
Maffia gangster "I'm going to break your legs" threat of violence or
something...geez Louise, I know I can say the odd "heretical" comment
from time to time but don't you think that's slightly
over-reacting...but, hey, if you want to get all "heavy" about things
then, fine, I'll back off as this is only a discussion about OS
architecture, for Pete's sake...hardly worth the "horse's head in the
bed" treatment, surely?

> Is it a tacit admission on your part that
> portability concerns are in all cases justifiable, in the end?

Right; First, I've never once said that "portability" is never
justifiable...my entire point, in fact, is that it should, indeed, be
_justified_...if you have a good reason then go ahead with my full
blessing...my concern is merely those cases were "portability" is
automatically installed, even where there's not really any benefit in
doing so or it might even be logically daft (e.g. something that's
already implicitly device- / platform-specific - a driver or file
system utility, perhaps - or where "portability" is unnecessarily
layered on top of "portability" causing a redundency in the system)...

Second, _how on Earth_ have you jumped to this particular conclusion?
Even if we accept that you genuinely _didn't_ see that I was talking
about two different things when saying "interrupts" (because they both
use the same interrupt mechanisms but are actually practically used
for two quite separate things...one - the hardware IRQ - is an
excellent thing and all steps should be taken to fully exploit
it...the other - the OS API on a software interrupt - is a means to
handle "relocation" issues in an easy way but which isn't really the
best method to use...

Right, so even accepting that you didn't see that very important
difference and believed that I'd said something inconsistent about
interrupts (which I haven't, in fact)...then how on Earth does this
now add up to the conclusion that it's a "tacit admission...that
portability concerns are in all cases justifiable"? That's akin to
working out that "two and two" equals 9,637 or something...it's not
even in the same universe, let alone ballpark, let alone even
marginally relevent here...

> In that
> case you're in danger of not only getting into peoples killfiles,
but
> getting disconnected from the network altogether! What will
probably
> happen is that something like a Unix operating system will be used
by an
> ISP to control program flow between terminals, leaving them with
minimal OS
> of the type you're suggesting.

Pardon? Now you're suggesting that "UNIX-like" operating systems are
unable to handle acting as interent servers? What planet have you been
living on all this time? Only recently has Windows been able to claw a
share in that market...heck, even MS's _OWN_ servers were infamously
running BSD until it was publicly pointed out that even MS don't trust
their own software, so they had to switch over for "PR" reasons...

I must confess to not totally comprehending your post or what it was
essentially all about...well, unless it was just about making your
"gangster" threats to break my bones or something...but, nonetheless,
it was enjoyable responding to it...

Beth :)