Re: Paging Beth Stone


Richard Cooper wrote:

[...]

| > I don't think it needs new tools, most of the assemblers around
| > can be modified to work for any API.

| Yes, but the problem I was looking at was how do I get NASM to work
| in my new OS without porting over GCC?

How about just rewrite the assemblers 'linker'-part?

| Then once it's running, what do I do with the object files it creates?

:) the same as with all other OS-depended parts .. ?
I think portability is a fiction for not fully abstracted VHLL-source.

| I figured it'd be simpler just to write my own assembler, and put all of
| it's OS specific things in just one little file, then porting it to my OS
| or any OS is just as simple as rewriting the function that opens and reads |
and writes files.

Yes, I also wrote my own tools (HEXEDIT and KESYS-script),
but merely to have unrestricted and independend

| > I found only two reasons for using the slow hardware task-switches:
| > Stack-faults and Debugger. Software multitasking is much faster than TSS.

| TSS isn't so bad. Everyone just sees that a TSS switch takes 314 clock
| cycles and they're like "OMG! That's so slow!"

I counted some more cycles here, if it only were just 314 cycles ...

| You'd have to do 10,000 of them a second to take up 1% of your CPU time.
| If you do 1ms timeslices, that's 2000, which leaves another 8000 for
| an interrupt every 0.25ms.

I really do use IRQ0 driven 1mS time-slices.
But here the OS decides which pending job got top priority
and if any 'protection' is required at all or not.

Most jobs are kernel-functions anyway, so here is no reason
to alter the protection-level.
I mean all IRQ- and EXCeption-handling shall always run with PL=0,
while event-handlers may reside in the users space.
But again, here the OS can already act on any 'IF EVENT'-kernel-job
before it gives focus to the user-thread.

| Considering what you get with TSS, I don't think that even 2% of
| the CPU is too much to spare.

| If you don't use TSS, you've still got to swap all of those registers
| manually, load a new CR3, and start making use of those segment
| protections (call gates et. al.) since it's no longer possible to give
| applications an address space that's totally isolated from the kernel.
| So how much processor time can you really save while still maintaining
| memory protection?

Save/restore/swap only what's needed ...

I think 'protection' has become a very paranoid used item ...
Total isolation may not be what we really want.
The OS itself (the instance which allow user-code execution) must
be able to access all user memory at every time.

Why waste memory with a new set of page tables for every task?

And it may often improve performance if two user-threads can
communicate by shared memory rather than detour over the OS.

Do we really need to lock out I/O instructions from user space ?

Sure, when all the offered protection is required (which I doubt),
then TSS-switching may be more effective than discrete switching.

| > And as non-M$ OS-developers are very individual folks,
| > I'm afraid the idea of an ALA-OS died before it even started.

| Even if we all agreed on the design of the OS, I doubt we would all
| agree on the assembler to use.

Now this would be a lesser problem, I'd say use all which support
the new API :)

| It would take a lot of compromising, that's for sure.

Yes. As the whole life seems to be ... ;)

__
wolfgang



.