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: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[Gábor Lénárt]

Hello,

On Wed, May 26, 2004 at 01:43:03PM +0200, Mario Premke wrote:
> > Why? On 16 bit protected mode (80286) you CAN alter the starting
> > address of
> > a segment while refeering the same selector before and after this action
> > (this is because in protected mode the segment register only contains a
> > 'selector' which is an index in the descriptor table which describes the
> > segment). Sure, real mode does not allow this, because in real mode the
> > content of the segment register is simply the starting address of the
> > segment divided by 16, allowing maximum of 1Mb address space
> 
> Is it possible to use the the content of the segment register in real mode
> as a selector in protected mode - so assuming GDT and possibly LDT are
> properly set up, would a real mode program run in protected mode?

Ehhm, I see. Sorry I did not understand your point.

OK, now I see, but I haven't got the point. I mean, if you have a syscall or
whatever to allocate a memory as a separate segment, you would get a 16 bit
ID which can be load in the segment register. And this is NOTHING for a user
space application that this is real mode segment register contant (so real
address divided by 16) or a selector in pmode, user app should only load
this number into the segment register. In this way (if we don't allow a user
app to caculate segment register values only allow to get these values from
the OS) user space program does not need to now ANYTHING about the real
connection between the memory and the content of a segment register. It's up
to the kernel. If you do this right, a 8086 ELKS program should also run in
ELKS for 286-protected-mode. The only need - as I've described below - that
values used to load into segment registers are 'allocated', 'queried' etc
from the OS so there is no assumption about the "real meaning" of the value
used to load into segment registers. Sorry my English is not so good, but
maybe I was able to describe the theory of mine.

Using 286 pmode also gives some nice features. Like memory defragmentation.
I mean, allocating several memory blocks than freeing some may result in
having enough memory but not disallowing allocation of large memory block
because not enough continuous memory block. In 8086 (real) mode there is
nothing to do here, since we can't move memory blocks: we have already
give segments register values to user space programs which values have got
direct meaning for the starting address of the segment in real mode (OK
maybe some VERY ugly trick can be done: we provide a mechanism to send
signal or whatever to user space program to recalibrate all of its segment
allocations but this would be VERY VERY VERY ugly and complex and also
it's very far from the C and UNIX way, I think ...). But in 286 protected
mode, you can alter the starting address of the segment without chaning the
descriptor value which refeers the segment itself. The only need is a memory
defragmention kernel daemon or something similar which copies the memory
and then alter the descriptor table. Sure, some locking should be provided
to avoid to run of the process whose memory region is being moved.

- 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: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[David Given]

On Wednesday 26 May 2004 14:06, Gábor Lénárt wrote:
[...]
> In a nutshell: segments should be considered as read-only values after
> getting them from the system.

Absolutely.

Basically, there are two routes you can go.

* If you give your application access to segment IDs, then the kernel cannot 
change them directly (because it doesn't know where the application's put 
them). This means that on a 8086, your application is not relocatable, which 
means not swappable.

* If you *don't* give your application access to segment IDs, then it's 
restricted to single code and data segments only. But because the kernel 
knows where the segment IDs are stored --- CS, DS, SS --- then the kernel can 
change them whenever it likes and the application doesn't even know.

Advantages of the former: applications can be bigger. Disadvantages of the 
former: larger code. Slower code. Severe disadvantages on the 8086 
(basically, the system would be unusable). Less reliable; bad pointers run a 
higher risk of corrupting something.

Advantages of the latter: smaller and faster. Much simpler. Much cleaner 
design. More functionality on the small systems. Poor-man's memory 
protection, making it more reliable. Disadvantages of the latter: 
applications can't be as large.

I just don't think that the advantages of having multisegment programs 
outweigh the disadvantages. Anything that needs multiple segments should be 
restructured to run as multiple processes. Plus, I should point out that we 
don't have any compilers that support far pointers anyway...


PS. Please don't cc me! I'm subscribed to the mailing list! I don't need more 
copies of the messages!

-- 
+- David Given --McQ-+ "P.S. If you do not receive this, of course it
|  dg@cowlark.com    | must have been miscarried; therefore I beg you to
| (dg@tao-group.com) | write and let me know." --- Sir Boyle Roche, in a
+- www.cowlark.com --+ letter
-
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: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[Gábor Lénárt]

Re,

On Wed, May 26, 2004 at 03:17:47PM +0100, David Given wrote:
> On Wednesday 26 May 2004 14:06, Gábor Lénárt wrote:
> [...]
> > In a nutshell: segments should be considered as read-only values after
> > getting them from the system.
> 
> Absolutely.

Well, I've wanted to write 'segment IDs should be' not just 'segments'.

> Basically, there are two routes you can go.
> 
> * If you give your application access to segment IDs, then the kernel cannot 
> change them directly (because it doesn't know where the application's put 
> them). This means that on a 8086, your application is not relocatable, which 
> means not swappable.

Or you can introduce a VERY ugly scheme: you should specify a pointer to
a 16 bit value when calling segment allocation/query. At return, kernel
will fill out the pointed word. Now, user app SHOULD ALWAYS load segment
from that memory word, instead of just loading it eg ES and use it forever
while the process run. Sure, very ugly, and a hard-to-track dead lock could
occure because a context switching would occure between loading segment ID
and use it. And it's VERY ugly and VERY complex as you can see. However,
in my 286OS (which source was destroyed several years ago, when my sister
tries to drink my computer with some cola ...) there was a signaling
mechanism and the kernel can notify application that it SHOULD reload
segment IDs and this signal is unblockable one. Sure, still ugly, but at
least we haven't got reload segment IDs every time ;-)

> 
> * If you *don't* give your application access to segment IDs, then it's 
> restricted to single code and data segments only. But because the kernel 
> knows where the segment IDs are stored --- CS, DS, SS --- then the kernel can 
> change them whenever it likes and the application doesn't even know.
> 
> Advantages of the former: applications can be bigger. Disadvantages of the 
> former: larger code. Slower code. Severe disadvantages on the 8086 
> (basically, the system would be unusable). Less reliable; bad pointers run a 
> higher risk of corrupting something.
> 
> Advantages of the latter: smaller and faster. Much simpler. Much cleaner 
> design. More functionality on the small systems. Poor-man's memory 
> protection, making it more reliable. Disadvantages of the latter: 
> applications can't be as large.
> 
> I just don't think that the advantages of having multisegment programs 
> outweigh the disadvantages. Anything that needs multiple segments should be 
> restructured to run as multiple processes. Plus, I should point out that we 
> don't have any compilers that support far pointers anyway...

OK, but let's see this from the view point of assembly (because it's low
level language). Inmagine that the process itself uses only some kbytes of
code and some kbytes of data, but the purpose of the program requires fast
access - let's say - 128K of data. If our program refeers that 128K data
in random order and it's a huge calulcation, you can't say broke the program
into two processes in this case ... But you can assume that its assembly
programmer say: OK, CS (code segment register) points to code segment,
DS (data segment register) points to data segment *AND* ES (extra segment
register) points to the ACTUAL user data segment. At startup the program
allocates two 64K wide segment and so get two segment IDs.

