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

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

[Miguel Bolanos]

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



[-- Attachment #2: Forwarded message - Re: EDE - Personal Suggestions and Ideas --]
[-- Type: message/rfc822, Size: 3667 bytes --]

From: "Jody" <jbruchon@nc.rr.com>
To: "Miguel Bolanos" <mike@linuxlabs.com>
Subject: Re: EDE - Personal Suggestions and Ideas
Date: Tue, 25 May 2004 10:18:37 -0400
Message-ID: <016001c44263$2bd82e80$0101a8c0@vash>

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

I found an 8-bit "Etherlink II TP" at my storage unit, and I assume the
drivers in Linux can be used to model drivers for ELKS in some way.  (?)

> - swap support

Without protected mode that could get sticky.  How can it be done cleanly
and in a stable manner?

> - maybe ext2fs support.

Perhaps, but will ext2 perform as well as a simpler filesystem on these old
old machines?

> Then get EDE to have the following features:
>
> - Capable of been installed on a hard disk ( i know, done)
> - Boot loader

The Bootkit in EDE is binary-only and I don't think we should be sticking
with a binary-only program, so unless we can have the sources to bootkit
somehow, I say we mark these two related components as UNDONE.  How can you
install ELKS to a hard disk without a boot loader?

> - Maybe implement something like bootsplash or Linux Progress Patch
> - X support.. perhaps Microwindows can be the solution?
> - An internet browser

Anyone want to strip down Lynx?

> - a Gui mail client

Not necessarily GUI-based.

> - maybe an irc client

Why MAYBE?  IRC is important :P

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

ELKS will most likely continue to fit in embedded systems, because we're
working on a small scale here.

> Anyways this is just my personal little idea - project, hopefully others
> will share my vision.
>
> Comments, suggestions, improvements.. are very welcome :)
> best wishes
>
> Mike

What about sound support?  If I have an 8-bit sound card (original Sound
Blaster?) then I'm gonna want to hear noises!

I suggest we start doing what ReactOS did.  We should stop talking about it
and DO it.  Focus on results rather than planning.

Someone offer to help me learn C.

Jody

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

[David Given]

On Tuesday 25 May 2004 15:23, Miguel Bolanos wrote:
[...]
> > - swap support
> 
> Without protected mode that could get sticky.  How can it be done cleanly
> and in a stable manner?

There's a difference between paging and swapping.

Paging is when you use the page-level MMU to copy individual pages to and from 
disk on an on-demand basis. The application tries to access a page that has 
no mapping to physical memory; an exception is raised; the kernel allocates a 
page, reads it from disk, updates the virtual mapping, and the application 
continues.

Swapping is when you read and write the entire application's address space 
when the application get scheduled or descheduled. The application is waiting 
for I/O; the kernel writes its data to disk and frees its memory; the I/O 
becomes available; the kernel reads the data back in again, updates the 
application's segment registers, and the application continues.

Paging can only be done with a page-level MMU, which only the 386 and above 
had.

Swapping can be done on any segmented processor, even the 8086.

Swapping is slower, because you've got to read and write more memory, but 
given the maximum size of a segment on ELKS is 64kB and each process can have 
a maximum of two segments, you end up having to read a maximum of 128kB per 
process. Which is not a lot. If you can swap to a ramdisk of some description 
--- EMS cards are ideal for this --- the delay is negligable.

One interesting feature: remember that code is read-only. You don't need to 
swap out an applications' text segment, it won't change. Just throw it away; 
you can always reload it from the original binary when you need it...

[...]
> > - maybe ext2fs support.
> 
> Perhaps, but will ext2 perform as well as a simpler filesystem on these old
> old machines?

Nah. You may as well stick to the Minix filesystem. It's much, much simpler, 
and the performance benefits of ext2 don't really apply on machines that 
small.

[...]
> > - A little "office" suite

Forget GUI and WYSIWYG packages; too big and complicated. If you want a 
kick-ass office suite done the Unix way, look into using troff for 
typesetting. Weird, yes, but deceptively powerful and it runs on tiny 
systems.

(Don't believe me? On my Debian system:

	zcat /usr/share/man/man1/gcc.1.gz | groff -man -Tps > out.ps

...will typeset a 110-page book. groff is big and chunky, but there are much 
smaller implementations available, such as the one on Minix.)

