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

On Sat, 17 Sep 2005 07:09:35 -0400, wolfgang kern <nowhere@xxxxxxxxxxx> wrote:

Exactly how I do it. Date, time and alarm-clock are in the RTCL hardware,
so I use the things as they are designed for, ... at least here  :)

No one seems to like to use it's IRQ though. I guess people just use the PIT because that's what DOS uses, and of course DOS uses it because it had to run on hardware so old that it didn't have a real time clock. So we've got OSs that require a 386 for protected mode, but use the PIT for time in case there isn't a real time clock.

Here I use a fixed 1mS base and have 32 timout(down until zero)-32-bit
counters beside one master 64-bt (up/rollover)-counter.

The reason I like the idea of reprogramming the PIT is that it lets you schedual things exactly when you need them. For example, Linux 2.4 programmed the PIT to 10ms, and so it wasn't all that useful for syncing to the video retrace, which is 17ms at 60Hz. If it reprogrammed the PIT as needed, then when my program requested to be woke up 16ms later, it could actually do that.

Now 1ms is of course better, but then imagine someone comes along and needs to sync to 600Hz. If you just leave the timeslice size flexable by using the PIT in one-shot mode, then you can do that sort of thing, while at the same time you can increase performance by expanding timeslices to 1/18 of a second when there isn't anything running that needs more precise timing. So you get the best of both, sort of, at least you're only paying the price of having small timeslices when you actually need the small timeslices.

I also synchronise one 0..999mS counter by RTCL for a moreexact file date/time and others.

My only concern with that is having the two timers not exactly in sync, so that the last millisecond is shorter than the rest, or worse, it might count 999 or 1001ms in a second. For some reason crystal oscillators aren't as accurate as they were back in 1985.

That can kind of be fixed by keeping two system timers, one which tracks real system time, like calander and wall clock time, and another which is set to zero at boot and just goes up from there. Usually either a program wants to record the day and time a message was recieved, or it wants to know how many seconds are left until a network connection times out. One of those time values benefits from changing when the user changes the date and time, and the other one just breaks things if it changes. So there should be a distinction anyway.

But anyway, if you only update the calander/clock time once a second from the real time clock interrupt, and use the 'uptime' timer for other timings, then it doesn't really matter if the two don't exactly agree on how long a second is.

What I meant is that IRQ/EXC-handlers can/shall run in PL0,
so a fully protective task-switch would not be needed here.


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

I'd like for protection to be on everything. If drivers are easy to write, everyone will want to write them. If they're difficult to write, everyone will stick to user-space hacks.

So while omitting the protection would speed things up a little, I think it would really slow down the development. If you can just play around making a driver for something and when you mess it up you just get a register dump from it, that's a lot more fun than trying to make a driver and when you mess it up the system goes down and you have to reboot, and then you find that some of your source code changes weren't saved to disk before the crash.

We could certainly write a very fast OS if we made everything, including the web browser, just one big kernel process all in the same address space.

However, if we split things into smaller pieces, it'll be a whole lot easier to do, and easier to do means more likely to be done.

The reason I'd like a new OS is because I hate programming on all of the choices currently available to me. I wouldn't want to spend all of that time writing a new OS only to end up with yet another OS that's a bitch.

| Now I'm not sure why that takes 314 clock cycles. ...

Last time I checked on TSS switch timing I measured more than 2000

Mine are just the 'official' numbers which never take into consideration memory access times or anything at all really.

| I don't know about you, but I like it when I write a program and it
| crashes, and I don't have to reboot my computer because it overwrote
| part of the OS.

:) I learned to teach myself in 'take more care' by having a fully
unprotected, unrestricted and unlimited environment for OS-design.

I don't think that having the extra punishment of having to reboot would really help anyone write better code. It would certainly make them want to write better code, but if you don't have the skills, wanting them doesn't make them come any faster.

I've done assembly in Linux over the last five years. When I started I wasn't very good. Every other compile resulted in a crash, so I always sure to recompile every five or six lines just so that I had some idea where the crash occured. Now I amaze myself with how many lines of code I can type and assemble and have work without a problem.

I think that what helped me learn the most was that between not having to reboot and the wonderful register dump on segfault code I wrote, I spent a lot more time writing code than I spent debugging it.

It makes sense. When you make mistakes, all you can do is learn from them, and if you've got to reboot the computer first and then spend an hour playing with the code trying to discover what you did wrong, that's just an hour that you had to waste before you finally learned something. So at most you learn eight things a day. On the other hand, if your system stays running, and your segmentation fault catching code narrows your problem down for you, then you can learn something every five minutes.

After all, most programming bugs (at least mine) aren't simply a matter of carelessness, but are a matter of the programmer genuinely believing that the code that they've written should work. No amount of negative reinforcement will help that.

Nevertheless, let's create another OS. One which satisfy us all :)

I'm not sure I'd be up for it. Back when I had my little OS Design discussion going on on my web site, just reading and writing messages took all day. It was all that I did for the few weeks it was going on, and even then we didn't have a good design nailed down. We had some nice general ideas, but few things were really specific, and those that were I wasn't completely convinced were well enough thought out.

So when/if we create a new OS, then I will have an option for the
'fast unprotected mode' in my copy :)

I wonder if that could be made to work? I dunno, somehow I think most of the time in the TSS switch is related to reloading CR3, and without seperate address spaces in processes, you get that whole memory allocation problem I was talking about.

I really wouldn't care if the OS sucked up 20% of my CPU time, I'd still have 80%, and 80% of 1Ghz is 800Mhz, which is something I can live with if I like the OS. Of course, probably no one else feels the same. Everyone who writes an OS makes it a goal to have the fastest OS. I just want the OS that's easiest to develop for. I think that's what's best.

I prefer the scienists notation:
x=a*b
over the milk-maid's ground-school scribble:
1*1=1

Same here. I really hated how the TI-92 calculator I once had, in it's programming language you had to do this:

	a * b -> x

And it's supposedly a good professional scholarly type tool. I'd expect anyone who needs it's capabilities to be able to grasp the concept of destination on left, but I guess TI didn't feel the same way.

But I don't think the used syntax is a main problem for OS-design teamwork.

Well, I assume we'd all want to be able to compile it from source without having to download a dozen different assemblers.

I can easy read, until macros come into play:

Yes, those macros are a real pain. I personally only use a few. I've got the flow control things like if/endif, do/loop, etc. Then I made another called skip/land which just jumps over a piece of code. The real reason I like those macros is because otherwise I have to start making up a lot of little variable names, and that's no fun, but if I use the macros, then they make up the label names all on their own.

Then I've got my system trap macro, it's main advantage is that it declares the error string in the .rodata segment for me. Then there's another for system calls, and another to call functions with C argument passing, and one which results in lines like:

	status "entering the signal handler"

Which just declares the string and calls a function called easyprint which writes it to stderr. And of course my enter/leave macros which track what function is being executed for bug tracking.

What I don't like are the macros that other people use. (I was going to try to say something else, but that's all it really comes down to.)

What I can't/wont read is Java,Perl,C,C+-,GAS,AT&T, and similar.

What I won't read is anything written by someone other than me. Now I read through the Linux Real Mode Interface code the other day, and it was great code, it's how I would write code if I could write code that well. However, most of the time I end up seeing stuff like this:

	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

Here's the same code out of my program Softer:

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

I really don't understand how other people think.
.