EDE - Personal Suggestions and Ideas

EDE - Personal Suggestions and Ideas

[Miguel Bolanos]

Greetings,

As a result of the fact that ELKS seems to be back to life, I have been
thinking myself a lot of things.. as you may have noticed i encouraged
everyone in the mailing list to provide the developers some input what
they  consider the future of elks should be, so i also have somethings
in mind that i want to see accomplished, and that i will for sure work
hard on.

Some days ago a journalist send me an email asking for the advantages
that elks has to offer to the countries of the 3rd world, due to the
fact that elks is intended to run on very old machines... the kind of
machines that can be easily found over there... later.. a very realistic
comment came up on the IRC channel "People now days is so used to
machines with HUGE processor, memory and storage capacities, that are
not longer aware of the things that can be done with machines that have
limited resources.", this is indeed very true, old operating systems
used to make many useful things with this kind of boxes.. and there are
even very interesting projects around that could be in someway or
another ported to elks.. more specifically become part of EDE.

Many people have made me the question this 2 questions:

"What's the purpose of ELKS?"
"What's your goal on your ELKS contribution?"

I personally believe that we should focus ELKS on not a "for fun"
project but turn serious, now I'm not willing to be misunderstood here..
but i believe that more than wish lists we should have very well defined
goals for the project.

I would like to say that my personal goal, is get a kernel that has:

- TCP/IP support. (Yes Alan i know we already have, i just want to 		 
point each thing i believe important even if it 		  already exists)
- PPP support
- Support for various NICs
- swap support
- maybe ext2fs support.

Then get EDE to have the following features:

- Capable of been installed on a hard disk ( i know, done)
- Boot loader
- Maybe implement something like bootsplash or Linux Progress Patch
- X support.. perhaps Microwindows can be the solution?
- An internet browser
- a Gui mail client
- maybe an irc client
- A little "office" suite

With only this little features we could make a HUGE contribution not
only to the countries in the 3rd world, but in many others that have a
very unstable economy and can't afford to have the top of technology to
empower the education for example, now doing this won't mean that ELKS
will no longer be intended for embedded systems (just in case anyone
misunderstands me)

Anyways this is just my personal little idea - project, hopefully others
will share my vision.

Comments, suggestions, improvements.. are very welcome :)
best wishes

Mike

Re: EDE - Personal Suggestions and Ideas

[Gábor Lénárt]

Re,

On Tue, May 25, 2004 at 07:33:08AM -0600, Miguel Bolanos wrote:
> Greetings,
> 
> As a result of the fact that ELKS seems to be back to life, I have been

Or at least the traffic of the mailing list ;-)

> Many people have made me the question this 2 questions:
> 
> "What's the purpose of ELKS?"
> "What's your goal on your ELKS contribution?"
> 
> I personally believe that we should focus ELKS on not a "for fun"
> project but turn serious, now I'm not willing to be misunderstood here..
> but i believe that more than wish lists we should have very well defined
> goals for the project.
> 
> I would like to say that my personal goal, is get a kernel that has:
> 
> - TCP/IP support. (Yes Alan i know we already have, i just want to 		 
> point each thing i believe important even if it 		  already exists)
> - PPP support
> - Support for various NICs
> - swap support

Swapping? It's not so trivial ... Sure, if you assume that context switching
can only be done by the scheduler, you can find an algorithm to notify
a "swap deamon" (or whatever) to do swap in/out, but there is an important
difference between this behaviour and swapping eg in Linux: an OS running
on a hardware doing "paging" (like 386+) you can swap in/out per page basis,
while ELKS behaviour on 8086 could be only a 'swap the whole process'
stuff, since there is no hw level mechanism to 'swap out a page and mark as
virtual or something and let to generate an exception which can be used by
OS to do swapping back that page'. On 286 you CAN do something similar with
exceptions but since there is no paging, only a whole segment can be paged
in/out. There was an idea (by me) to alter size of the segment to be able
to swap out the 'tail' of a segment with setting size to some lower value
than the actual used size so refeering to offset greater than that size
would trigger an exception. However it's far from the page based stuff
can be done on a 386 like arch, sure ...

> - maybe ext2fs support.

