Re: Maybe we should stop "Paging Beth Stone" already...

On Sun, 18 Sep 2005 08:39:59 -0400, wolfgang kern <nowhere@xxxxxxxxxxx> wrote:

The so common taught 'good coding practice'  may not see a solution
for an OS to run if the 'system clock' stops because of low battery :)

I think it would still work, it just would lose time when the computer was turned off.

But I assume and rely on RTCL, as this 0.50U$-chip will be in every PC. 

Last I checked it was actually $5.

Yes, it needs individual adjustment on every PC, but can be automated.

I'm just thinking about the last milisecond being only half as long as the others, but it could probably be made to sync well enough.

| Only if the IRQ handler is interrupting the kernel and not an | application.

??  I see this in the opposite direction.
I wouldn't allow user-mode event-handlers to direct hook IRQ-handlers.

Well what I mean is, if you've got a user-space process executing when the IRQ goes off, then you've got to do a TSS switch to get back to kernel space.

Also if an IRQ-routine would use some stack lines of the users stack,

Then a user space process could crash the driver by setting ESP to zero and then entering an infinite loop. It could happen accidentally given the correct circumstances.

I wouldn't let a user run his own user-space device-drivers anyway,

I certainly would. (at least, the non-hardware variety) Say a user just has a disk image of a DOS floppy and wants to read it. If they can load drivers, they can load the FAT driver and tell it to read the file as it's disk, and then they can access it with other programs just as if it were a real disk.

Driver development is a story on its own, hardware can't be emulated
and drivers must run in PL0, so doing it from a user-platform may not work.

In Linux, if you're root, you can get I/O permissions. If there were just some way to set up an IRQ handler, you could write user-space drivers. (of course, you wouldn't be able to make those things in /dev/, but I have a better idea than that)

But you sure don't mean Device drivers creation in user-mode ?

Certainly. The user would be 'root' of course, but user-mode none the less.

Many developers use emulators, but as the emulators around are far from
being perfect, they may hit the reset-button quite as often as I once had to.

So that's where things like "Does not boot on a real computer and only runs on versions of Bochs below 1.x." come from...

Fast and short code doesn't neccessarily mean 'unreliable'or 'complex API handling'

No, but usually fast is accomplished by cutting out features, and that's what I don't like. Cutting out TSS usage and replacing it with less reliable protection schemes will speed up the code, but the faster code won't have the same features as the slower code. That's what I was getting at, the features that I want, I want even if the OS would be faster without them.

So even though the OS could be faster with a less effective form of protection, I'm not interested in the speed, I'm interested in the protection.

My OS hasn't a text based source at all :) 

That's assembly taken to an extreme.

Like I've said before, unlike most assembly language programmers, I don't use assembly language for speed, I just use it because I like it. So when writing my assembly code, I just go with whatever is going to be easiest to read and write rather than worry about optimizing everything.

[see my demo with HEXTUTOR and let me know if you would accept one
 of the many output options there]


I'm in Linux now, so I can't run any DOS executables.

| modex_get_colormap:
| xor dword ecx, ecx
| xor dword eax, eax
| mov dword edx, VGA_PEL_INDEX_READ
| out word  dx, al
| mov dword edx, VGA_PEL_DATA
| .loop:
| in byte  al, dx
| shl dword eax, 8
| in byte  al, dx
| shl dword eax, 8
| in byte  al, dx
| mov dword [ebx + 4 * ecx], eax
| inc dword ecx
| test byte  cl, cl
| jnz short .loop
| ret

This seems to be a result of great books teaching
and fully misinterpreted optimisation hints. :)

What I don't get is the aligning of everything into columns (just makes it hard to read in my opinion), and the constant use of byte/word/dword prefixes which make reading even more difficult. The "out word dx, al" line isn't even correct, but I'm sure it still works since NASM probably just ignores the byte/word/dword nonsense.

| palette_read; enter " -- palette_read"
|   cld
|   mov dx, $3C7; xor al, al; outb
|   mov dx, $3C9; mov ecx, $300; repz insb
| leave; ret

Except for different separators and never used stack-frames,

Actually, my enter and leave macros have nothing to do with the enter and leave instructions by the same name. Here's the code for them:

%macro enter 1.nolist
  %ifdef debug_version
    section .rodata
    %%text db %1, 10, 0
    section .text
    push eax
    mov eax, %%text
    call debug_push
    pop eax
  %endif
%endmacro

%macro leave 0.nolist
  %ifdef debug_version
    call debug_pop
  %endif
%endmacro

If I assemble without "-D debug_version" on the NASM command line, they don't create any code at all, otherwise enter just defines the text string it's given and calls debug_push with a pointer to it as an operand, and leave just calls debug_pop.

Then if a crash occurs, the code that prints the register dump also prints everything that is on the debug stack, that way I know what the program was up to when it crashed. So if a crash occured in that function, then the register dump would mention " -- palette_write" telling me so.

Here's what a crash message looks like:

    Signal 11 recieved.

    EAX: 00000000  EBX: 00025800  ECX: 00000014  EDX: 00000000
    ESI: 08125820  EDI: 3FFFFFEC  EBP: FFFFFFEC  ESP: BFFFF784
    EIP: 08049125  EFLAGS: 00000000 00000000 00000010 00000010
                                               ..OD   SZ A P C
    Debugging Stack:

    Softer 122
    selector.asm - selector.run
     -- display_read
    orange.asm -- orange.input
     -- interpreter
    format.asm - format.convert
    !!! Signal Trap

    Happy debugging!

Thus, Softer's main function "Softer 122" called selector.run in selector.asm, which called display_read in the same file, which called orange.input in orange.asm, which called interpreter in the same file, which called format.convert in format.asm, which caused the segmentation fault, which called the signal handler.

Much more useful than the enter and leave instructions...
.