OS Syatem reqirements

[srg]

Hi

Solar's comment about code bloat got be thinking

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

I'll start, when mine is complete enough to call it 1.0:
386SX or DX with 8MB RAM
Should be able to just fit on a floppy or might take about 5-10MB hard disk space at absolute max.

I will add features that are in later CPUs either as conditional compilation (lesser binary code bloat) or as descision based at runtime (binary portability: just move the file).

srg

[Candy]

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

Ouch, my weak point.

Since I consider the past the past, and I feel current things are not going to be used significantly in the future, supporting future things is way more important than supporting past things. Rather have 10 drivers for devices that are still being made than 1000 drivers for obsolete hardware.

In the same perspective, I'm aiming on top performance on AMD's, specifically the AMD64 platform. That, and 100% compatibles. Since this doesn't allow me much to do now (write a bootloader, save up for testing it on a real machine) I decided to write it also for newer duron/athlons which I own one of now. Because the AMD64s all have APICs and they solve a lot of cr*p with the old PICs I only will support APIC computers, shutting out the model 1 athlon and the model 3 duron. The rest of the athlon/duron family should be supported.

Of the intel family, I have no idea. Whatever works.
That is, probably the P3, P4, PM and maybe those EM64T's, but only in 32-bit mode (they ripped out the syscall in 64-bit mode while supporting it in 32-bit mode... stupid?).

Memory would be as I require it to put drivers in, but probably at <64M for the first few years. Only when it starts getting used might that increase.

Harddisk space, what you want for your files. 200M should suffice for a while, probably some years to a decade. Of course, placing numerous user files will probably increase disk space requirement

Possible later computers (and em64t crap should it become somewhat popular) will be added as a separate kernel target. All modules must be compiled specifically for that kernel, so I hope that day never comes

[srg]

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

Ouch, my weak point.

Since I consider the past the past, and I feel current things are not going to be used significantly in the future, supporting future things is way more important than supporting past things. Rather have 10 drivers for devices that are still being made than 1000 drivers for obsolete hardware.

In the same perspective, I'm aiming on top performance on AMD's, specifically the AMD64 platform. That, and 100% compatibles. Since this doesn't allow me much to do now (write a bootloader, save up for testing it on a real machine) I decided to write it also for newer duron/athlons which I own one of now. Because the AMD64s all have APICs and they solve a lot of cr*p with the old PICs I only will support APIC computers, shutting out the model 1 athlon and the model 3 duron. The rest of the athlon/duron family should be supported.

Of the intel family, I have no idea. Whatever works.
That is, probably the P3, P4, PM and maybe those EM64T's, but only in 32-bit mode (they ripped out the syscall in 64-bit mode while supporting it in 32-bit mode... stupid?).

Memory would be as I require it to put drivers in, but probably at <64M for the first few years. Only when it starts getting used might that increase.

Harddisk space, what you want for your files. 200M should suffice for a while, probably some years to a decade. Of course, placing numerous user files will probably increase disk space requirement

Possible later computers (and em64t crap should it become somewhat popular) will be added as a separate kernel target. All modules must be compiled specifically for that kernel, so I hope that day never comes

