Re: learning asm.

• Previous message: sinewave: "Re: Review of Art of Assembly Language"
• Maybe in reply to: Beth: "Re: learning asm."
• Next in thread: Beth: "Re: learning asm."
• Reply: Beth: "Re: learning asm."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 08 Nov 2003 17:03:06 -0600

>
>> 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. The question is,
where is the Assembler OS? Forth, in its modern incantation, is close,
from which we learn that these perspectives are mutually incompatible. 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? 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.

> ....
> 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. 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. Why isn't there even one respectable compiler written in
pure Assembly? It all begins with the answer to this question.

> ....
> 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, 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. I mean, first you
complain that interrupts are wrong, and now you are all for them, and all
for the sake of porting C64 games of all things! Seems like we have some
loop breaking to do here, and more than peoples computer operating systems
will break as a result. Is it a tacit admission on your part that
portability concerns are in all cases justifiable, in the end? 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.

-- 
http://www.costarricense.cr/pagina/ernobe

• Previous message: sinewave: "Re: Review of Art of Assembly Language"
• Maybe in reply to: Beth: "Re: learning asm."
• Next in thread: Beth: "Re: learning asm."
• Reply: Beth: "Re: learning asm."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]