And what about journaling? ;-)

> Then get EDE to have the following features:
> 
> - Capable of been installed on a hard disk ( i know, done)
> - Boot loader
> - Maybe implement something like bootsplash or Linux Progress Patch
> - X support.. perhaps Microwindows can be the solution?

So, some framebuffer-like feature would be usefull, both for having
bootsplash and other silly :) stuffs, and implementing some whatever
windowing system on the top of it, like picoGUI, or whatever, even
svgalib like apps but using fb instead.

> - An internet browser

You mean web browser?

> - a Gui mail client
> - maybe an irc client

It would be quite simple, I written a little iRC client of course without
any scripting, logging, etc whatever complex feature, but the core iRC
protocol is VERY simple.

> - A little "office" suite

mvi ("mini vi") with clip? ;-)

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EDE - Personal Suggestions and Ideas

[sandeep]

hi,
may be i don't quite understand ELKS much being a newbie here, but what's 
complex issue in having multiple segments on elks-8086?

let's assume well behaved program running on elks, that has 4 different segments 
in use (CS, DS, ES, SS) and all the accesses made by it are wrt segment registers.

when this program is taken off, it's all the segment registers are also saved in 
context info. apart from this elks kernel also keeps track of the extent of 
these segments used, so that moving segments around in the memory is convenient.

next time when the program is brought in, whereever it's corresponding segments
have been placed in memory, segment registers are appropriately set and control 
is passed back to the program via an iret call.

of course some information manipulation is required for implementation of this. 
but we get the flexibility to move the segments around.

-- 
regards
sandeep
--------------------------------------------------------------------------
Loose bits sink chips.
--------------------------------------------------------------------------

Re: EDE - Personal Suggestions and Ideas

[Eduardo Pereira Habkost]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Thu, May 27, 2004 at 11:37:42AM +0530, sandeep wrote:
> hi,
> may be i don't quite understand ELKS much being a newbie here, but what's 
> complex issue in having multiple segments on elks-8086?
> 
> let's assume well behaved program running on elks, that has 4 different 
> segments in use (CS, DS, ES, SS) and all the accesses made by it are wrt 
> segment registers.
> 
> when this program is taken off, it's all the segment registers are also 
> saved in context info. apart from this elks kernel also keeps track of the 
> extent of these segments used, so that moving segments around in the memory 
> is convenient.
> 
> next time when the program is brought in, whereever it's corresponding 
> segments
> have been placed in memory, segment registers are appropriately set and 
> control is passed back to the program via an iret call.
> 
> of course some information manipulation is required for implementation of 
> this. but we get the flexibility to move the segments around.
> 

You are right, but this is true only if you assume that the program
don't try to mess with the segment registers by itself, or store in
memory the values of the segment registers for using them later. That
is what was being discussed.

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: EDE - Personal Suggestions and Ideas

[sandeep]

hi Eduardo,

Since my earlier mail was focussed wrt to 8086/88, I am continuing with that 
only as reference when voicing few suggestions.

> You are right, but this is true only if you assume that the program
> don't try to mess with the segment registers by itself, or store in
> memory the values of the segment registers for using them later. That
> is what was being discussed.
That issue comes with user writing assembly programs and messing around.
To start with the work, why not assume that user will only be writing C programs 
for time being and gcc/any other compiler (and corresponding c libraries) can be 
modified to handle the above issues.
I am hopeful, as the work progresses, ideas will take better shape.

AND guidelines can be laid for the assembly programmer. IF (s)he doesn't follow 
(s)he himself will be responsible for trashing the system.

Here are my 2 cents on the issues (and a lot needs improvement and filling the 
gaps) --

* to start with (a dirty design), compiler generated code, limits code, data and 
stack to 64KB maximum (CS/DS/SS) and uses only 64KB (ES) for dynamic memory 
allocations.

* in case data/code is more than 64KB, it should be managed via code and data 
overlays. these overlays could be 4/8/12/16 KB in size (to keep things simple 
may be can start with 8KB) mapped into fixed location in CS/DS segments. no far 
pointers, only near pointers.