year, each to their own. I personally want mine to run on the widest range of machines possible (you don't need an ultra fast machine to do certain tasks). Also that is probably driven by my interest on old computers as well as new ones.

srg

[Dreamsmith]

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

I'm shooting for being able to fit the OS code on a 32K ROM, of course including only drivers necessary for the device it is embedded in. RAM requirements should be in the same ballpark...

[Candy]

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

I'm shooting for being able to fit the OS code on a 32K ROM, of course including only drivers necessary for the device it is embedded in. RAM requirements should be in the same ballpark...

darn... I'm feeling stuffed at 24k already, and I considered myself to be a non-bloat compared to Linux and Windows...

Of course this includes a few bits of static data, of which I do need a lot (to support a lot that is). Sure you don't want 1M or 16M ROM/RAM?

[Dreamsmith]

Sure you don't want 1M or 16M ROM/RAM?

I would love that, alas it's not always an option.

Just to put things into perspective, I believe the average computer in use today has <64K RAM. Less than 5% of computers in the world are sitting on people's desks or in server rooms -- the vast majority of them are operating your microwave ovens, controlling the fuel pumps in your cars, displaying information on the LCD displays on your stereos, and other similar tasks. It's a rare computer today that actually has more than 64K of RAM...

[Solar]

My aims for Pro-POS - before I discontinued the effort - were a bit different in that I wanted it to become a general purpose OS. Capable of driving web servers as well as desktops, laptops, and handhelds. As such, it would have been designed to be scaleable on a modular basis.

I started with a prototype kernel aimed at the desktop / workstation / small server range; I opted for an i586 minimum because of a couple of nice CPU features not available before (can't really remember which anymore, though). The release version would probably have required an i686, if not more - not because I'd need the MHz, but because later generations introduced interesting features to be exploited on OS level, and honestly, it would take a decade to bring an OS to release, and who'd own an i586 or older by that time?

Read-only booting was a perceived requirement, for booting off CD-ROM or embedded ROM images. As for the size, well... I intended to make it small and effective, and see how much it needed in the end. Call me a pragmatic.

---

As for the PD C Library I am working on, you'd think that the minimum implementation of e.g. a <string.h> would be obvious - but I was surprised to see that most existing implementations are pretty careless about how many local variables they require. I now have a <string.h> implementation that hardly, if ever, uses local variables at all - solely operating on the parameters passed on the stack.

I also squeezed the lookup table in <ctype.h> (the one telling you about isalpha / isdigit / isspace and their ilk) down to an array of char... instead of an array of short, as even P.J. Plauger (of Dinkumware fame) claimed to be unavoidable, only at the cost of minimal additional logic in isgraph and isdigit. That means, for each additional locale, the lookup table will be 257 byte, not 514... and I fully intend to continue that path.

</shameless plug of PDCLib, milestone 1 to be released by end of 3Q2004>

[Brendan]

Hi,

My OS's minimum requirements are:
80486
2 Mb of RAM
Any VGA video card
Keyboard
Floppy drive

I'm aiming for every 80x86 compatible computer equal to or better than the minimum requirements. This includes support for multi-CPU, PAE, NUMA, 64 bit, Intel/AMD/Cyrix, etc.

I currently have 4 kernels (with/without PAE, and with/without multi-CPU support), and later on I'll have 2 more kernels for 64 bit (with/without multi-CPU support). My boot code detects which features are present and automatically selects the most appropriate kernel from the kernels available in the boot image. This way I can have an "OS installation boot image" that'd work for all computers.

I support old computers because the OS is a distributed OS, and old computers are extremely cheap. I don't support 80386 computers because they don't have INVLPG or native FPU exceptions. They also tend to use expanded memory rather than extended memory, and CGA rather than VGA. Working 80386 machines have also become very difficult to find, and therefore (IMHO) the extra "market share" you'd get from supporting them doesn't justify the amount of extra work needed.

Also (to a limited extent) I agree with Candy. By the time my OS reaches the point where it can be considered a serious option for normal users, the top of the line computers of today may be almost obsolete. During development however it'd be good if other developers could set up a "cluster" of cheap/obsolete computers.


Cheers,

Brendan

[Pype.Clicker]

i assume large cache (i mean, larger than 8KB for efficient microkernel operations), i'm assuming "global page" and CPUID, and i'll probably be assuming Virtual Mode Extensions for my VM monitor

Though Clicker uses modules and has a way to decide which's the "best" driver to load based on device inspection and simple rules (like "bonus +5 if UDMA supported by the driver"), so i could have the pager replaced by a PAE-aware subsystem if needed

afaik, minimal RAM support is 12MB. below that, you're running in degraded mode.

I don't know too much for disk space requirements, since i'm still working with the kernel, but the kernel itself and the pack of modules it uses could fit a floppy and are used read-only so far...

[crc]

What are the system requirements for each of the OSs that your making, so what sort of system will you os need?

At the moment the minimum system is an 80386sx with 2MB RAM, text capable video card and monitor, qwerty keyboard, and a floppy drive. I'd recommend 4MB ram, VGA capable video card & monitor, and a hard drive though. I don't expect the minimum requirements to increase anytime soon.

It can be made even smaller at the cost of programability. I've done versions that use less than 10k of RAM, but that doesn't allow any non trivial program to be written or run. Given 32-64k of RAM, a lot more can be done.

With a few KB of hardware init code, the OS kernel could fit on a small ROM. Then you'd need less RAM (just enough for i/o buffers, the dictionary, and the code space); a minimum of 3k over the kernel size (the kernel is currently ~5k). So the smallest possible footprint at this point is ~8k. That would give (barely) enough space for a very simple application.

Seriously though, since my OS is designed for older PC's, the resource limits I've set aren't too demanding. I try to keep things simple, yet workable, for the uses I have in mind.

[srg]

Hi,

My OS's minimum requirements are:
80486
2 Mb of RAM
Any VGA video card
Keyboard
Floppy drive

I'm aiming for every 80x86 compatible computer equal to or better than the minimum requirements. This includes support for multi-CPU, PAE, NUMA, 64 bit, Intel/AMD/Cyrix, etc.

I currently have 4 kernels (with/without PAE, and with/without multi-CPU support), and later on I'll have 2 more kernels for 64 bit (with/without multi-CPU support). My boot code detects which features are present and automatically selects the most appropriate kernel from the kernels available in the boot image. This way I can have an "OS installation boot image" that'd work for all computers.

I support old computers because the OS is a distributed OS, and old computers are extremely cheap. I don't support 80386 computers because they don't have INVLPG or native FPU exceptions. They also tend to use expanded memory rather than extended memory, and CGA rather than VGA. Working 80386 machines have also become very difficult to find, and therefore (IMHO) the extra "market share" you'd get from supporting them doesn't justify the amount of extra work needed.

Also (to a limited extent) I agree with Candy. By the time my OS reaches the point where it can be considered a serious option for normal users, the top of the line computers of today may be almost obsolete. During development however it'd be good if other developers could set up a "cluster" of cheap/obsolete computers.


Cheers,

Brendan

I will be supporting the INVLPG instruction on 486 machines (I also want my os to run on Nx586 machines BTW They are like fast 386s). The two options I have are:

* I will add features that are in later CPUs either as conditional compilation (lesser binary code bloat), so for each CPU family you recompile the kernel.

Or

* As descision based at runtime (binary portability: just move the file), so based on a variable the instruction would be run or not (the variable holds the CPU family and is filled by the CPU detection).

Which would be better?

BTW Dreamsmith, the machines you're talking about are embedded computers and that's the sort of thing that my Uni course is all about. The chip my Uni loves is the PIC16F877 wihich has 14336bytes of program memory, 368 of RAM and 256byte Data EEPROM (a bit small for your OS but the ATtiny15 has 512 words of flash for program and just it's 32 registers for variable storage), surely this is mor ethe sort of thing that what you listed would be using (I am still very much a noob at this though)?


srg

[Candy]

what about runtime invalid opcode handling? The 386 throws an invalid opcode, you instead of handling it like an error clear the page cache and return

[srg]

what about runtime invalid opcode handling? The 386 throws an invalid opcode, you instead of handling it like an error clear the page cache and return

That is an excellent idea! Brendan to add that to add support for the 386 as well.

But, on a 386 based machine, wouldn't that really slow things down a lot?

srg

[Candy]

But, on a 386 based machine, wouldn't that really slow things down a lot?

I thought it up from the point of making them usable, not fast.

They'll probably delay a lot, if you take care writing it it'd end up to 40-80 cycles for it. Counting the cost of flushing the entire TLB, that's not so much.

[Brendan]

Hi,

I will be supporting the INVLPG instruction on 486 machines (I also want my os to run on Nx586 machines BTW They are like fast 386s). The two options I have are:

* I will add features that are in later CPUs either as conditional compilation (lesser binary code bloat), so for each CPU family you recompile the kernel.

Or

* As descision based at runtime (binary portability: just move the file), so based on a variable the instruction would be run or not (the variable holds the CPU family and is filled by the CPU detection).

Which would be better?

I don't like OS's where the user is expected to compile the kernel before using it for best performance. It makes it hard for normal users (as opposed to programmers, system administrators) to install the OS. Also one of my goals is to have a single floppy disk which can be used to boot any supported computer with the absolute minimum of configuration required (for demonstration and installation purposes).

This is why I have multiple kernels in the boot image - so kernels can be pre-compiled with every possible combination of conditional assembly options. Of course increasing the number of options exponentially increases the number of kernels (2 options = 4 kernels, 3 options = 8 kernels, 4 options = 16 kernels, etc).

Because of this exponential increase I use seperate kernels where the beneifits are justified, and runtime decisions otherwise. For example, there's a major difference between single CPU and multi-CPU kernels, but determining if the global pages are supported is a runtime decision.

Also I wouldn't use the CPU family to determine what the CPU supports. Instead I'd create a set of feature flags which would include those returned via CPUID/eax=1, CPUID/eax=0x80000001 and additional flags for features that aren't reported via CPUID (e.g. BSWAP, XADD, CMPXCHG, INVD, WBINVD, INVLPG and FPU presence).

Rather than checking these feature flags every time it can be better to do it once and have multiple routines. For instance, your kernel could have 4 different page fault handlers and select one of them during boot when the IDT is being configured. You can also use indirect calls to pre-selected functions rather than testing and branching each time.

Candy's suggestion of using the invalid opcode handler is also a good idea because it allows unsupported instructions to be used by user-level code. For e.g. if an application contains the BSWAP, XADD or CMPXCHG instruction it can still run on an 386. Things like CPUID, FPU, MMX and SSE can also be emulated by the appropriate exception handlers.


Cheers,

Brendan