For spreadsheets, look into sc. It's a character-cell spreadsheet that's 
portable to practically everything.

For a database, use sc, or else use text files. You'd be amazed what you can 
do with a few lines of awk.

You're not *going* to make an 8086 work the same way as a modern desktop. 
There's just not enough room for a program that's a text entry application 
*and* a typesetting application *and* a graphical preview application *and* a 
file manager *and* a programming language, etc. Instead, divide and conquer. 
Your text entry application is vi or uemacs. Your typesetting application is 
troff. Your graphical preview application is ditview. Your file manager is 
the shell. Your programming language is awk. Each tool is small enough to run 
on a small system, and simple enough that it will run *well* on a small 
system.

[...]
> Someone offer to help me learn C.

The best way to learn is to do something. Kernel hacking's not a good place to 
start; it's too hard to debug, and there are too many knock-on effects (you 
run the risk of accidentally breaking things without realising it).

Applications would probably be a good place to start. What tools do you want 
on ELKS? Anything there you'd want to try and write?

-- 
+- David Given --McQ-+ "I love the way Microsoft follows standards. In
|  dg@cowlark.com    | much the same manner that fish follow migrating
| (dg@tao-group.com) | caribou." --- Paul Tomblin
+- 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

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

[Mario Premke]

> Swapping is slower, because you've got to read and write more memory, but
> given the maximum size of a segment on ELKS is 64kB and each
> process can have
> a maximum of two segments, you end up having to read a maximum of
> 128kB per
> process. Which is not a lot. If you can swap to a ramdisk of some

What about supporting 286 protected mode in a manner that more than one
text+data segment per program are possible - still far-pointers were to be
implmented, but would segment switching not be easier with HW-protection (in
comparison to 8086)?  I am not familiar with  compiler programming, so I
have no idea of how much work it would be.
The last time I looked into the elks sources there was code for initializing
286 protected mode - don't know if it works.

Mario

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

[David Given]

On Wednesday 26 May 2004 07:20, you wrote:
[...]
> What about supporting 286 protected mode in a manner that more than one
> text+data segment per program are possible - still far-pointers were to be
> implmented, but would segment switching not be easier with HW-protection
> (in comparison to 8086)?  I am not familiar with  compiler programming, so
> I have no idea of how much work it would be.
> The last time I looked into the elks sources there was code for
> initializing 286 protected mode - don't know if it works.

The problem with using far pointers is that you end up having to encode 
segment IDs into the pointers themselves, which makes things really painful. 
Particularly, on systems that don't have an MMU, the segment ID controls the 
address of the segment; so on the 8086 and 8088 you won't be able to move 
your application's segments around while the program's running.

(Brief tutorial on segments: the 8086, 8088 and 80286 are *not* 32-bit 
processors. They are 16-bit processors. They can address a total of 64kB of 
memory. However, they have a feature where you can select which 64kB of 
memory you want to use out of a much larger memory region. Each area is 
called a segment, and is referred to by segment ID. The processor can use 
different segments for accessing code, data and stack, so you can put your 
code in a different 64kB area than your data. The 8086 and 8088 have a 
hard-coded MMU where all segments are 64kB long and the physical address of 
each segment is (segmentID * 16); physical memory is 1MB wide. The 286 and 
above have a programmable MMU where you can vary the length and physical 
address of any segment at run time, and physical memory is 16MB wide.)

Also, far pointers are slow and cause bloated and annoying code. One of the 
problems is that now your pointers are 32 bits wide, but your integers are 16 
--- and while this shouldn't affect well-written code, there's a lot of 
badly-written code out there.

I'm of the opinion that a program that won't fit in a 64/64 address space is 
too big to run well on an 8086-class system, anyway.