with this in place OS always have to bother with only 4 segments maximum 
(suggestions in my previous mail wrt 8086/88). in the scheme so far we don't 
endup with the need to store segment id anywhere in some variables. but in a 
logical sense total space for program in memory at any time is fixed at maximum 
256KB, though we have much more memory available for user program.

This next idea possibly hides alternatives to current idea.

* we want to go beyound 256KB now. we cookup one table [with fixed limit] that 
is kept as a part of program related information, that informs where in memory 
the segments related to program are currently located and what is their length, 
that helps OS to track them and relocate them.
for ex. ((seg1,len1),(seg2,len2).....(segN,lenN))
all the segs are saved onto disk, when process got moved out, we remember the 
order, and next time wherever we put them in memory, appropriately update them 
in this list concerning programming related information. assuming whenever the 
new segments are loaded into segment registers by program, they are picked up 
from this table. other values of CS/DS/ES/SS are anyways handled in same manner 
as in earlier mail.

* similar treatment can be given to far pointers (allow only global/static far 
pointers for time beings) that get stored in same section, that can be handled 
in some special manner. all these far pointers have segment-offset format and 
the segments part can be updated in similar manner via the OS, some bit of 
housekeeping/supporting information will be used for this. this will keep far 
pointers fine across program removal and put-backs.

-- 
regards
sandeep
--------------------------------------------------------------------------
Loose bits sink chips.
--------------------------------------------------------------------------

Re: EDE - Personal Suggestions and Ideas

[Gábor Lénárt]

On Fri, May 28, 2004 at 01:39:59PM +0530, sandeep wrote:
> Since my earlier mail was focussed wrt to 8086/88, I am continuing with 
> that only as reference when voicing few suggestions.
> 
> >You are right, but this is true only if you assume that the program
> >don't try to mess with the segment registers by itself, or store in
> >memory the values of the segment registers for using them later. That
> >is what was being discussed.
> That issue comes with user writing assembly programs and messing around.

Wrong, because there is no such thing like 'C program' from the view point 
of the CPU. It runs machine code. It's ANOTHER thing that this machine
code was produced by a C compiler/linker/etc, or it's 'hand coded' in
assembly and was assembled by the assembler and/or linked/etc into CPU
runnable machine code. My only point is that we should generally speaking
that we have or have not this feature, and probably we should not use
rules 'only C is allowed'.

[...]
> * similar treatment can be given to far pointers (allow only global/static 
> far pointers for time beings) that get stored in same section, that can be 
> handled in some special manner. all these far pointers have segment-offset 
> format and the segments part can be updated in similar manner via the OS, 
> some bit of housekeeping/supporting information will be used for this. this 
> will keep far pointers fine across program removal and put-backs.

And again, it's quite interesing that 'far pointer' notion is only
introduced by C compilers on machine without 'flat' addressing model.
However it's only because you assume that you can address the whole memory
in once. But you shouldn't and eg an assembly coder does not even have
problems to use multiple segments. (S)he does not even know what is 'far
pointer' ;-)

So it's better to provide an OPTIONAL mechanism to write multi segment
programs and it's up the the program/compiler/programmer/whatever to
handle the situation because it may varies on the certain ability of
used compiler, on task you should deal with it, etc etc etc.
That's why EXACTLY why I've been talking about SIMPLE implementation in
kernel and my theory to leave to the program to handle the high amount of
this complex work if it really needs this multi segment relocatable stuff
...

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EDE - Personal Suggestions and Ideas

[David Given]

On Friday 28 May 2004 09:10, Gábor Lénárt wrote:
[...]
> Wrong, because there is no such thing like 'C program' from the view point
> of the CPU. It runs machine code. It's ANOTHER thing that this machine
> code was produced by a C compiler/linker/etc, or it's 'hand coded' in
> assembly and was assembled by the assembler and/or linked/etc into CPU
> runnable machine code. My only point is that we should generally speaking
> that we have or have not this feature, and probably we should not use
> rules 'only C is allowed'.

One interesting consequence of dealing with C is that C insists that you can 
take pointers to things on the stack. This means that the stack has to live 
in the data segment.

