blitz and loosecaboose

[Flexibal]

::blitz::
can you list all the floating point instructions the CPU/FPU has, with the cycle count of each? i just wonder what a library has to write for itself and what it can rely on the cpu for.


::loosecaboose::
i've really taken vema a long way already (vema... remember, that virtual message-passing o/s i started in qb... http://forum.qbasicnews.com/viewtopic.ph...light=vema) .

i moved to c++, i dont use any libraries like STL/MFC, etc., i've written my own classes for string, queue, array, etc., implementing them with only the functions i need and the way i want them. for example, my array has no "removeAt" method, and my queue class is synch'ed and can add blocks dynamically (you know, a cyclic queue, where you write at one block and lock it for reading, then read from block and lock it from writing, and then free it).

i was very happy the way i implemented it, considering i have never taken computer classes or other things that teach you how to do things. ANYWAY.

unlike minix (which i downloaded the src of), i'm not writing an os, i'm writing an oe (operation environment), something like a virtual machine that provide certain facilities like resource and memory management, but no files, for instance. the point of vema is not to run on any real computer or achieve any real functionallity; i do it for research only. currently it runs over windows, but i guess that since i never used any windows-specific libs, i could port it anywhere.

so, as i stated, vema is unlike minix. device drivers are not hardcoded into the kernel. the kernel provides only msg passing and msg handling. apart from that, the system predefines three resources: keyboard, mouse, and console. but, i stress again, these resources have no internal drivers. the keyboard just contains a buffer of 256 bytes, to which the key-state-map is copied by the kernel. now, some driver, called the keyboard driver, must poll this map, hold key-stroke counts, and send messages such as keydown/up/press. a second driver, called terminal driver, listens to these messages, and according to it's layout (en-us, for instance) will convert the keypress msgs to ascii, taking into account the state of the shifts and capslock. this works in theory, but i dont like the way the keyboard driver must do polling. i could of course define "virtual interrupts", e.g., the kernel sends RESOURCE_IN messages when a resource has some input, and then the keyboard driver will wake to read what's been pressed... but that scheme is fit only for input devices like the keyboard.

the console, for instance, is just a buffer of 80x25 characters. the terminal driver listens to MSG_TERM_WRITE msgs, etc., and writes characters to the console buffer, taking care of scrolling down when needed and moving the cursor. so an output-only device like the console does not fit the virtual interrupt scheme.

another thing is, creating resources on runtime. as i explained, the driver is just an app running in my VM, that provides a layer of abstraction to its users. just like that, a driver may allocate a block of memory and utilize it as a virtual disk, holding virtual files.

an app would send a create-file message, the disk driver would accept it, allocate a starting virtual sector, register that virtual file in some array, and return a handler. now, the app could send file-write or file-read messages like the normal file api we know.

another thing could be virtual hardware devices. i could just fill the resource buffer with some arbitrary data and let it process it. for example, every 100ms, i would fill the mouse-buffer with random data, then the mouse driver would process this data and move the mouse on the screen accordingly. that's just an example.

predefined resources mean that the resource's buffer is filled with raw input by the kernel. but if i could mimic raw input, by "manually"
having an app filling it for me, i could define any number of resources on runtime.

now that i think of it... the virtual interrupt method does work. i generalized it enough in my head already. shucks. i wrote all this in vain anyway, consider this a "progress report". if you have any comments, please do reply.

of course i still have problems with memory management... should it me dynamic? static? use a stack? a heap? pointers? qb-style? should everything be an object, like java/.net? making all variables objects makes life simpler for me, as i hold an array of variable-id's, each is associated a pointer to where the data is stored. this way, adding/removing vars is simple, but the overhead is quite large.

another problem i think i have is with multiple tasks of the same trap running simultaneously. but i'm not sure it's a problem :oops: ... i'd have to test it and see.


::other people::
get off my case