(Incidentally, I dug out of storage an old laptop of mine: a 386SX/16 with one 
whole megabyte of memory. I installed Minix on it, telling Minix that it was 
a 286, and it runs fine! Recompiled the kernel and everything! It's a bit 
slow, but I wasn't really expecting otherwise.)

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | "Two of my imaginary friends reproduced once ...
| (dg@tao-group.com) | with negative results." --- Ben, from a.s.r
+- www.cowlark.com --+ 

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

[Gábor Lénárt]

On Wed, May 26, 2004 at 11:09:41AM +0100, David Given wrote:
> On Wednesday 26 May 2004 07:20, you wrote:
> [...]
> > What about supporting 286 protected mode in a manner that more than one
> > text+data segment per program are possible - still far-pointers were to be
> > implmented, but would segment switching not be easier with HW-protection
> > (in comparison to 8086)?  I am not familiar with  compiler programming, so
> > I have no idea of how much work it would be.
> > The last time I looked into the elks sources there was code for
> > initializing 286 protected mode - don't know if it works.
> 
> The problem with using far pointers is that you end up having to encode 
> segment IDs into the pointers themselves, which makes things really painful. 
> Particularly, on systems that don't have an MMU, the segment ID controls the 
> address of the segment; so on the 8086 and 8088 you won't be able to move 
> your application's segments around while the program's running.

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 (1Mb+64K-16byte
if you set segment register to 0xFFFF, but on XT this simply warps arount
the the start of the memory, while on AT this is called HMA, and for
avoiding warping around se so called A20 line enabling was needed, etc, but
it's out of scope here I think).

> (Brief tutorial on segments: the 8086, 8088 and 80286 are *not* 32-bit 
> processors. They are 16-bit processors. They can address a total of 64kB of 
> memory. However, they have a feature where you can select which 64kB of 
> memory you want to use out of a much larger memory region. Each area is 

Yep, exactly. Intel's first 32 bit CPU was the 386.
8086 and 80286 is only address maximum 64K at 'once' (sure not including
the fact that you can use different segment for data, code and stack,
also an extra segment register (ES) was introduced), but 286 does not have
got 32 bit instructions and registers as well. Yes, they're 16 bit CPUs.

> Also, far pointers are slow and cause bloated and annoying code. One of the 
> problems is that now your pointers are 32 bits wide, but your integers are 16 
> --- and while this shouldn't affect well-written code, there's a lot of 
> badly-written code out there.

Yep, but if you don't want to buy +386 system, and you wanna to provide
the possibility to run a Linux-like OS on 8086 and 286 you should deal with
them ...

- 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

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

[Mario Premke]

> > Particularly, on systems that don't have an MMU, the segment ID
> controls the
> > address of the segment; so on the 8086 and 8088 you won't be
> able to move
> > your application's segments around while the program's running.
>
> 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?

>
> Yep, but if you don't want to buy +386 system, and you wanna to provide
> the possibility to run a Linux-like OS on 8086 and 286 you should
> deal with
> them ...
>
Yes, that's what I meant, because these CPU's are very limited, every
possible feature should be supported.

Mario

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

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

[Mario Premke]

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

Don't excuse, there might not be much point in my writing ... ;-)

> 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

If a stupid real mode program can't recognize being run in pmode it could be
possible to develop 286-pmode for ELKS without changing the rest of the
system (user space programs) in the first place (anyway there are only 64k
data + 64k text programs currently)

When it comes to far pointers you must use a selector which number
correspondens to the segment adress of the far pointer in the real mode
program independly of the actual memory position the descriptor points to -
if I get it right ...

Mario

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

[Gábor Lénárt]

On Wed, May 26, 2004 at 02:39:44PM +0200, Mario Premke wrote:
> > 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
> 
> If a stupid real mode program can't recognize being run in pmode it could be

No, it's not stupidity at all, I think it should be a RULE, not to depend on
the 'subarchitecture' (8086_real vs 80286_pmode) at all! Because it allows
an ELKS/8086 sw can run on ELKS/286_mode system, I mean binary
compatibility. Of course it may be wrong for kernel API compatibility (where
eg in memory layer there are big differences), but it's another issue.

> possible to develop 286-pmode for ELKS without changing the rest of the
> system (user space programs) in the first place (anyway there are only 64k
> data + 64k text programs currently)

Exactly. Sure, the system initalization (switching into protected mode), the
pmode dependent architecture (exception handlers, descriptor table
management, memory layer etc) should be different, but otherwise in case of
GOOD design the other parts of the system (and the user space) even needn't
know about the fact that this is ELKS protected mode or ELKS real mode ...

> When it comes to far pointers you must use a selector which number
> correspondens to the segment adress of the far pointer in the real mode

Since "far pointers" are consists of a "selector" and an "offset" part and
"selector" part is ALWAYS requested/queried/etc by the system (which is
a smaller part of the kernel which actually KNOWS about pmode/real mode
difference of course) the requestor needn't know about the details on this
topic, period. I mean something similar (only pseudo syntax though!!):

far char *p=sys_far_malloc(4096);

Where far_malloc() should some syscall or whatever to the system which 
allocates 4096 bytes long segment SOMEWHERE. The returned far pointer
is a 4 byte value in type:  a word descibing the segment, and a word
describing the offset (probably zero here). Then you can refeer the
memory, like:

*(p+2)=1;

This should set byte at SEG:(OFS+2) where SEG and OFS are values originated
by the memory layer when far_sys_malloc() was called. So the trick is memory
layer knows about the REAL meaning of "SEG", but our application shouldn't,
it should only blindly trust in this value, and not assume that it means
anything (like the phys_address/16 at 8086).

Attention! *(p+4096)=1 in ELKS/pmode would trigger a memory protection
exception (over the size of the segment) while in ELKS/8086 it simply
overwrites something which shouldn't be overwritten, but we haven't got
better idea, since there is no hw level protection and we want to allow
to use smaller segments than 64K as well ...

In a nutshell: segments should be considered as read-only values after
getting them from the system.

> program independly of the actual memory position the descriptor points to -
> if I get it right ...

Right. Do you have any problem with this theory or it was only a summary of
my brainstorming written in bad English? ;-)

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

[Andrey Romanenko]

Hi there,

Gábor Lénárt wrote:

>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.
>  
>
I think all this "novel" sounds very resonable. We have vast of sources 
on the NET written with this 64kb segments in mind (yes those old 
sources still may be very useful for ELKS -GEM,libraries and so on.); 
Besides, there is FreeDOS project full of usable for our situation 
goodies. From the other hand we have MINIX and UZIX utilities sources 
that small enough to be compiled as 2 segment executables - so we need 
to keep existing executable schema. Eventually, guys look at OLD DOS - 
this operating system started with COM files and than moved forward to 
all those exotic mamory models available - that seems absolutely natural 
way.

I've got also question about proposed solution for segment base address 
changing by SIGNALs. Is there another way of managing this? Lets say 
user process upon memory allocation forced to "register" all places 
where it plan to keep 16bit segment address (CPU registers or memory 
locations) and kernel changes all those values upon process context 
loading according to current situation. It seems to me that all system 
related tasks should be performed by kernel but not by user process (the 
memory managment such a task).

thanks,

Andrey


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

[Eduardo Pereira Habkost]

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

On Wed, May 26, 2004 at 05:49:42PM +0100, David Given wrote:
> 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!

Erm... shouldn't be this exactly the task of the scheduler? Simply the
scheduler should be sure that the segment registers are updated and
data is in the right place before switching to user code again. Before
returning to the user process, the structure storing the 'context' will
be updated before returning to user context. I think I didn't get what
is the point.

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

I was thinking on this, too: things will be simpler if we explicitly
state that user processes cannot touch the segment registers.

The compiler be aware of that, too. But given that we have only one
data segment, one code segment, and maybe one ES segment pointing to
out of process data, the compiler shouldn't need to touch the segment
registers, ever.

We could have, instead of a "copy_{to,from}_buffer", a "map_buffer_to_es",
that will make sure that the ES register for the process point to the
selected buffer (reading your example again, I saw that this is exactly
what your use_buffer() is supposed to do), but the way C sees the memory
don't make this so simple. Unless the compiler give us some help to
easily accessing data in the ES segment.

If someday the compiler is supposed to support 'far' pointers, we could
use them, but instead of storing the ES value on the pointer, and updating
ES before accessing data, store the buffer handle on the pointer and call
use_buffer() before using it. Yes, more expensive than simply setting
the ES register, but would allow the OS to move the data, if needed.

And that would be compatible with 286pmode, too. The difference is that
on 286, we would need fewer copy operations, and fewer segment register
changing. And if we want to have 286pmode-only, but slightly faster,
applications, we can allow them to simply set ES to the returned handle,
without a syscall. Obviously the returned handle, in this case, will be
a segment identifier that can be directly put on a segment register.

--
Eduardo

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

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

[Gábor Lénárt]

Re,

On Wed, May 26, 2004 at 02:19:54PM -0300, Eduardo Pereira Habkost 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!
> 
> Erm... shouldn't be this exactly the task of the scheduler? Simply the
> scheduler should be sure that the segment registers are updated and

Yes, but what's up if a user space program stores a 'far pointer' in the
memory? scheduler changes content of the segment registers, but scheduler
will NOT know that the user space programs use eg an array of far pointers
which should be altered as well etc ... The only way to workaround this
problem is let the process to do it if it want to use multi segment model
anyway though it's know to be ugly, sure :) But if it REALLY wants ? ;-)

> data is in the right place before switching to user code again. Before
> returning to the user process, the structure storing the 'context' will
> be updated before returning to user context. I think I didn't get what
> is the point.

Yes, I see, so the situation here is not the content of segment registers
but other registers and memory locations stores segment IDs by the user
space process itself perhaps as the part of far pointers or such ...

> I was thinking on this, too: things will be simpler if we explicitly
> state that user processes cannot touch the segment registers.

Sure you're right. But I think we should not reject to write multisegment
apps. To keep kernel simple, we can let the large amount of the complexity
to the user space, so we can say: "hey, if you really wanna do this mess
multisegment madness, you should write app with segidchange sighandlers
etc. so you have been warned but you CAN do it if you REALLY need this
stuff".
 
[...]
> If someday the compiler is supposed to support 'far' pointers, we could
> use them, but instead of storing the ES value on the pointer, and updating
> ES before accessing data, store the buffer handle on the pointer and call
> use_buffer() before using it. Yes, more expensive than simply setting
> the ES register, but would allow the OS to move the data, if needed.
> 
> And that would be compatible with 286pmode, too. The difference is that
> on 286, we would need fewer copy operations, and fewer segment register
> changing. And if we want to have 286pmode-only, but slightly faster,

In 286 pmode even a multi segment process is relocatable, since kernel
can change the base address of the segment without changing the segment
IDs (called selectors in pmode), which is NOT true for real mode (and
this is the exact reason of my signal notification theory: to allow kernel
to reallocate a segment of a multi segment mode user space program while
running, so allow to defragment memory which can be done ie a kernel thread
or something similar which runs on IDLE or at out-of-enough-continous memory
situations).

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

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

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

[Harry Kalogirou]

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

You can do that right now... add a ramdrive and create tempfiles on it.

-- 
Harry Kalogirou <harkal@gmx.net>

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

[Gábor Lénárt]

Re,

On Wed, May 26, 2004 at 05:49:42PM +0100, David Given wrote:
> > 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!

Good point :) Maybe user space program should assume that the signal
handler SHOULD BE PLACED in the first code segment and it should use
the first data segment, and before kernel give control to this 'special'
signal handler, CS, SS and DS is aligned to meet this requirement. Or
something similar. Well ... 

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

Hmm, yes, but keep in mind, that there is not only C in the world, someone
may write application in assembly for ELKS or whatever ...
 
[...]
> 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...

Well, you're talking about the C implementation of a user space program
which uses multi segment memory model. However we can even think that
it's up to the user space ... Maybe only SOME program will use this, maybe
programs aren't written in C at all. And so on. So I think it's out of the
scope now, only the kernel infrastructure should be provided to be able
to write such a program at once ... The only point to open threads on this
topic is the idea, that kernel should be flexible enough to implement
this scheme as well easily.

And IMHO you can't blame ELKS because of some compiler bugs you've
mentioned. An operating system which runs on an architecture without 
hw level protection there is no way to protect itself for all of the
possible bugs, so it's up to the compiler bugs as well. However eg in
286 pmode the situation can change. Maybe you should develope in 286 pmode
and test the system, because there is hw protection there which will trigger
exceptions on protection faults. Because of the unique handle of segment IDs
(user space programs should not assume anything about the meaning of segment
IDs) there should be NO difference between running on 286pmode or 8086 real
mode ELKS kernel, but in case of 286 pmode you can use hw protection and
maybe other debugging features as well to test 'bug-ness' of the application
so it does not crash the system on ELKS 8086 either ...

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

[Dan Olson]

> Yep, but if you don't want to buy +386 system, and you wanna to provide
> the possibility to run a Linux-like OS on 8086 and 286 you should deal with
> them ...

Just a thought, maybe if using the 286's features is something we want to
do, then why not look into Xenix and any other Unix of the era that runs
on the 286 and see if any ideas can be gotten from them.  I'm sure we're
re-inventing the wheel to some extent.

	Dan

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

[Andrey Romanenko]

Dan Olson wrote:

>Just a thought, maybe if using the 286's features is something we want to
>do, then why not look into Xenix and any other Unix of the era that runs
>on the 286 and see if any ideas can be gotten from them.  I'm sure we're
>re-inventing the wheel to some extent.
>  
>
You are talking about copyrighted software with closed sources. The 
total maximum we can found is a binary disribution.

Andrey

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

[David Given]

On Thursday 27 May 2004 08:14, Andrey Romanenko wrote:
> Dan Olson wrote:
> >Just a thought, maybe if using the 286's features is something we want to
> >do, then why not look into Xenix and any other Unix of the era that runs
> >on the 286 and see if any ideas can be gotten from them.  I'm sure we're
> >re-inventing the wheel to some extent.
>
> You are talking about copyrighted software with closed sources. The
> total maximum we can found is a binary disribution.

You could look at Minix instead; it's open source and handles 286 protected 
mode. It uses the 286's MMU to put segments anywhere in memory while keeping 
binary compatibility with the 8086; basically, you just run Minix on the 286 
and you can use up to 16MB of RAM where on the 8086 you can use up to 640kB. 
It's completely invisible and works very nicely.

-- 
+- David Given --McQ-+ "For is it not written, wheresoever two or three
|  dg@cowlark.com    | are gathered together, yea they will perform the
| (dg@tao-group.com) | Parrot Sketch?" --- _Not The 9 o'Clock News_
+- www.cowlark.com --+ 

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

[Gábor Lénárt]

On Thu, May 27, 2004 at 10:32:19AM +0100, David Given wrote:
> > You are talking about copyrighted software with closed sources. The
> > total maximum we can found is a binary disribution.
> 
> You could look at Minix instead; it's open source and handles 286 protected 
> mode. It uses the 286's MMU to put segments anywhere in memory while keeping 
> binary compatibility with the 8086; basically, you just run Minix on the 286 
> and you can use up to 16MB of RAM where on the 8086 you can use up to 640kB. 

Or more, since you have got virtual memory, I mean you may have segments
which are not exists in the physical RAM. So with hw supported 'swapping'
(but on segment basis not on page like in case of 386 it can be done)
you can use even memory memory.

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

[Tommy McCabe]

--- David Given <dg@cowlark.com> wrote:
> On Thursday 27 May 2004 08:14, Andrey Romanenko
> wrote:
> > Dan Olson wrote:
> > >Just a thought, maybe if using the 286's features
> is something we want to
> > >do, then why not look into Xenix and any other
> Unix of the era that runs
> > >on the 286 and see if any ideas can be gotten
> from them.  I'm sure we're
> > >re-inventing the wheel to some extent.
> >
> > You are talking about copyrighted software with
> closed sources. The
> > total maximum we can found is a binary
> disribution.
> 
> You could look at Minix instead; it's open source
> and handles 286 protected 
> mode. It uses the 286's MMU to put segments anywhere
> in memory while keeping 
> binary compatibility with the 8086; basically, you
> just run Minix on the 286 
> and you can use up to 16MB of RAM where on the 8086
> you can use up to 640kB. 
> It's completely invisible and works very nicely.

Last time I checked, Minix 2.0.x didn't use 286
protected mode- it had an edition for 386s+ and an
edition for 8086s/286s. 286 protected mode isn't
binarily comptible with real mode or 386 protected
mode- at the very least, the memory handling work
differently. However, there are various tricks to
access over 640KB in real mode, like XMS and EMS.

> -- 
> +- David Given --McQ-+ "For is it not written,
> wheresoever two or three
> |  dg@cowlark.com    | are gathered together, yea
> they will perform the
> | (dg@tao-group.com) | Parrot Sketch?" --- _Not The
> 9 o'Clock News_
> +- 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



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

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

[Gábor Lénárt]

On Thu, May 27, 2004 at 02:07:42PM -0700, Tommy McCabe wrote:
> Last time I checked, Minix 2.0.x didn't use 286
> protected mode- it had an edition for 386s+ and an
> edition for 8086s/286s. 286 protected mode isn't
> binarily comptible with real mode or 386 protected
> mode- at the very least, the memory handling work
> differently. However, there are various tricks to
> access over 640KB in real mode, like XMS and EMS.

XMS is not for accessing over 640K in real mode. First, it's over 1Mb
instead (strictly speaking it's FFFF:FFFF which is almost 1Mb+64K is
A20 is enabled, and it's called HMA), second XMS functions are mainly
limited to copy operations between >1Mb areas and/or <1Mb areas which
is done by switching into protected mode (so disable all interrupts etc)
to gain full 16Mb address space access on 286 for example, do the copy,
and then switch back to real mode. So it's not ideal at all ;-)

EMS is another thing, it's a scheme where you can access a "window" of
the >1Mb space below 1Mb, but it can be only done if:

* it's a 386+ system and the CPU is not in real mode but in virtual 8086
  mode

- OR -

* the hardware has got direct support for EMS paging like some old
  NEC 286 motherboard did (if I remember correctly)


As you can see, on 286 the only GOOD solution is to use protected mode
(or special hardware).

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

[Gabucino]

Tommy McCabe wrote:
> Last time I checked, Minix 2.0.x didn't use 286 protected mode-
It does, and the "latest" releases even support enabling a disk slice ("b" by
default) as virtual memory (swap) - even on a 8086.

-- 
Bérczi Gábor
/Gabucino/
-
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][OT]

[Javier Sedano]

Hi,

Gabucino wrote:
> Tommy McCabe wrote:
> 
>>Last time I checked, Minix 2.0.x didn't use 286 protected mode-
> 
> It does, and the "latest" releases even support enabling a disk slice ("b" by
> default) as virtual memory (swap) - even on a 8086.
> 

	Really? As far as the minix web pages and c.o.minix say, 2.0.3 and 
2.0.4 do not run on 8086/640k. It seems they're pushing to make 2.0.5 
runnable on 8086 again, and keeping swap support, but I think it is not 
included in 2.0.3 and 2.0.4.

-- 
Javier Sedano Jarillo: javier.sedano@agora-2000.com
                        (http://www.it.uc3m.es/~jsedano)
Agora Systems, S.A.
C/Aravaca 12
E-28040 Madrid (Spain)
Tel.: +34 91 533 58 57
Fax.: +34 91 534 84 77
--------
Disculpen si les llamo caballeros, pero es que todavía no les conozco 
bien (Groucho Marx)

-
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

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

[Mario Premke]

> The problem with using far pointers is that you end up having to encode
> segment IDs into the pointers themselves, which makes things
> really painful.
> Particularly, on systems that don't have an MMU, the segment ID
> controls the
> address of the segment; so on the 8086 and 8088 you won't be able to move
> your application's segments around while the program's running.
>
> (Brief tutorial on segments: the 8086, 8088 and 80286 are *not* 32-bit
> processors. They are 16-bit processors. They can address a total
> of 64kB of
> memory. However, they have a feature where you can select which 64kB of
> memory you want to use out of a much larger memory region. Each area is
> called a segment, and is referred to by segment ID. The processor can use
> different segments for accessing code, data and stack, so you can
> put your
> code in a different 64kB area than your data. The 8086 and 8088 have a
> hard-coded MMU where all segments are 64kB long and the physical
> address of
> each segment is (segmentID * 16); physical memory is 1MB wide.
> The 286 and
> above have a programmable MMU where you can vary the length and physical
> address of any segment at run time, and physical memory is 16MB wide.)

AFAIK the difference of a 286 and 8086 is that in x86 real mode the 'segment
ID' is part of a real hardware address whereas the 286 has memory protection
in protested mode and is able to hold a 64kB local descriptor table for each
process which holds the segment ID's in memory ... as far as I remember each
desriptor being 8 bytes long this results in 8192 adressable segments per
process ?!?

>
> Also, far pointers are slow and cause bloated and annoying code.
> One of the
> problems is that now your pointers are 32 bits wide, but your
> integers are 16
> --- and while this shouldn't affect well-written code, there's a lot of
> badly-written code out there.
>
> I'm of the opinion that a program that won't fit in a 64/64
> address space is
> too big to run well on an 8086-class system, anyway.
>
> (Incidentally, I dug out of storage an old laptop of mine: a
> 386SX/16 with one
> whole megabyte of memory. I installed Minix on it, telling Minix
> that it was
> a 286, and it runs fine! Recompiled the kernel and everything! It's a bit

I did the same on my 286 w. 5Mb Ram - I expected the Minix kernel
compilation to endure a while, but it finished (successful) after only ~15
min.

I only wanted to state that coding a 16bit OS and leaving out multiple
segments for code and data especially on a 286 with MMU and protection
capabilities would give away some (good) features. On the other hand more
than 64kB text and 64kB data might be rarely needed ...

Mario

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

[Gábor Lénárt]

Re,

On Wed, May 26, 2004 at 01:34:36PM +0200, Mario Premke wrote:
> > The problem with using far pointers is that you end up having to encode
> > segment IDs into the pointers themselves, which makes things
> > really painful.
> > Particularly, on systems that don't have an MMU, the segment ID
> > controls the
> > address of the segment; so on the 8086 and 8088 you won't be able to move
> > your application's segments around while the program's running.

Yes, unless you provide a mechanism which notifies a process that it
SHOULD (must) "recalibrate" all of its far pointers or anything which
uses segment numbers as well. I've described it in my last mail.
However it would be really ugly and UNIX-alien technology ;-)

> > each segment is (segmentID * 16); physical memory is 1MB wide.
> > The 286 and
> > above have a programmable MMU where you can vary the length and physical
> > address of any segment at run time, and physical memory is 16MB wide.)
> 
> AFAIK the difference of a 286 and 8086 is that in x86 real mode the 'segment
> ID' is part of a real hardware address whereas the 286 has memory protection
> in protested mode and is able to hold a 64kB local descriptor table for each
> process which holds the segment ID's in memory ... as far as I remember each
> desriptor being 8 bytes long this results in 8192 adressable segments per
> process ?!?

Yes, something similar, I haven't work with this for ages either :)


> > Also, far pointers are slow and cause bloated and annoying code.
> > One of the
> > problems is that now your pointers are 32 bits wide, but your
> > integers are 16
> > --- and while this shouldn't affect well-written code, there's a lot of
> > badly-written code out there.
> >
> > I'm of the opinion that a program that won't fit in a 64/64
> > address space is
> > too big to run well on an 8086-class system, anyway.

Hmmm, maybe a process can require a memory model at starting up.
Or we can allow to allocate multiple segments. But a process could allocate
only one. Or whatever. So now it's up the application to use a single
code and a single data&stack (for example) segment (with a given limit of
course, it can allocate less memory than 64K as well of course) or it
can allocat multiple segments even for only code, it's up the process.
The kernel side is not too different since only some mapping is needed
to know the memory allocation table of a process and so on.
Someone may want to write a multi segment application in assembler without
the knowledge of C 'pointer' and 'far pointer' problem, only knowing
assembly, and (s)he will be happy with the situation without any fear of
C pointer questions ;-) Yes, I remember when I write a lot in x86 assembly.