However, the 8086 doesn't have to do this! You can put the stack in a 
completely different segment, if you like. If you do, the only way of 
accessing it is via stack-relative addressing modes, but the 8086 was 
designed to make this easy. (If you've ever programmed on the Z80, which 
*wasn't* designed to make this easy, you'll realise just how nice 
stack-relative addressing modes are.)

Unfortunately, if you put the stack in another segment, you can't take 
pointers to it from C. Imagine this code:

void settozero(char* pointer)
{
	*pointer = 0;
}

char global;
void main()
{
	char local;

	settozero(&local);
	settozero(&global);
}

As far as the settozero() function is concerned, it doesn't know whether the 
pointer argument should be accessed with DS or SS.

But if you're not programming in C, you don't have this limitation. Unix 
traditionally is programmed in C, so people don't think about this much, but 
it would be really nice if the kernel would manage all the segment registers 
and not just CS and DS. So that, if you like, you could load a binary that 
allocated all four segments. This would allow nice features such as a Basic 
interpreter that stored its byte-code in ES, its working stack in SS, and 
used DS for workspace.

I haven't looked at the source, so I don't know how much extra work it would 
be, but I suspect it wouldn't be hard to extend the kernel to do this. This 
way the multi-segment people can be happy, plus we keep the clean design of 
the kernel (and avoid the hideousness of far pointers).

-- 
+- David Given --McQ-+ "...you could wire up a *dead rat* to a DIMM
|  dg@cowlark.com    | socket, and the PC BIOS memory test would pass it
| (dg@tao-group.com) | just fine." --- Ethan Benson
+- www.cowlark.com --+ 
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EDE - Personal Suggestions and Ideas

[sandeep]

>>>You are right, but this is true only if you assume that the program
>>>don't try to mess with the segment registers by itself, or store in
>>>memory the values of the segment registers for using them later. That
>>>is what was being discussed.
>>That issue comes with user writing assembly programs and messing around.
> Wrong, because there is no such thing like 'C program' from the view point 
> of the CPU. It runs machine code. It's ANOTHER thing that this machine
> code was produced by a C compiler/linker/etc, or it's 'hand coded' in
> assembly and was assembled by the assembler and/or linked/etc into CPU
> runnable machine code. My only point is that we should generally speaking
> that we have or have not this feature, and probably we should not use
> rules 'only C is allowed'.
My idea is - when program is loaded OS sets up segment registers for the 
program. In the compiler generated program user is saved from headaches of 
bothering about setting the segment registers etc. I hope you noticed that I had 
also said - "AND guidelines can be laid for the assembly programmer" and any 
other language is also fine as long as it takes away the headaches from 
programmer. I am pro-solution that takes headaches away from programmer. Just 
cutting off this here. :)

-- 
regards
sandeep
--------------------------------------------------------------------------
Loose bits sink chips.
--------------------------------------------------------------------------

Re: EDE - Personal Suggestions and Ideas

[Andrey Romanenko]

David Given wrote:

>But if you're not programming in C, you don't have this limitation. Unix 
>traditionally is programmed in C, so people don't think about this much, but 
>it would be really nice if the kernel would manage all the segment registers 
>and not just CS and DS. So that, if you like, you could load a binary that 
>allocated all four segments. This would allow nice features such as a Basic 
>interpreter that stored its byte-code in ES, its working stack in SS, and 
>used DS for workspace.
>  
>
You propose to maintain two or more pointers that points to same memory 
location but to different areas that may cross over.
That means that if you have (pointer == pointer2) it is not enough to 
say that they are poining to the same object.
I think this situation is COMPLETE NIGHTMARE that gives us no value but 
only troubles.
Yes I understand that 8086 architecture alredy support it but this is 
not a reason to bring this to C compiler.
I belive C programmer does not need to know about all this 8086's 
xxxx:xxxx memory structure at all.
It is job of compiler to convert 32bit pointers to xxxx:xxxx addresses. 
So ideally there would be two types of executables: old
(that we have now) and new with multi segments where compiler using 
kernel manages all segments allocation and converts
32bit pointers to apropriate locations.

Andrey

Re: EDE - Personal Suggestions and Ideas

[David Given]