[Flexibal>

[TheBigBasicQ]

Wow, its really intresting. Would you be keeping us updated?

[LooseCaboose]

i've really taken vema a long way already

Cool. The operating environment idea is similar to .NET/Java, but it would be interesting to see a system that has a virtual machine at its core but implements enough of a kernel to allow features such as multiprocessing and interprocess communication.

the console, for instance, is just a buffer of 80x25 characters.

I would abstract things like this a little more. The console should be an arbitary sized buffer, probably flat rather than 2d, which is indexed based on row/column calculations for the given screen size.

an app would send a create-file message, the disk driver would accept it, allocate a starting virtual sector, register that virtual file in some array, and return a handler. now, the app could send file-write or file-read messages like the normal file api we know.

Yup, this is bang-on. Remember that sending the messages from user mode programs should have a friendlish level of abstraction, so you dont want something like:

Code:

file_handle = (file_handle_t *)send_message(FILE_CREAT, "file.txt");

Something like the following is a better approach:

Code:

file_handle = open("myfile.txt");

Your user mode library would then do the dirty working of converting the bottom one to the top one.

predefined resources mean that the resource's buffer is filled with raw input by the kernel. but if i could mimic raw input, by "manually"
having an app filling it for me, i could define any number of resources on runtime.

Again you are spot on. Unix has a filesystem called the dev heirachy which has files mapping to devices which can be read and written to (depending on access permissions). It is possible to do something like the following:

Code:

$ head 100 /dev/random > /dev/mouse

Which would write 100 bytes of random data to the mouse.

of course i still have problems with memory management... should it me dynamic? static? use a stack? a heap? pointers? qb-style? should everything be an object, like java/.net?

Each process should be allocated its own flat memory space, on a 32-bit machine you can access 4gb of virtual memory. Within that flat space you allocate each of the segments you talked about. Each program will have a fixed amount of code (text segment) so that can be allocated statically at the bottom (or top) of the address space. Then the stack (temporary data) typically grows downward from the top of the address space and the heap (semi-permenant data) grows upward. When the two meet you need to generate an out of memory error. Because programs rarely use all of the 4gb, you will need some code to determine which programs should have their memory map in phyiscal memory and which can be stored away on disk (ie swapping or paging). Code segments for example are stored on disk in the executable file so they dont need swapping out. Memory management is pretty complicated and I dont really have room to explain it fully here, but if you have more specific question Ill try and help out.

Keep up the good work.

[na_th_an]

::other people::
get off my case

PM exists.

[Flexibal]

loose - i wrote this long article... explaining things... took me two hours. then i press post, and "invalid session". press back, and everything i wrote is gone. so i'll write it some other time.




[Flexibal>

[wildcard]

loose - i wrote this long article... explaining things... took me two hours. then i press post, and "invalid session". press back, and everything i wrote is gone. so i'll write it some other time.
[Flexibal>

There is an extremely annoying bug in phpBB/php that causes posts/text boxes to not keep their messages. Many many good posts have been lost, I am trying to investigate but don't have a solution up yet.

[oracle]

wildcard, extend the session length before people are automatically logged out, that's all you can do at the moment.

Everyone else: if you think you're near the time limit (which wildcard will post in this thread (hint, hint )), post what you have written with a small message stating you're finishing it and then edit your post to restart the timer

[LooseCaboose]

There is an extremely annoying bug in phpBB/php that causes posts/text boxes to not keep their messages. Many many good posts have been lost, I am trying to investigate but don't have a solution up yet.

I usually copy long posts to the clipboard before posting them, so I can repaste them if I get the invalid session error. I have lost a couple of lengthy posts that I never bothered to retype.

wrote this long article... explaining things... took me two hours. then i press post, and "invalid session". press back, and everything i wrote is gone. so i'll write it some other time.

Thats cool. You can always PM me or email me at loosecaboose@linuxmail.org, I check it fairly regularly.

[SCM]

If it happens to you again, copy your text before you leave. Then you can just paste it back in again in another session.

[TheBigBasicQ]

I always type lengthy posts in notepad and save the file. That way i wont loose any of my posts if theres a blackout or i get the invalid session error =)