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


Richard Cooper wrote:

[RTCL..]
| 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.

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 :)
So IRQ8 is used only for the user-defined alarm message:
"hey wake up, it's time to leave the office".

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

[1mS PIT-base...]

Right, it can be made flexible as well, and for those which like
to have both (true real time and a variable PIT) the RTCL can be
optional set to fire 1024 times per second.

| > I also synchronise one 0..999mS counter by RTCL ...

| 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, ...

Yes, it needs individual adjustment on every PC, but can be automated.
1985: X-tals and clock chips weren't as cheap as today, but they were
more accurate then.

[..]
| 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.

Yes, that's why I said 'almost exact', the length of Seconds on the RTCL
vary by many clock-cycles anyway.

| > 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 see this in the opposite direction.
I wouldn't allow user-mode event-handlers to direct hook IRQ-handlers.

Also if an IRQ-routine would use some stack lines of the users stack,
the interrupted user code will not even recognise that something is/was
acting in kernel-mode behind his back, except for the lost cycles.

| 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.

I wouldn't let a user run his own user-space device-drivers anyway,
but the OS-design must offer an easy driver implementation and even
more easier API-functions (simple,short,fast,transparent).

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.

| 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.

Sure, fool-proved exception handlers must be in the OS, even stack faults
and a few others may not be recoverable, at least a safe return to a known
status can save us reboot.
But you sure don't mean Device drivers creation in user-mode ?

| 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.

Yes.

| 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.

Right, as I'm a hex-coder I like small modules ...

| 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.

This was exactly my reason to start with my own tools about 25 years ago,
and step by step I overruled DOS with my own functions until DOS wasn't
required anymore, the first version (i286) of KESYS was born.

| > :) 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.

Yes, just my needs for total freedom let me keep everything unprotected.

[experience and fast system recovery..]
Yes,
worst case are bugs in the file-/boot-loader and in the memory-manager.
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.

| 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.

True also here, but as we can already point it out ... :)
I see my own code with much more critical eyes than I would for others.

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

| I'm not sure I'd be up for it.

Me not either, but if the idea finds interest, I'd give it a hand with
some core-code and a few device driver modules.

| 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.

First thing would be to just collect and sort all the different demands,
targets, wishes,... on how API-functions 'shall' work in general.

| > 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?

'That' was a joke, it of course will need a very own version
which just uses the same API.

| 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.

Yes, my momentary OS version is different:
no paging, all code runs PL0, only one stack per CPU,
minor kernel protection by stack- and code-segmenting,
and all data are unprotected flat.

| 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.

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


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

My OS hasn't a text based source at all :)
it is fully written in machine code, so I see the binaries as the
language independent source. But my text documentation of structures,
function entry points and code blocks description show all details.
So everyone who got a disassembler with the tools in use can read it
in the preferred syntax.
Only a few of us may be familiar to interpret code without any comments
and most use commented text source anyway.
So I might use my latest disassembler to post my code as text source
and add a few comments manually.
[see my demo with HEXTUTOR and let me know if you would accept one
of the many output options there]

[dest,src] agreed.

[macros...]

| 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.)

:) At least once, it had to be said.

| > 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

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


| 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.

That comes from 'how they've been teached to see' programming ...

Except for different separators and never used stack-frames,
my source would look similar with RosAsm format:

GetPalette: ;768 bytes to buffer at ES:EDI
cld |mov dx 3C7h |mov al 0 |outb
|mov dl C9h |mov ecx 0300h |rep insb |ret

or with my old HEX_WORK standard (TAB-spaced):

GetPalette:
cld rw2=03c7 al=0 outb rb2=c9 rd1=0300 rep insb ret

or whatsoever may be wanted ...
__
wolfgang


.