On Friday 28 May 2004 12:23, you wrote:
> David Given wrote:
> >But if you're not programming in C, you don't have this limitation. Unix
> >traditionally is programmed in C, so people don't think about this much,
> > but it would be really nice if the kernel would manage all the segment
> > registers and not just CS and DS. So that, if you like, you could load a
> > binary that allocated all four segments. This would allow nice features
> > such as a Basic interpreter that stored its byte-code in ES, its working
> > stack in SS, and used DS for workspace.
>
> You propose to maintain two or more pointers that points to same memory
> location but to different areas that may cross over.

No! Nonononono! Dear gods, that's horrible!

I'm assuming that segments *never* overlap. Ever. (Except for the special case 
where two segment registers refer to the same segment.)

Don't think about nasty, hacked up 8086 multisegment executables and far 
pointers. These are irrelevant. We do not want to support this, it's a pain.

Think instead of traditional Unix segments. The 8086 is a 16-bit processor, 
which means each process can address 64kB of memory. Full stop. We don't even 
want to *try* to make it address more, it's just too complicated. However... 
which 64kB is being accessed depends on what the processor is doing at the 
moment (accessing code, data, the stack, or 'other'). That's very easy to 
support and allows considerable flexibility later.

I'm not talking about binaries containing multiple code or data segments.

Currently, ELKS binaries (which are the same format as Minix binaries, 
although you can't run Minix binaries on ELKS) contain a header that 
contains, among other things, the size of the code segment and the size of 
the data segment. If we extend this with a couple of fields for the size of 
the stack segment and the size of the extended segment, with the proviso that 
0 means that they map onto the data segment, that's all we need.

So, if a process wants, it can allocate up to 256kB of memory. If it does, it 
needs to be specially written --- probably not in C --- but it can be done.

[...]
> I belive C programmer does not need to know about all this 8086's
> xxxx:xxxx memory structure at all.
> It is job of compiler to convert 32bit pointers to xxxx:xxxx addresses.

Except that in our case, pointers are always 16 bits. The compiler neither 
knows nor cares about segments. As far as it is concerned, it's using a flat, 
linear 16-bit address space with memory protection (even though on anything 
below a 286 there isn't any actual memory protection).

> So ideally there would be two types of executables: old
> (that we have now) and new with multi segments where compiler using
> kernel manages all segments allocation and converts
> 32bit pointers to apropriate locations.

I really don't want to support binaries containing multiple code and data 
segments. If needed, that can be implemented at a purely user level. But 
multisegment executables make life much, much harder.

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | "I have a mind like a steel trap. It's rusty and
| (dg@tao-group.com) | full of dead mice." --- Anonymous, on rasfc
+- www.cowlark.com --+ 

Re: EDE - Personal Suggestions and Ideas

[Dan Olson]

> Think instead of traditional Unix segments. The 8086 is a 16-bit processor,
> which means each process can address 64kB of memory. Full stop. We don't even
> want to *try* to make it address more, it's just too complicated. However...
> which 64kB is being accessed depends on what the processor is doing at the
> moment (accessing code, data, the stack, or 'other'). That's very easy to
> support and allows considerable flexibility later.

I agree 100%, I keep seeing what look like very complicated ways to allow
large processes to run under ELKS, while I can't claim to be an ELKS
programmer, I tend to think that we are better off just keeping things
simple and small.

> So, if a process wants, it can allocate up to 256kB of memory. If it does, it
> needs to be specially written --- probably not in C --- but it can be done.

That's a good sized chunk of memory, if you concider that the OS and other
background stuff will be using memory too, about have of the memory on a
640k machine will be used once this one large process is run.  This also
make it possible to allow C without special concideration, and without
giving up the multiple segment feature that the 8086 allows.

> Except that in our case, pointers are always 16 bits. The compiler neither
> knows nor cares about segments. As far as it is concerned, it's using a flat,
> linear 16-bit address space with memory protection (even though on anything
> below a 286 there isn't any actual memory protection).

Very true too, I think the best we can do it to just assume that the
memory is protected, as we can't stop someone who really wants to write a
program to modify another process's memory, or prevent misbehaved
programs.  If that's a feature that's needed, the 8086/8088 is a poor
choice (without a MMU).

	Dan