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


Richard Cooper wrote:

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

| Still leaves me with needing to compile NASM to run on my OS. I'd have to
| modify GCC so that it creates programs that work in my OS. I'll want to
| work on my OS while running my OS, so the assembler that it's written with
| has to run under it.

I see, at least one assembler must know about the new API.
It may not be enough to just modify the PE-header with other
API-function pointers.


| > I really do use IRQ0 driven 1mS time-slices.

| Now I'd set the real time clock to one second intervals for real clock
| time,

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

| then I'd use the PIT in one shot mode, ...

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. I also synchronise
one 0..999mS counter by RTCL for a more exact file date/time and others.

With this IRQ0-counters I can measure/delay/wait to cover all hardware
events in parallel and can swap focus to pending jobs from as many active
software tasks I may allow in (almost exact) true real-time.

So one question will be:
'real-time' or the same as WinLindoze 'block until guess-when' ?

[pro/con TSS]
| > Save/restore/swap only what's needed ...
|
| There isn't much in the TSS that you don't have to swap. ...
[...]

What I meant is that IRQ/EXC-handlers can/shall run in PL0,
so a fully protective task-switch would not be needed here.
This will only swap SS:ESP from the TSS if user-code is interrupted.

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

Last time I checked on TSS switch timing I measured more than 2000 cycles,
but this may depend on many things.
Perhaps you didn't involve the slowed code after TSS in the timing,
everything becomes 'newly accessed, so check if allowed' there.
Flush TLB on CR3 load seems to be a big time-eater also.

| > I think 'protection' has become a very paranoid used item ..
| > Total isolation may not be what we really want.

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

But right, for playing the user-role it would be better to not crash
on every typo.

| Now if you're writing an embedded system they you may well not want
| protection, but for a general use system, ...

I'm not sure if my OS can be called an embedded one,
it is a bootable standalone OS with a multi-user, multi-tasking
desktop GUI, but it never would execute 'foreign' code on just the
users will (has been proven as the best protection yet).
Granted, it is not a general use system yet.

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

| ...where my computer is busy doing
| other things of varying importance while at the same time I'm writing
| programs that are crashing left and right, I want some protection in
| there. It's a nice thing to have.

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

| Like I've said, I wouldn't want my OS to not have all of that protection.
| For an embedded system I wouldn't use protection, but for a desktop OS, I
| want it.

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


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

| Do you mean like none of them, and instead just write a new one?

:) No, I misunderstood. I meant the assembler authors will have to
modify their linking-routines to the new OS's API,
while you talk about the syntax to use for the OS-design work.

| On the other hand, all I can think of is '|' vs. ';' and "dest, src" vs.
| "src, dest", so maybe a signifigant number of us could agree on something.

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

But I don't think the used syntax is a main problem for OS-design teamwork.
The KESYS-project contain code modules written by various members, and
everyone uses his/her preferred tools to produce just binary files.
It's then on me to disassemble it into 'my view' for documantation.

Of course, a teamwork on a NG will need something understandable by all
participants.
I can easy read, until macros come into play:
FASM/NASM/RosAsm/HTML/(best)HEX.

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

__
wolfgang





.