> I did the same on my 286 w. 5Mb Ram - I expected the Minix kernel
> compilation to endure a while, but it finished (successful) after only ~15
> min.
> 
> I only wanted to state that coding a 16bit OS and leaving out multiple
> segments for code and data especially on a 286 with MMU and protection
> capabilities would give away some (good) features. On the other hand more
> than 64kB text and 64kB data might be rarely needed ...

Maybe. Maybe not ;-)

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

[Dan Olson]

> What about supporting 286 protected mode in a manner that more than one
> text+data segment per program are possible - still far-pointers were to be
> implmented, but would segment switching not be easier with HW-protection (in
> comparison to 8086)?  I am not familiar with  compiler programming, so I
> have no idea of how much work it would be.

It seems like this came up in the past and the conclusion was that there
weren't enough 286s to make it worth while, the code wouldn't work on the
8088/8086 and of course a 386SX will run a stripped Linux.

> The last time I looked into the elks sources there was code for initializing
> 286 protected mode - don't know if it works.

You know, that sounds familar.  Was there was work to use protected mode
in order to use extended memory as a RAM drive?  Maybe I'm thinking of
something else.

	Dan

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

[Harry Kalogirou]

> Without protected mode that could get sticky.  How can it be done
cleanly
> and in a stable manner?

Actually I'm quite certain that I remember myself coding that! 
ELKS allready supports swapping!

-- 
Harry Kalogirou <harkal@gmx.net>