This *STUPID* example:



; user_seg_1 and user_seg_2 stores two segment IDs which points
; to two allocated segments at startup of the process
	mov cx,CONSTANT
stupid:
	mov es,[user_seg_1]
	add al,es:[bx]
	mov es,[user_seg_2]
	add al,es:[bx+2]
	loop stupid

Because this programs SHOULD access more data than 64K and it changes
segments VERY fast, you have no chance to implement this as two processes
just for a rule that one process should not have got multiple data/code
segments.

I think - as my example shows - it's not a problem of the kernel itself.
Instead we have got problem with the C language that it assumes easy and linear
access of the memory eg via pointers. But as you can see, in assembly you
can write quite usefull programs which almost hides the disadvantages of
the 64K segment limit rule (sure its somewhat slower because of the ES
loadings and es: prefixes, but we've done it folks, at least).

So there is no major kernel problem with multiple segments. So let's do it.
It's ANOTHER question that writing a multiple segmented user space program
in C would be HARD, but it's not the problem of the kernel ... We have at
least give the possibility to be ABLE to do this in user space, of course
you mustn't use it anyway if you don't want it ;)

So my ONLY though with this long novel ;-) -> at least we should provide
the possibility for multi segment processes ... Sure, at startup process
shoulde REQUIRE kernel for multi segment mode. In this way there is no
slowdown or other resource bottleneck of this scheme if we don't want it.
But if we want it, kernel prepares eg the above described signaling
machanism and other stuffs I was talking about.

> PS. Please don't cc me! I'm subscribed to the mailing list! I don't need more 
> copies of the messages!

Hmm, sure, I've got similar thought as well at first, but I got the idea
that here everyone CCs everyone ;-) But you're right. Well, at least IMHO.

- 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: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[David Given]

On Wednesday 26 May 2004 16:10, Gábor Lénárt wrote:
> However,
> in my 286OS (which source was destroyed several years ago, when my sister
> tries to drink my computer with some cola ...) there was a signaling
> mechanism and the kernel can notify application that it SHOULD reload
> segment IDs and this signal is unblockable one. Sure, still ugly, but at
> least we haven't got reload segment IDs every time ;-)

The only issue with this is, what happens if it's the code or data segments 
that have changed... you can't execute any user code until the segments have 
been updated and you can't update segments without running user code!

[...]
> But you can assume that its
> assembly programmer say: OK, CS (code segment register) points to code
> segment, DS (data segment register) points to data segment *AND* ES (extra
> segment register) points to the ACTUAL user data segment.

Ha! Great minds think alike, and fools seldom differ... I was going to propose 
something like this. Except from C, and only allowing a single extra segment 
(so that the user process never concerns itself with the contents of ES). I 
was going to call it the buffer area and allow you to do things like:

{
	resize_buffer(32*1024); /* request 32kB buffer area */
	copy_from_buffer(data, 2*1024, 32); /* copy 32 bytes to data from 2kB
		into buffer area */
}

However, I didn't mention it because I had vague memories that part of ELKS' 
libc uses ES for some of its loops, and wanted to check on that.

But yeah, that would work. It might make a suitable compromise between 
single-segment code and multi-segment code.

If you want to use more than one extra segment, however, you end up with 
exactly the same problem as before --- the kernel doesn't know where the 
segment addresses are in the app's address space. Giving the kernel a pointer 
to where it's stored is really, really ugly.

Perhaps a better approach would be to have the kernel mediate all this; use 
syscalls to tell the kernel to allocate out-of-process memory. (Or, actually, 
a device driver would be better because then it would all get cleared up 
automatically when the process exits.)

{
	int handle1 = allocate_buffer(48*1024); /* request 48kB buffer area */
	int handle2 = allocate_buffer(48*1024); /* and another one */

	use_buffer(handle1); /* tell the kernel to look up what selector
		handle1 refers to and set it to ES */
	copy_from_buffer(data, 2*1024, 32);
	use_buffer(handle2);
	copy_to_buffer(3*1024, data, 32);
}

You'd get fast copying from a buffer to normal data and vice versa, but not 
from one buffer to another buffer (unless you were to implement another 
syscall so the kernel did it).

Ideally you don't want your user process playing with the segment registers. 
Ever. That way lies madness, and horrible bugs when, e.g., the compiler 
decides to cache a selector on the stack without telling you, and the kernel 
changes the selector without updating the version on the stack...

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | Wholesale theft is the sincerest form of flattery.
| (dg@tao-group.com) | 
+- 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: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[Andrey Romanenko]

Hi David,

David Given wrote:

>The only issue with this is, what happens if it's the code or data segments 
>that have changed... you can't execute any user code until the segments have 
>been updated and you can't update segments without running user code!
>  
>
that is the result of breaking general rule - do not allow user-mode 
processes to manage kernel tasks :)

>{
>	resize_buffer(32*1024); /* request 32kB buffer area */
>	copy_from_buffer(data, 2*1024, 32); /* copy 32 bytes to data from 2kB
>		into buffer area */
>}
>  
>
by this code you just change one user-mode process memory manamgent by 
athother one - same mistake.

>If you want to use more than one extra segment, however, you end up with 
>exactly the same problem as before --- the kernel doesn't know where the 
>segment addresses are in the app's address space. Giving the kernel a pointer 
>to where it's stored is really, really ugly.
>  
>
WHY??? almost the same situation happens on the real hardware with 386 
cpu - difference only that kernel does have another way to acomplish 
this task (by changing apropriate tables in own memory space); I 
consider this situation almost equal - we just update locations pointed 
by process itself insted of those defined by 386cpu architecture. And at 
the end of the story I see C++ compiler that supports ONLY 32bit 
pointers and make translation of 32bit-virtual addresses to 8086's 
xxxx:xxxx - format addresses absolutely invisible for programmer of 
multi-segment exe module.

>Perhaps a better approach would be to have the kernel mediate all this; use 
>syscalls to tell the kernel to allocate out-of-process memory.
>
seems :) you very like the idea to give task of memory managment to 
user-mode process, isn't it?

thanks,

Andrey

Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

[David Given]

Andrey Romanenko wrote:
[...]
> by this code you just change one user-mode process memory manamgent by 
> athother one - same mistake.

Ah, no. All this code is doing is accessing memory with ES. Actually 
setting up ES is strictly the job of the kernel. The user code doesn't 
know what's in ES, doesn't care, shouldn't even be looking.

[...]
>> Perhaps a better approach would be to have the kernel mediate all 
>> this; use syscalls to tell the kernel to allocate out-of-process memory.
>>
> seems :) you very like the idea to give task of memory managment to 
> user-mode process, isn't it?

Uh, no. The exact opposite. People have said that the 64kB RAM limit of 
a process is too small; I'm trying to come up with a technique of 
quickly accessing more than 64kB of memory *without* resorting to the 
big, slow, insecure, dangerous and ugly technique of far pointers and 
multisegment executables.

What I'm suggesting is a compromise that will allow us to keep the 
16-bit pointers and clean design of the existing system, and also allow 
us to quickly access another 64kB of memory that's outside the process' 
own address space.

Yes, the same effect could be performed using temporary files. But 
temporary files are *really slow*. In order to copy data out of a 
temporary file, you have to actually wait for the disk to move. Copying 
out of ES can be done in about four instructions.

Frankly, I'd rather do without it completely --- I'm sure you're all 
sick of hearing me say that an application that needs more than 64kB of 
RAM is too big on ELKS. But this would give the option of fast access to 
another 64kB in a clean way that doesn't break the existing design --- 
should anyone want it...

-- 
[insert interesting .sig here]

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

[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

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